Re: [PATCH] odb/files: be less aggressive with geometric repacking

Heh, looks like a typed up a response and got distracted just before
the end and never came back and sent it.  Sending now due to Patrick's
ping about this not showing up in What's Cooking; maybe an extra
review will help.  :-)

On Tue, Aug 11, 2026 at 2:17 AM Patrick Steinhardt [off-list ref] wrote:

When performing auto-maintenance with geometric repacking we have two
conditions that may trigger a repack:

  - Either the geometric sequence of packfiles is invalidated.

  - Or we have too many loose objects.

The first condition shouldn't trigger all that often: it may be hit when
we fetch a new packfile, but users tend to not do that all the time. The
second condition is what typically triggers more regularly though, as
every command that ends up writing new objects may cause us to cross the
threshold of loose objects. It is thus preferable to not be too
aggressive here, as otherwise we may end up repacking objects quite
often.

For the geometric-repacking strategy though we have a default of 100
objects, only. As we're approximating the count of objects by only
reading the "objects/17/" shared, we'd only need 2 objects in there
before we perform a repack by default, which is quite aggressive.
git-gc(1) on the other hand has a default of 6700, so it is quite a bit
more conservative here.

2?  Wouldn't you only need 1 (or if you could have fractional numbers
of objects, only 0.390625 of them)?  <looks around...>    Oh, huh:

        /*
         * This is weird, but stems from legacy behaviour: the GC auto
         * threshold was always essentially interpreted as if it was rounded up
         * to the next multiple 256 of, so we retain this behaviour for now.
         */
        return loose_count > (DIV_ROUND_UP(((unsigned long) limit), 256) * 256);

So, indeed, you need 2.

Being this aggressive is also causing problems as reported by our users.
When running lots of concurrent writers, those writes will constantly
end up spawning maintenance jobs that end up repacking objects. As we
also prune objects, a concurrently running process that tries to write
an object may see that the sharding directories get removed under their
feet. While we try re-creating such leading directories, we only do so a
single time, and it may happen that the directory vanishes again before
we had the chance to create the loose object. This is not a new problem,
but it is exacerbated by us running maintenance this aggressively.

Unrelated to this patch...but should git avoid pruning the loose
object sharding directories?

Improve the status quo by reducing the frequency at which we pack loose
objects to the same frequency that git-gc(1) uses.

Makes sense.

Looks good to me.