Re: Recovering from repository corruption

[Nicolas Pitre <nico@cam.org>]

On Tue, 10 Jun 2008, Linus Torvalds wrote:

> 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