Hi, Jaegeuk On 2018/2/10 8:44, Jaegeuk Kim wrote: > On 02/02, Junling Zheng wrote: >> Commit "0a007b97aad6"(f2fs: recover directory operations by fsync) >> fixed xfstest generic/342 case, but it also increased the written >> data and caused the performance degradation. In most cases, there's >> no need to do so heavily fsync actually. >> >> So we introduce a new mount option "strict_fsync" to control the >> policy of fsync. It's set by default, and means that fsync follows >> POSIX semantics. And "nostrict_fsync" means that the behaviour is >> in line with xfs, ext4 and btrfs, where generic/342 will pass. > > How about adding "fsync=%s" to give another chance for fsync policies? >
OK, I'll give patch v3 to change to "fsync=%s" format. BTW, which policy do u think should be the default behavior for f2fs? Posix or ext4? Thanks Junling > Thanks, > >> >> Signed-off-by: Junling Zheng <zhengjunl...@huawei.com> >> Reviewed-by: Chao Yu <yuch...@huawei.com> >> --- >> Documentation/filesystems/f2fs.txt | 4 ++++ >> fs/f2fs/dir.c | 3 ++- >> fs/f2fs/f2fs.h | 1 + >> fs/f2fs/file.c | 3 ++- >> fs/f2fs/namei.c | 9 ++++++--- >> fs/f2fs/super.c | 13 +++++++++++++ >> 6 files changed, 28 insertions(+), 5 deletions(-) >> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
