Re: [PATCH] enable core.fsyncObjectFiles by default

From: Theodore Ts'o <tytso@mit.edu>
Date: Jan 20, 2018, 22:14 UTC
Message-ID: <20180120221445.GA4451@thunk.org>
In-Reply-To: <xmqqzi59psxt.fsf@gitster.mtv.corp.google.com>

On Fri, Jan 19, 2018 at 11:08:46AM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> So..., is it fair to say that the one you sent in
> 
>   https://public-inbox.org/git/20180117193510.GA30657@lst.de/
> 
> is the best variant we have seen in this thread so far?  I'll keep
> that in my inbox so that I do not forget, but I think we would want
> to deal with a hotfix for 2.16 on case insensitive platforms before
> this topic.

It's a simplistic fix, but it will work. There may very well be certain workloads which generate a large number of loose objects (e.g., git repack -A) which will make things go significantly more slowly as a result. It might very well be the case that if nothing else is going on, something like "write all the files without fsync(2), then use syncfs(2)" would be much faster. The downside with that approach is if indeed you were downloading a multi-gigabyte DVD image at the same time, the syncfs(2) will force a writeback of the partially writte DVD image, or some other unrelated files.

But if the goal is to just change the default, and then see what shakes out, and then apply other optimizations later, that's certainly a valid result. I've never been fond of the "git repack -A" behavior where it can generate huge numbers of loose files. I'd much prefer it if the other objects ended up in a separate pack file, and then some other provision made for nuking that pack file some time later. But that's expanding the scope significantly over what's currently being discussed.

						- Ted