Re: [PATCH] btrfs: zoned: automatically reclaim zones

[Johannes Thumshirn <Johannes.Thumshirn@wdc.com>]

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.thumshirn@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.