Re: [PATCH 1/2] maintenance: account for promisor pack geometry

On Mon, Aug 10, 2026 at 05:11:32PM +0200, Patrick Steinhardt wrote:
> > Check both progressions before choosing the repack mode. If either
> > leaves a pack above its split, geometric repack still avoids rewriting
> > that pack, whereas the all-into-one fallback would rewrite it. Use the
> > fallback only when neither progression leaves a pack behind. That
> > preserves the reason for the fallback: let the all-into-one repack
> > handle unreachable objects when it is not rewriting more packs than the
> > geometric repack.
>
> Okay. The consequence of the status quo could be that we perform an
> all-into-one repack more frequent than really desired because the set of
> non-promised packs is small, and thus even writing a small set of new
> objects could cause a full repack.

Right. I stumbled on this after a few colleagues had reported that their
geometric maintenance task didn't seem to be doing anything. When
looking into it, I found that they had many promisor packs, but the
non-promisor packs were already in a geometric progression, and thus we
did an all-into-one repack.

> This might create the reverse situation though, where we don't perform
> the all-into-one repack at all anymore. We could come up with a clever
> solution here, like for example considering both sequences together and
> repacking when we cross a certain combined threshold. But I'm not sure
> it's worth it for now, and we can still evolve the strategy as needed.

The change in this patch means that we will perform a geometric repack
when doing so would result in a new geometrically-repacked series of
promisor packs, in addition to non-promisor ones.

Is your concern that the non-promisor packs might be in a state where we
should compact them into a single pack, but that the sequence of
promisor packs would prevent us from doing so? In that case, we will
perform a geometric repack on both sets of packs independently. If the
non-promisor packs should be rolled up into a single pack (i.e.,
"geometry.split == geometry.pack_nr"), then the geometric repack *will*
produce a single pack, as if we had performed an all-into-one repack on
the set of non-promisor packs.

So I am not sure that I understand your concern here, but please let me
know if I am missing some aspect of it.

Thanks,
Taylor