On Sun, Apr 29, 2018 at 5:16 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: >> In the spirit of clarifying fsync behavior, we have one more case >> where we'd like to find out what should be expected. >> >> Consider this: >> >> Mkdir A >> Creat A/bar >> Fsync A/bar >> Rename A to B >> Fsync B/bar >> -- Crash -- >> >> A/bar has been fsynced previously, so its not a newly created file. >> After the crash, in ext4 and btrfs, can we expect directory B and >> B/bar to exist? > > or ext4, no. The POSIX semantics apply: bar will *either* be in A, > or in B. Thank you for confirming this. > If you modify the file bar such that the mod time has been updated, > then fsync(2) --- but not necessarily fdatasync(2) --- will cause the > inode modifications to be written committed, and this will cause the > updates to directory B from the rename to be committed as a > side-effect. > > Note though that there are plenty of people who consider this to be a > performance bug, and not a feature, and there have been papers > proposed by your fellow academics that if implemented, would change > this to no longer be true. > > In general with these sorts of things it would be useful to reason > about this in the context of real world applications and why they want > such guarantees. These guarantees can cost performance hits, and so > there is a cost/benefit tradeoff involved. So my preference is to > negotiate with applicationt writes, and ask *why* they want such > guarantees, and to explore whether there better ways of achieving > their high level goals before we legislate this to be an iron-clad > commitment which might application A happy, but performance-seeking > user B unhappy. I definitely agree that there is a performance trade-off for each guarantee given by the file system. We are not suggesting any particular set of guarantees, only trying to find out what are supported by different file systems. I agree that application use-cases seem like a good way to motivate the guarantees given by file systems. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
