Re: Recovering from repository corruption

From: Nicolas Pitre <nico@cam.org>
Date: Jun 11, 2008, 00:43 UTC
Message-ID: <alpine.LFD.1.10.0806102026430.23110@xanadu.home>
In-Reply-To: <alpine.LFD.1.10.0806101518590.3101@woody.linux-foundation.org>

On Tue, 10 Jun 2008, Linus Torvalds wrote:

Show 13 quoted lines

> Anyway, I'll think about sane ways to add a "safe" mode without making it 
> _too_ painful. In the meantime, here's a trial patch that you should 
> probably use. It does slow things down, but hopefully not too much.
> 
> (I really don't much like it - but I think this is a good change, and I 
> just need to come up with a better way to do the fsync() than to be 
> totally synchronous about it.)
> 
> It's going to make big "git add" calls *much* slower, so I'm not very 
> happy about it (especially since we don't actually care that deeply about 
> the files really being there until much later, so doing something 
> asynchronous would be perfectly acceptable), but for you this is 
> definitely worth-while.

I don't like it at all.

I think this only gives a false sense of security with a huge performance cost. If the machine crashes at the right moment, the object will still be half written/fsync'd and you'll be in the same situation again.

And because we don't overwrite existing objects (again for performance reasons), then a corrupted blob object will remain corrupted even if you reattempt the commit later. So doing the fsync only when the commit object is written isn't a good solution either.

I wonder if supporting crashy systems is worth that cost. If Denis' laptop is the odd case then a sync in the commit hook might be plenty sufficient. Personally I'd simply replace the OS or the machine for something more reliable.

Nicolas