On 3/17/21 6:38 AM, Johannes Thumshirn wrote:
When a file gets deleted on a zoned file system, the space freed is no
returned back into the block group's free space, but is migrated to
zone_unusable.
As this zone_unusable space is behind the current write pointer it is not
possible to use it for new allocations. In the current implementation a
zone is reset once all of the block group's space is accounted as zone
unusable.
This behaviour can lead to premature ENOSPC errors on a busy file system.
Instead of only reclaiming the zone once it is completely unusable,
kick off a reclaim job once the amount of unusable bytes exceeds a user
configurable threshold between 51% and 100%.
Similar to reclaiming unused block groups, these dirty block groups are
added to a to_reclaim list and then on a transaction commit, the reclaim
process is triggered but after we deleted unused block groups, which will
free space for the relocation process.
Signed-off-by: Johannes Thumshirn <johannes.thumsh...@wdc.com>
I think this is generally useful, but we should indicate to the user that it's
happening via automatic cleanup and not because of somebody using btrfs balance
start.
As for doing it on non-zoned, I'm still hesitant to do this simply because I
haven't been able to finish working on the relocation stuff. Once my current
set of patches get merged I'll pick it back up, but there still remains some
pretty unpleasant side-effects of balance.
Chris and I have been discussing your RAID5/6 plan, and we both really, really
like the idea of the stripe root from the point of view that it makes relocation
insanely straightforward and simple. I think once we have that in place I'd
feel a lot more comfortable running relocation automatically everywhere, as
it'll be a much faster and less error prone operation. Thanks,
Josef
