On 11/4/25 16:23, Johannes Thumshirn wrote: > 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.
The cache is initialized with zone revalidation and maintained as IOs and zone management operations are executeds. No need to involve blkdev_report_zones() for maintaining the zone information. Not to mention that it would be impossible to correctly do it without guaranteeing that report zones is the *only* command being executed. Otherwise, by the time you process a zone report, write/reset/finish IOs to that zone may already have changed it. -- Damien Le Moal Western Digital Research
