Re: [PATCH] builtin/repack.c: remove redundant pack-based bitmaps
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Oct 17, 2022, 18:50 UTC
- Message-ID
- <221017.868rlejn4z.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <Y02YzYS172skpbAb@coredump.intra.peff.net>
On Mon, Oct 17 2022, Jeff King wrote:
Show 16 quoted lines
> On Wed, Oct 12, 2022 at 03:05:33PM -0400, Taylor Blau wrote:
> [...]
>> [...]
>> + for_each_string_list_item(item, include) {
>> + strbuf_addstr(&path, item->string);
>> + strbuf_strip_suffix(&path, ".idx");
>> + strbuf_addstr(&path, ".bitmap");
>> +
>> + if (unlink(path.buf) && errno != ENOENT)
>> + die_errno(_("could not remove stale bitmap: %s"),
>> + path.buf);
>
> We could downgrade this to a warning, since there is no downside to
> retaining those files (aside from wasted space). In
> remove_redundant_pack(), we call into unlink_pack_path(), which just
> ignores unlink errors (though arguably it should at least warn).An ENOENT would indicate a race with a concurrent process.
That in itself seems like a wart of our lock management. I.e. we invoked "multi-pack-index" earlier and took a lock to create the midx.
I don't know how exactly that interact with the pack bitmaps, but should we ideally have taken locks on the relevant associated files instead during the larger operation?
But anyway, that's a much larger topic, so we could sweep it under the rug here.
But at that point should we be ignoring other unlink() errors? Maybe we should additionally be ignoring EBUSY.
But the rest all seem from a quick scan of unlink(2) to be things we'd like to just die on, e.g. EIO.