On 11/4/25 01:34, Chaitanya Kulkarni wrote: > Adding Keith's current email address : > 's/Keith Busch <[email protected]>/[email protected]/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
