From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org, derrickstolee@github.com, vdye@github.com,
gitster@pobox.com
Subject: Re: [PATCH] builtin/repack.c: remove redundant pack-based bitmaps
Date: Mon, 17 Oct 2022 20:50:07 +0200 [thread overview]
Message-ID: <221017.868rlejn4z.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <Y02YzYS172skpbAb@coredump.intra.peff.net>
On Mon, Oct 17 2022, Jeff King wrote:
> 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.
next prev parent reply other threads:[~2022-10-17 18:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 19:05 [PATCH] builtin/repack.c: remove redundant pack-based bitmaps Taylor Blau
2022-10-17 18:02 ` Jeff King
2022-10-17 18:50 ` Ævar Arnfjörð Bjarmason [this message]
2022-10-17 19:27 ` Jeff King
2022-10-17 21:04 ` Junio C Hamano
2022-10-17 21:40 ` Jeff King
2022-10-18 2:38 ` Taylor Blau
2022-10-18 2:43 ` Taylor Blau
2022-10-18 2:45 ` [PATCH v2] " Taylor Blau
2022-10-18 6:29 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=221017.868rlejn4z.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=vdye@github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).