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.
