On Thu, Sep 17 2020, Christoph Hellwig wrote: > On Thu, Sep 17, 2020 at 01:28:29PM +0200, Ævar Arnfjörð Bjarmason wrote: >> Change the behavior of core.fsyncObjectFiles to also sync the >> directory entry. I don't have a case where this broke, just going by >> paranoia and the fsync(2) manual page's guarantees about its behavior. > > It is not just paranoia, but indeed what is required from the standards > POV. At least for many Linux file systems your second fsync will be > very cheap (basically a NULL syscall) as the log has alredy been forced > all the way by the first one, but you can't rely on that. > > Acked-by: Christoph Hellwig <hch@xxxxxx> Thanks a lot for your advice in this thread. Can you (or someone else) suggest a Linux fs setup that's as unforgiving as possible vis-a-vis fsync() for testing? I'd like to hack on making git better at this, but one of the problems of testing it is that modern filesystems generally do a pretty good job of not losing your data. So something like ext4's commit=N is an obvious start, but for git's own test suite it would be ideal to have process A write file X, and then have process B try to read it and just not see it if X hadn't been fsynced (or not see its directory if that hadn't been synced). It would turn our test suite into pretty much a 100% failure, but one that could then be fixed by fixing the relevant file writing code.
