DragonFlyBSD

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.