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. 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 know this is not POSIX compliant, but from prior comments, it seems > like both ext4 and btrfs would like to persist directory entries upon > fsync of newly created files. So we were wondering if this extended to > this case. We had real world examples of users/applications who suffered data loss when the directory entries for newly created files were not persisted. It was on the basis of these complaints that we made this commitment, since it seemed more important than the relatively minor performance hit. Cheers, - Ted -- 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
