summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/call-graph-from-sql.py
diff options
context:
space:
mode:
authorChao Yu <yuchao0@huawei.com>2016-11-17 15:53:31 +0300
committerJaegeuk Kim <jaegeuk@kernel.org>2016-11-25 21:16:03 +0300
commit281518c694a5228d6c46fac83529fb3e2c331281 (patch)
tree6d3a41a3952a757f4817822024972a4af2b430b0 /tools/perf/scripts/python/call-graph-from-sql.py
parent04d47e673863c637a2b44ad34a558aeb5d0a727e (diff)
downloadlinux-281518c694a5228d6c46fac83529fb3e2c331281.tar.xz
f2fs: fix fdatasync
For below two cases, we can't guarantee data consistence: a) 1. xfs_io "pwrite 0 4195328" "fsync" 2. xfs_io "pwrite 4195328 1024" "fdatasync" 3. godown 4. umount & mount --> isize we updated before fdatasync won't be recovered b) 1. xfs_io "pwrite -S 0xcc 0 4202496" "fsync" 2. xfs_io "fpunch 4194304 4096" "fdatasync" 3. godown 4. umount & mount --> dnode we punched before fdatasync won't be recovered The reason is that normally fdatasync won't be aware of modification of metadata in file, e.g. isize changing, dnode updating, so in ->fsync we will skip flushing node pages for above cases, result in making fdatasynced file being lost during recovery. Currently we have introduced DIRTY_META global list in sbi for tracking dirty inode selectively, so in fdatasync we can choose to flush nodes depend on dirty state of current inode in the list. Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-sql.py')
0 files changed, 0 insertions, 0 deletions