Re: [RFC PATCH 1/2] sha1-file: fsync() loose dir entry when core.fsyncObjectFiles

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 22, 2020, 10:42 UTC
Message-ID: <877dsmhz36.fsf@evledraar.gmail.com>
In-Reply-To: <20200917140912.GA27653@lst.de>

On Thu, Sep 17 2020, Christoph Hellwig wrote:

Show 11 quoted lines

> 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@lst.de>

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.