bcachefs: bcachefs_metadata_version_rebalance_v2bcachefs-testing

"Extent needs rebalance for data_replicas" cannot be a pure function of
the extent with the current bch_extent_rebalance, which is required for
the triggers - they would create inconsistencies in the rebalance_work
accounting and btrees when e.g. device durability changes.

So: this adds bch_extent_rebalance.needs_rb, which has flags for all the
reasons rebalance may need to process an extent: the trigger now uses
just these flags instead of running the full "does this extent need
rebalance" calculations in bch2_bkey_sectors_need_rebalance().

Additionally:
- Instead of a single accounting counter for pending rebalance work,
  this is now split out into different counters for the different io
  path options rebalance handles (compression, data_checksum, replicas,
  erasure_code, etc.)

- "Does this extent need to be rebalanced?" is now centralized in
  bch2_bkey_set_needs_rebalance()

- "Is new rebalance_work allowed in this context" is
  new_needs_rb_allowed() - this enforces that extents match the
  specified io path options, with clearly defined exceptions (e.g.
  accounting for races with option changes, and foreground writes are
  allowed to add background_compression and background_target work)

Compatibility notes: still undecided if we'll stick with redefining the
existing bch_extent_rebalance, or add a new extent entry type for
bch_extent_rebalance_v2 - there are pros and cons to both

If we redefine the existing bch_extent_rebalance, on upgrade
check_rebalance_work will correct all the existing bch_extent_rebalance
entries (along with accounting, rebalance_work btrees) - except indirect
extents will need special handling, which we likely need anyways

On downgrade, old versions don't have a recovery pass that
checks/fixes bch_extent_rebalance from the io path options - but they do
that on data move, so we're probably more or less ok; some wonkiness in
rebalance_work accounting would be expected

Adding a bch_extent_rebalance_v2 would be an incompatible upgrade
(adding new extent entry types is always an incompatible upgrade,
unfortunately) - and it'd require keeping around compatibility code for
e.g. the triggers to handle the old bch_extent_rebalance...

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

0 files changed, 0 insertions, 0 deletions