Hi,
While testing filesystems for crash consistency, we came across a
workload that could demonstrate that f2fs lacks strictly ordered
metadata behavior.
Workload:
mkdir A
sync()
rename(A, B)
creat (B/foo)
fsync (B/foo)
---crash---
For a strictly ordered metadata filesystem, if we fsync a file, then
all previous transactions that are required to reference this file
must also be committed. Going by this logic, fsync(B/foo) should have
persisted the rename operation and the directory B itself. ext4 and
xfs correctly resolve all dependencies and on recovery from a crash,
we see both directory B and B/foo i.e. the contents of directory are:
dir A : does not exist
dir B:
foo
However in f2fs, on recovery we see:
dir A :
foo
dir B : does not exist
This seems to be an incorrect state to recover to, because the file
foo was created in directory B after the rename operation and we
incorrectly see the entry in directory A.
However, if we tweak the workload to not have a sync, i.e
mkdir A
rename(A, B)
creat (B/foo)
fsync (B/foo)
---crash---
then, the file B/foo and directory B are persisted. We don't seem to
understand the reason for this behaviour.
We understand that POSIX requires fsync on directory B to persist the
rename operation, and f2fs does persist the entries if we sync the
directory, however most filesystems(ext4, xfs) provide much higher
guarantees when it comes to crash consistency.
If F2FS classifies itself as a filesystem that provides ordered
metadata behaviour, shouldn't it correctly persist the rename in this
case? Let us know what you think about this inconsistent behaviour.
Thanks,
Jayashree Mohan
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
