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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html