On Wed, Aug 27, 2025 at 01:49:06AM +0300, Nikita Ofitserov via B4 Relay wrote:
> This patch series introduces new per-btree accounting counters and uses
> them for (hopefully) accurate progress reporting in recovery passes.
> Also includes various assorted bugfixes.
>
> The first commit ("Relax restrictions on the number of accounting
> counters") is optional, but will likely greatly improve the
> upgrade/tools version mismatch experience. Without it, all bree usage
> accounting will be thrown out and rebuilt on any version mismatch.
>
> The second commit has the format change but does not contain the
> upgrade/downgrade table entries. It is intended to be integrated
> together with other accounting changes in a single version upgrade.
>
> The last four commits are drive-by fixes/improvements, especially
> "Improve check_allocations pass speed not in fsck", which should make
> the future accounting upgrades much faster.
Series looks good, except for a couple notes:
- I prefer bugfixes/refactorings to come at the start of a series, so we
can get them in right away; I try to push on disk format changes as
far back in the series as I can
- The nr_counters check you deleted in bkey_validate has
upgrade/downgrade considerations, old versions will blow away the
btree counters on downgrade. That means we have to add a downgrade
table entry and run check_allocations, on both upgrade and downgrade
- As noted on IRC, by default all on disk format changes with only very
simple exceptions should get a new on disk format version; it helps
document what changed and it's good hygiene - version numbers are
cheap
- We should probably think more about upgrade/downgrade testing: I have
upgrade/downgrade tests, but they're not automated since they require
disk images that the CI doesn't know about
