Re: [PATCH v2 2/2] btrfs: zoned: automatically reclaim zones

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

On 23/03/2021 07:45, Anand Jain wrote:
> 
> On 19/03/2021 18:48, Johannes Thumshirn wrote:
>> When a file gets deleted on a zoned file system, the space freed is not
>> 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%. It can be set per mounted
>> filesystem via the sysfs tunable bg_reclaim_threshold which is set to 75%
>> per default.
>>
>> 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.
>>
> 
> Still, in the code below, I don't see the zone write pointer reset of
> the zone_unusable done here. Where does that happen? Or what did I miss?

This is indeed correct, relocation doesn't call trim/zone-reset. I've added
a patch to the series taking this into account. Thanks for spotting.