Re: ignoring extra bitmap file?

From: Jeff King <peff@peff.net>
Date: Aug 18, 2017, 06:53 UTC
Message-ID: <20170818065333.7povtg6b4sugnnfg@sigill.intra.peff.net>
In-Reply-To: <20170817192436.GA4782@inner.h.apk.li>

On Thu, Aug 17, 2017 at 09:24:36PM +0200, Andreas Krey wrote:

Show 5 quoted lines

> I'm seeing the message
> 
>    remote: warning: ignoring extra bitmap file: ./objects/pack/pack-2943dc24....pack
> 
> and indeed, there is such a thing (two, actually):

Only one is the extra. :) The other is doing something useful.

Basically, the bitmap code was written to a handle a single bitmap file. It would be possible to handle multiple, but it simplified the implementation greatly to only handle one. And in practice, since a bitmap can only be made for a pack which contains all of the reachable objects, you'd have only one bitmap per repo, for the one big "main" pack.

> But it looks like something went wrong in that repack cycle (that
> pack-2943dc247702 is the full repo), and it won't get removed later
> in the next repack in the evening.

Yes, it looks like you got a full repack that failed to remove the old pack. Or more likely you had two full repacks racing with each other, each creating a new big pack.

So the extra bitmap here is harmless. Both of them contain more or less the same data, and whichever one we use will be fine (and remember that the .bitmap files are purely an optimization, so that "more or less" will only make a minor impact on the speed of operations, not on the output).

> Question: Can I safely remove the .bitmap file, and repack will then
> clean up the .pack and .idx files as will?

Yes, it's always safe to remove a .bitmap file (though if you remove the last one, you may expect performance to drop for some operations).

Whether there's a .bitmap doesn't impact whether .pack and .idx files are deleted. The next full repack would pack everything into a new big pack, and then delete any existing files, including .pack, .idx, and .bitmap.

-Peff