Re: missing objects -- prevention

[Jeff King <peff@peff.net>]

On Sun, Jan 13, 2013 at 06:26:53AM +0530, Sitaram Chamarty wrote:

> > Right, I meant if you have receive.fsckObjects on. It won't help this
> > situation at all, as we already do a connectivity check separate from
> > the fsck. But I do recommend it in general, just because it helps catch
> > bad objects before they gets disseminated to a wider audience (at which
> > point it is often infeasible to rewind history). And it has found git
> > bugs (e.g., null sha1s in tree entries).
> 
> I will add this.  Any idea if there's a significant performance hit?

Not usually; we are already resolving all of the sent deltas as a
precaution, anyway. I do notice after a push to GitHub there is
sometimes a second or two of pause from the server before the push
status is shown. But I haven't narrowed it down to fsck (versus
connectivity check, versus our post-receive hook).

So you may want to keep an eye on the effects (and if you have numbers,
please share :) ).

> That's always the hard part.  System admins (at the Unix level) insist
> there's nothing wrong and no disk errors and so on...  that is why I
> was interested in network errors causing problems and so on.

Yeah, I feel bad saying "well, this repo is totally corrupted, but it
couldn't possibly be git's fault, because that's not what its failure
modes look like". But luckily our Ops people are very understanding, and
most of the problems I have seen have turned out to be fs corruption
after all (the pack-refs things is the big exception).

> Thanks once again for your patient replies!

No problem. There aren't many people dealing with large-scale
server-side issues, so it's something that doesn't come up much on the
list. I'm happy to talk about it.

-Peff