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

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

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,


Reply via email to