* ecbalancer: cap total shards per rack in Plan
Plan caps data and parity per rack separately (ceil(data/racks) and
ceil(parity/racks)), so with 10+4 over 8 racks a rack can legally hold
2 data + 1 parity. When a rack is one disk, losing two such racks loses
6 of 14 shards and the volume can't be read.
The cross-rack phase now also caps each rack's TOTAL shards of a
volume, sized with Place's rackTotalCap: ceil(shards/racks) unless the
racks lack room, counting a rack's own shards of the volume as room
since Plan can move them.
- A rack above the cap sheds parity until it fits. Those shards may go
to a data-bearing rack, and when no rack is under the parity cap
they fall back to a rack under the total cap. #11438's non-overflow
candidates keep moving only to data-free racks.
- No cross-rack move lands on a rack at the cap.
- A rack above the cap triggers balancing regardless of the imbalance
threshold.
- The fallback applies only while the source rack is above the cap;
otherwise the next Plan moves the shard back.
- Options.RackTotalCapRaised reports volumes whose cap had to be raised
above the even share; the worker and the shell log it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* ecbalancer: finish the rack cap in one Plan, count SameRackCount room
Review follow-ups.
- The data pass can run out of destinations before the parity pass frees
slots elsewhere, which left a data-heavy rack above the cap after one
Plan (a one-shot shell balance stops there). The cross-rack phase now
repeats while a rack is above the cap and the last round moved
something. A shard moves at most once per plan, since each move runs
as its own task.
- planRackTotalCap bounds each node's room by what SameRackCount still
allows, as Place does. Counting the raw free slots sized the cap too
low, so RackTotalCapRaised missed volumes it should report.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
