Re: Non-robust lock files in containers can lead to repo corruption

From: Jeff King <peff@peff.net>
Date: Aug 12, 2019, 16:38 UTC
Message-ID: <20190812163812.GB26231@sigill.intra.peff.net>
In-Reply-To: <qimq0i$49gn$1@blaine.gmane.org>

On Sat, Aug 10, 2019 at 09:05:33AM -0700, Gregory Szorc wrote:

Show 7 quoted lines

> I tracked down a source of Git corrupting repositories to lock file
> design not being robust when containers / PID namespaces are present.
> 
> In my case, the corruption stemmed from premature release of the `git
> gc` lock in the gc.pid file. But since the lock file code for that file
> is in gc.c, there could be other lock files in Git affected by the same
> design limitation as well.

I don't think there are. Most of Git's locks are predicated purely on the existence of the lockfile (with the intent that they'd work over systems like NFS). The gc lock is a weird one-off.

And while it's not great for multiple gc's to run at the same time (because it wastes CPU), two of them running at the same time shouldn't cause a corruption. If you have a reproducible demonstration where that happens, I'd be very interested to see it.

-Peff