On 17/03/2021 15:33, David Sterba wrote: > On Wed, Mar 17, 2021 at 07:38:11PM +0900, 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'll add it as topic branch to for-next but I haven't reviewed it and > first thing I see missing is lack of mentioning the sysfs tunable in the > changelog. >
Thanks, will add the sysfs tunable (and fixed the type in line 1 of the commit msg as well). Can we also kick off a discussion whether this is generally useful for btrfs and not just a zoned FS? While we're not having a low hanging fruit like zone_unusable as indicator when to balance, I think we can work against fragmentation this way.
