[PATCH 07/13] block: track zone conditions

[Damien Le Moal]

On 11/4/25 00:48, Bart Van Assche wrote:
> On 11/2/25 10:05 PM, Damien Le Moal wrote:
>> On 11/1/25 06:17, Bart Van Assche wrote:
>>> On 10/30/25 11:13 PM, Damien Le Moal wrote:
>>>> Implement tracking of the runtime changes to zone conditions using
>>>> the new cond field in struct blk_zone_wplug. The size of this structure
>>>> remains 112 Bytes as the new field replaces the 4 Bytes padding at the
>>>> end of the structure. For zones that do not have a zone write plug, the
>>>> zones_cond array of a disk is used to track changes to zone conditions,
>>>> e.g. when a zone reset, reset all or finish operation is executed.
>>>
>>> Why is it necessary to track the condition of sequential zones that do
>>> not have a zone write plug? Please explain what the use cases are.
>>
>> Because zones that do not have a zone write plug can be empty OR full.
> 
> Why does the block layer have to track this information? Filesystems can
> easily derive this information from the filesystem metadata information,
> isn't it?

The title of this patch series is: Introduce cached report zones.
For that, the answer to your question is I think obvious. Otherwise, how do you
exactly propose to report correctly the condition of a zone without have that
condition tracked and cached in memory ?

The point here is to provide as much information (almost) as a device generated
report zone, but much fasterer, using cached information only, thus avoiding any
(much slower) command execution on the device. And as these patches show, that
is not that hard to do, with the trade-off of a slightly higher memory usage per
device.

See the numbers for XFS and BTRFS mount speedup in patch 14 and 15. The gains
are even higher when mounting a large BTRFS RAID volume with many SMR drives.


-- 
Damien Le Moal
Western Digital Research