Re: [PATCH] perf: work around the tested repo having an index.lock

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 2, 2017, 20:12 UTC
Message-ID: <CACBZZX61uqRsB8p+VdA=DZEt6Aa9bA+c4zTa5-ngmG8G4U3U4Q@mail.gmail.com>
In-Reply-To: <20170602184506.x2inwswmcwafyvfy@sigill.intra.peff.net>

On Fri, Jun 2, 2017 at 8:45 PM, Jeff King <peff@peff.net> wrote:

Show 24 quoted lines

> On Fri, Jun 02, 2017 at 10:33:30AM +0000, Ævar Arnfjörð Bjarmason wrote:
>
>> When the tested repo has an index.lock file it should be removed. This
>> file may be present if e.g. git-status previously crashed in that
>> repo, and it will make a lot of git commands fail. Let's try harder
>> and remove the lock.
>
> If your git-status is crashing, you probably have bigger problems (and
> need to clean up the original, too).
>
> But I think a more compelling case is that there may be an ongoing
> operation in the original repo (e.g., say you are in the middle of
> writing a commit message) when we do a blind copy of the filesystem
> contents. You might racily pick up a lockfile.
>
> Should we find and delete all *.lock files in the copied directory? That
> would get ref locks, etc. Half-formed object files are OK. Technically
> if you want to get an uncorrupted repository you'd also want to copy
> refs before objects (in case somebody makes a new object and updates a
> ref while you're copying).
>
> I don't know how careful it's worth being. I don't really _object_ to
> this patch exactly, but it does seem like it's picking up one random
> case (that presumably you hit) and ignoring all of the related cases.

It's not a perfect solution, but it seemed not to cause any harm, and would allow us to just do what you mean. I can't think of a case where we'd care to preserve the index.lock in our perf copy, of course the test may fail due to various other reasons, but at least it won't be due to this reason.

This is just something I happened to run into locally because I had a stale index.lock, but FWIW at work I have a git updater running on tens of thousands of machines that has to handle various edge cases (e.g. the machine ran out of disk space in the middle of an update, or something was kill -9'd).

The leftover index.lock is quite common, the second most common "index is hosed" error is "fatal: index file smaller than expected", but solving that is more invasive, you need to rm the index and reset --hard.