RE: safer git?

["Randall S. Becker" <rsbecker@nexbridge.com>]

On October 24, 2020 11:06 PM, brian m. carlson wrote:
> [I somehow didn't get the original message, so replying inline below.]
> 
> On 2020-10-24 at 22:11:54, Randall S. Becker wrote:
> > On October 24, 2020 4:19 PM, hv@crypt.org wrote:
> > > Q: Is there a mode in which I can run git that would make it a bit
> > > more robust against crashes, at the cost of being a bit slower?
> > >
> > >
> > > The primary symptom is that files modified shortly before a crash
> > > show up existing but zero-length after the crash. For source files I
> > > mostly know what to do in that situation, but `git fsck` shows a lot
> > > of files under '.git/objects' that are empty, which seems to make
> > > things hard to recover:
> > >
> > > % git fsck
> > > error: object file
> > > .git/objects/0e/f31631726cea2e9bf89d7bbe7b924b5282d533 is empty
> > > error: unable to mmap
> > > .git/objects/0e/f31631726cea2e9bf89d7bbe7b924b5282d533: No such
> file
> > > or directory
> > > error: 0ef31631726cea2e9bf89d7bbe7b924b5282d533: object corrupt or
> > > missing: .git/objects/0e/f31631726cea2e9bf89d7bbe7b924b5282d533
> > > [... a dozen similar entries ...]
> > > error: object file
> > > .git/objects/f5/a9d125645e69a0e40f9bf7a8c90b1c1c4a4ea5 is empty
> > > error: unable to mmap
> > > .git/objects/f5/a9d125645e69a0e40f9bf7a8c90b1c1c4a4ea5: No such
> file
> > > or directory
> > > error: f5a9d125645e69a0e40f9bf7a8c90b1c1c4a4ea5: object corrupt or
> > > missing: .git/objects/f5/a9d125645e69a0e40f9bf7a8c90b1c1c4a4ea5
> > > Checking object directories: 100% (256/256), done.
> > > Checking objects: 100% (1577/1577), done.
> > > error: refs/stash: invalid sha1 pointer
> > > 0000000000000000000000000000000000000000
> > > error: bad ref for .git/logs/refs/stash dangling commit
> > > 1c0ea4e6159952501957012d2b9db7d68b52d107
> > > %
> 
> You can try setting core.fsyncObjectFiles to true.  That's the only knob that
> Git has for that at the moment, although there was some discussion about
> adding a new feature for other files[0].
> 
> I suspect a lot of the zero-byte files and any files that end up as all-zeros are
> due to your file system.  The default file system on Ubuntu is ext4, IIRC, and
> if that's what you're using, you can set data=journal instead of data=ordered
> as a mount option.  For the root file system, you'll need to pass
> rootflags=data=journal as a kernel boot option.
> 
> That may be significantly slower, but until you get your hardware problem
> sorted out, it may very well be worth it for you.  I'd try this option before the
> one below because it'll have less of an impact on performance and may solve
> most or all of your problems.
> 
> > > Last time I checked out the previous state from github in a new
> > > directory
> > and
> > > was able to find and copy over most of my work before continuing. On
> > > this occasion I did a `git stash save` shortly before the crash, and
> > > I'm not
> > sure
> > > how to get that back. I see René Scharfe's suggestion of:
> > >   git fsck --unreachable |
> > >   grep commit | cut -d\  -f3 |
> > >   xargs git log --merges --no-walk --grep=WIP from a recent message,
> > > but that is only showing me an older stash item.
> >
> > I would suggest turning off write-through buffering on your disk. Let
> > writes complete immediately instead of being deferred to sync. Also,
> > this does feel like a disk issue, so fsck or chkdsk /f (or whatever) on your
> disk urgently.
> 
> Turning off buffering and caching for your disk drive may make things
> _really_ slow, but it will definitely improve data integrity.
> 
> I know hardware problems are always a hassle, so I hope you get things
> figured out and fixed soon.
> 
> [0] I admit I am not running the very latest version and the new feature may
> have already landed; if so, I apologize for the out-of-date information and
> for not keeping up with the list.

Thanks for pointing out the git knob. I didn't know about that one and it seems helpful in general.

Regards,
Randall