btrfs: stripe_alloc: drop incremental claimable credit to end the over-count
The rule-1 credit in __btrfs_add_free_space credited whole stripes on every add,
but several add paths re-add free space that a low-level remove never
de-credited: the async-discard trim (unlink_free_space / bitmap_clear_bits, then
do_trimming re-adds via __btrfs_add_free_space) and btrfs_remove_free_space's
middle-split tail re-add. The double-credit drives bg->stripe_claimable ABOVE
the authoritative per-commit scan (the "incremental stripe_claimable %llu above
scanned %llu" WARN) -- the over-count direction that is unsafe once admission
gates on the counter, where a reservation admitted against phantom supply is
dropped at writeback.
Drop the positive incremental credit entirely. The incremental rules now only
ever DEBIT (removes round out, claims are exact -- both err low); the per-commit
rescan is the sole upward correction. stripe_claimable can therefore only
under-count between commits (early, clean write()-time ENOSPC -- the
deliberately-safe direction) and never over-count, structurally, regardless of
which re-add path forgets to de-credit.
Reproduced with compress+autodefrag+discard=async on a legacy-converted raid5
fs (incremental ~= 2x scanned); credit_return attribution confirmed the phantom
entered through do_trimming's re-add, not the open-stripe allocator returns.
projects / linux / commit