Re: [PATCH] Enable core.fsyncObjectFiles by default

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2015, 05:20 UTC
Message-ID: <xmqqlhf9bs2b.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150624033725.GA19321@peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> I had always assumed this was fine on ext4 with data=ordered (i.e.,
> either the rename and its pointed-to content will go through, or not; so
> you either get your update or the old state, but not a garbage or empty
> file). But it sounds from what Ted wrote in:
>
>   http://article.gmane.org/gmane.linux.file-systems/97255
>
> that this may not be the case. If it's not, I think we should consider
> fsyncing ref writes.

That matches my understanding. IIRC, we do fsync (without a knob to turn it off) packs, we do not fsync refs (as you described above), the index, or working tree files (via write_entry()). Among these:

 * If we are so paranoid that loss of new loose objects matter (as
   opposed to "Heh, it is just the matter of 'git add' again") to
   cause us to set core.fsyncObjectFiles, we should definitely fsync
   ref writes.  They are even more precious.

 * The index is much less precious.  In the worst case, you can 'git
   reset' (no flags) and re-add from the working tree and nothing
   unrecoverable is lost.  I do not mind a knob to force us fsync,
   but we may want it to be separate from core.fsyncObjectFiles.

 * The working tree files?  I am not sure.  Again, recovery is just
   to run "git diff" to notice what was eaten by the power failure
   and then "git checkout $path" to restore from a known state,
   so...