btrfs: stripe_meta: let the transaction machinery's own reservations draw on the reserve
With the whole-stripe reserve counted as used for everyone but the
relocation task, a committing transaction whose handle reserve runs dry
mid-COW gets ENOSPC from btrfs_use_block_rsv(): its NO_FLUSH fallback
reservation is refused as soon as the claimable supply is below the
reserve, and the global reserve behind it has been refilled by fiat
against stripes that do not exist. Seen on the delete phase of the
metadata fill test with relocation running: claimable 163 MiB, reserve
352 MiB, delayed refs freeing the deleted leaves, and the extent tree
COW that freeing needs aborted the transaction with ENOSPC while
163 MiB of whole stripes sat unused (no allocator canary: the allocator
was never asked).
The reserve exists to hold back user operations so relocation and the
commit that follows it have room; it must not hold back the commit.
Let NO_FLUSH, FLUSH_LIMIT (delayed refs, delayed inodes) and EMERGENCY
reservations draw on it like relocation does. They are bounded and
kernel-internal; user reservations (FLUSH_ALL, ALL_STEAL, EVICT, DATA)
still stop at the reserve.
projects / linux / commit