[DragonFlyBSD - Bug #3249] HAMMER2 fsync(2) not working properly

[sigttou]

Issue #3249 has been updated by sigttou.


I reproduced the new-file loss in an HAMMER2 QEMU TCG guest using
master `1cb32eba459f9449dad10687c4886a4217ac9c19`.

After syncing a seed file, the test created a new file, wrote its
marker and successfully called `fsync`, then terminated the
guest without shutdown or umount and checked the same disk.

Results:

 file fsync = 0:                new file absent after recovery
file and directory fsync = 0:   new file absent after recovery
file fsync followed by sync():  new file and marker survive

The reviewed fsync path uses HAMMER2_XOP_INODE_STOP and retains
the comment about not flushing root topology down to the inode.

----------------------------------------
Bug #3249: HAMMER2 fsync(2) not working properly
http://bugs.dragonflybsd.org/issues/3249#change-14799

* Author: tkusumi
* Status: New
* Priority: Normal
* Target version: 6.4
* Start date: 2020-09-21
----------------------------------------
VOP_FSYNC in HAMMER2 doesn't flush chains all the way up to the root, because inodes are initially detached from its parent and they are still detached when fsync happens.

This is also mentioned in the below comment in hammer2_vnops.c.
"This function does not flush the root topology down to the inode."

But if that's part of the design, what's the point of fsync in HAMMER2 ?

e.g. In HAMMER2, a regular file is gone after creat() -> write() -> fsync() -> force-reboot.
To be exact, after force-reboot, nothing (no inode, dirent, data) from creat/write/fsync was allocated in freemap.




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account