On Fri, Feb 13, 2015 at 12:47:54PM +0000, Filipe Manana wrote: > This test is motivated by an fsync issue discovered in btrfs. > The issue was that we could lose file data, that was previously fsync'ed > successfully, if we end up shrinking (via truncate) the file, add a hard > link to our file and then persist the fsync log later via an fsync of > other inode for example. After a power loss our file content wouldn't > match what it had when we last fsync'ed, but instead it had the data > prior to that fsync.
Prior to which fsync? XFS has strictly ordered metadata journalling, which means transactions committed prior to *any* fsync will be present on disk after the fsync. ext4 is not quite so strict, but has essentially the same behaviour. ext3 in ordered mode behaves like XFS. As such, ext3, ext4 and XFS return the state of the file as "0xaa for 0 to 5k, 0x00 out to 32k" and the hardlink foo_link is present after the filesystem is remounted and the log replayed. So, as this test is written, it does not encapsulate the longstanding, expected behaviour of existing filesystems. btrfs should behave like XFS, ext3 and ext4 if possible - being different is only going to cause confusion and pain for application developers. > The btrfs issue was fixed by the following linux kernel patch: > > Btrfs: don't remove extents and xattrs when logging new names Sounds like you've just introduced an ordered mode behavioural journalling regression into btrfs... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
