On 11/3/25 7:17 AM, 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?
Hi Damien and Johannes,
I have a different proposal, namely not to introduce BLKREPORTZONEV2 at
all. If we keep the BLKREPORTZONE ioctl and do not introduce the
BLKREPORTZONEV2 ioctl then in the kernel we only have to cache zone
information that will be used by filesystems. Information that won't be
used by filesystems doesn't have to be cached. With this approach the
existing data structures are sufficient (struct blk_zone_wplug and
conv_zones_bitmap) and we don't need to introduce new data structures
for tracking zone information.
Thanks,
Bart.
