[PATCH 07/13] block: track zone conditions
Damien Le Moal
dlemoal at kernel.org
Mon Nov 3 14:53:07 PST 2025
On 11/4/25 01:34, Chaitanya Kulkarni wrote:
> Adding Keith's current email address :
> 's/Keith Busch <keith.busch at wdc.com>/kbusch at kernel.org/g'
>
> On 11/3/25 7:48 AM, 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?
>>
>> Thanks,
>>
>> Bart.
>>
>
> In case current file systems store this, isn't that a code duplication for each
> fs ? perhaps having a central interface at block layer should help remove the
> code duplication ?
catch 22: You cannot ask the file system without first knowing the zone layout
and conditions of zone to check the file system metadata.
--
Damien Le Moal
Western Digital Research
More information about the Linux-nvme
mailing list