[PATCH v2 11/15] block: introduce BLKREPORTZONESV2 ioctl

[Johannes Thumshirn]

On 11/4/25 1:15 AM, Damien Le Moal wrote:
> On 11/4/25 00:17, Johannes Thumshirn wrote:
>> On 11/3/25 2:38 PM, Damien Le Moal wrote:
>>> Introduce the new BLKREPORTZONESV2 ioctl command to allow user
>>> applications access to the fast zone report implemented by
>>> blkdev_report_zones_cached(). This new ioctl is defined as number 142
>>> and is documented in include/uapi/linux/fs.h.
>>>
>>> Unlike the existing BLKREPORTZONES ioctl, this new ioctl uses the flags
>>> field of struct blk_zone_report also as an input. If the user sets the
>>> BLK_ZONE_REP_CACHED flag as an input, then blkdev_report_zones_cached()
>>> is used to generate the zone report using cached zone information. If
>>> this flag is not set, then BLKREPORTZONESV2 behaves in the same manner
>>> as BLKREPORTZONES and the zone report is generated by accessing the
>>> zoned device.
>>
>> Is there a downside to always do the caching? A.k.a do we need the new
>> ioctl or can we keep using the old one and cache the report zones reply?
> The old one is needed to allow getting the precise imp open, exp open, closed
> conditions, if the user cares about these. E.g. Zonefs does because of the
> (optional) explicit zone open done on file open.
>
> And we cannot break existing user space anyway (e.g. sysutils blkzone), so we
> must return the "legacy" report unless asked otherwise.


OK, let me read the patches again, but why can't we do a "write-through" 
style caching? I.e. something in the system is executing

blkdev_report_zones(), the cache will be populated as well.