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 -- 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
