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.
