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

On Mon, Aug 10, 2026 at 10:56:14AM -0500, Taylor Blau wrote:
> 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.

The concern is that it's quite unlikely that both the geometric and
non-geometric sequence will merge all packs together at the same point
in time. Consequently, we'll never hit the case where we perform an
all-into-one pack to prune unreachable objects, and that may cause us to
never prune objects at all.

So what I'm wondering is whether we should be a bit more clever about
that and perform an all-into-one repack under a new condition, like for
example when the objects we're about to repack exceed a certain
percentage of the repository size.

Hope that clarifies it a bit :)

Thanks!

Patrick