Capacity must leave room to restore redundancy

For a fixed coding factor, multiply the relevant logical payload by that factor before comparing with physical capacity. Include every retained data version that actually consumes storage under the implementation's allocation model. Then account for metadata, indexes, padding, small-object allocation, incomplete uploads, temporary copies, and any additional protection layers. Do not add an imagined provider-internal code to a managed service's billed logical byte count; a self-managed physical budget and a provider invoice have different boundaries.

Reserve must also be defined at the right layer. A stated twenty-percent free target can mean a fraction of installed physical capacity, surviving capacity after a failure, or some administrative pool limit. Those are not equivalent. Document whether the reserve is before or after metadata and whether deleted space is actually reclaimable. A version hidden by a marker or protected by retention is not free just because the application's current namespace no longer lists it.

After losing a device or domain, total usable capacity decreases while desired restored redundancy may still require the same encoded payload on survivors. Aggregate arithmetic is a necessary check, but a placement rule can reject the remaining free space if it is concentrated in the wrong domains. Ceph's recovery-full and backfill-full states illustrate that insufficient eligible space can block restoration. Test the actual failure domains and per-device fullness distribution rather than assuming the average utilization describes every target.

The recovery interval also consumes source reads, network bandwidth, decode CPU, and target writes. Its lower bound depends on the limiting resource and the bytes charged to that resource. Foreground work and scrubbing share some of those resources, and another failure can occur before restoration completes. Do not turn a short ideal repair time into a durability guarantee without a complete failure and recovery model. Measured progress and remaining degraded data provide stronger operational evidence than a configured worker count.

Build scenarios for normal occupancy, one-domain loss, maintenance overlap, and retention-driven growth. For each, identify both the capacity inequality and a feasible replacement placement. Record assumptions about object sizes and skew: a few large placement groups can make a uniform-distribution estimate misleading. Include growth during recovery and a bounded response when reserve is threatened. Deleting a current name is not a reliable emergency capacity lever if old versions or protected data still occupy the backend.

The queue lab illustrates normalized repair-work balance only. Reset, set both λ=4 and μ=3, predict growth from four initial work units, then Play or Step. Reset and set both λ=2,μ=3 to compare a fresh draining case. The model recomputes from its initial four when controls change at retained time, so the comparisons require Reset. It has no physical capacity ceiling, placement map, encoded-byte amplification, or product durability parameters. Use it to distinguish completed-work rate from a backlog chart, then evaluate space and failure scenarios with their own explicit evidence.