> On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: >> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote: >>> My goal for the fsync tree log was to make it just do the right thing most >>> of the time. We mostly got there, thanks to a ton of fixes and test cases >>> from Filipe. >>> >>> fsync(some file) -- all the names for this file will exist, without having >>> to fsync the directory. >>> >>> fsync(some dir) -- ugh, don't fsync the directory. But if you do, all the >>> files/subdirs will exist, and unlinks will be done and renames will be >>> included. This is slow and may require a full FS commit, which is why we >>> don't want dirs fsunk. >> >> What ext4 does is this: >> >> fsync(some file) -- for a newly created file, the filename that it was >> created under will exist. If the file has a hard-link added, >> the hard link is not guarnateed to be written to disk >> >> fsync(some dir) -- all changes to file names in thentee directory will >> exist after the crash. It does *not* guarantee that any data >> changes to any of files in the directories will persist after >> a crash. 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? 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. -- 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
