Re: [PATCH v4 0/8] repack: support repacking into a geometric sequence

From: Martin Fick <mfick@codeaurora.org>
Date: Feb 23, 2021, 21:57 UTC
Message-ID: <2190798.zr6bNypoxz@mfick-lnx>
In-Reply-To: <YDVgPtkaTb9zNq0/@nand.local>

On Tuesday, February 23, 2021 3:06:22 PM MST Taylor Blau wrote:

Show 9 quoted lines

> On Tue, Feb 23, 2021 at 12:54:56PM -0700, Martin Fick wrote:
> > Would it make sense to somehow detect all new packs since the last rollup
> > and always include them in the rollup no matter what their size? That is
> > one thing that my git-exproll script did.
> 
> I'm certainly not opposed, and this could certainly be done in an
> additive way (i.e., after this series). I think the current approach has
> nice properties, but I could also see "roll-up all packs that have
> mtimes after xyz timestamp" being useful.

Just to be clear, I meant to combine the two approaches. And yes, my 
suggestion would likely make more sense as an additive switch later on.

> It would even be possible to reuse a lot of the geometric repack
> machinery. Having a separate path to arrange packs by their mtimes and
> determine the "split" at pack whose mtime is nearest the provided one
> would do exactly what you want.

I was thinking to keep all of your geometric repack machinery and only looking for the split point starting at the right most pack which is newer than the provided mtime, and then possibly enhancing the approach with a clever way to use the mtime of the last consolidation (maybe by touching a pack/.geometric file?).

> (As a side-note, reading the original threads about your git-exproll was
> quite humbling, since it turns out all of the problems I thought were
> hard had already been discussed eight years ago!)

Thanks, but I think you have likely done a much better job than what I did. Your approach of using object counts is likely much better as it should be stable, using byte counts is not. You are also solving only one problem at a time, that's probably better than my hodge-podge of at least 3 different problems. And the most important part of your approach as I understand it, is that it actually saves CPU time whereas my approach only saved IO.

Cheers,

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation