Re: [PATCH 2/2] block: fix the length of a smaller last zone in blkdev_get_zone_info()

[shashank Jain]

On Mon, Oct 12, 2026, Damien Le Moal wrote:
> I was thinking on adding a "--cached" option to control the use of
> BLK_ZONE_REP_CACHED.
> If you want to take on such patch, go ahead. CC me on it and I will review.

Thanks - yes, I will take it: a "--cached" option to "blkzone report"
that selects BLKREPORTZONEV2 with BLK_ZONE_REP_CACHED, leaving the
default report via the device (BLKREPORTZONE) unchanged. I will post it
to util-linux and CC you. The blktests reproducer will then use
"blkzone report --cached" rather than a bundled helper.

Thanks,
Shashank

On Mon, Oct 12, 2026 at 6:15 PM Damien Le Moal <dlemoal@xxxxxxxxxx> wrote:
>
> On 2026/10/12 14:41, shashank Jain wrote:
> > On Mon, Oct 12, 2026, Damien Le Moal wrote:
> >> How do you plan to issue a BLK_ZONE_REP_CACHED report? "blkzone report"
> >> does not have that yet. I am planning to send a patch for it.
> >
> > Good point. Two options, and I am happy to follow your preference:
> >
> > - Use "blkzone report" with the cached flag once your util-linux patch
> >   lands - that matches the existing zbd tests and avoids a bundled tool.
> >   I would hold the blktests submission until it is available.
>
> We should leave "blkzone report" to get the device report as before, to avoid
> breaking anything for user with the "active" condition being returned.
> I was thinking on adding a "--cached" option to control the use of
> BLK_ZONE_REP_CACHED.
>
> If you want to take on such patch, go ahead. CC me on it and I will review. The
> patches I need to send to add depop support will take some more time.
>
> > - Or carry a small C helper in the blktests src/ directory that issues
> >   BLKREPORTZONEV2 with BLK_ZONE_REP_CACHED directly, so the test is
> >   self-contained and does not depend on the util-linux version.
> >
> > I lean towards the first, to match the zbd conventions and your blkzone
> > work; tell me which you prefer and I will align the test with it.
> >
> > Thanks,
> > Shashank
> >
> > On Mon, Oct 12, 2026 at 6:07 PM Damien Le Moal <dlemoal@xxxxxxxxxx> wrote:
> >>
> >> On 2026/10/12 14:29, shashank Jain wrote:
> >>> On Mon, Oct 12, 2026, Christoph Hellwig wrote:
> >>>> Can you add this to blktests as a reproducer?
> >>>
> >>> Will do. I'll send a blktests test under tests/zbd/ that sets up a zoned
> >>> null_blk device with a smaller last zone and checks that BLKREPORTZONEV2
> >>> without BLK_ZONE_REP_CACHED matches BLKREPORTZONE, and that the cached
> >>> report's last-zone length does not extend past the device. I'll post it
> >>> to the blktests project separately and reference this series.
> >>
> >> How do you plan to issue a BLK_ZONE_REP_CACHED report? "blkzone report" does not
> >> have that yet. I am planning to send a patch for it.
> >>
> >>>
> >>> Thanks,
> >>> Shashank
> >>>
> >>> On Mon, Oct 12, 2026 at 5:51 PM Christoph Hellwig <hch@xxxxxx> wrote:
> >>>>
> >>>> On Sun, Oct 11, 2026 at 10:49:06AM +0530, Shashank Mohan Jain wrote:
> >>>>> blkdev_get_zone_info() sets the length of every zone to the zone size
> >>>>> of the device. The last zone of a zoned block device may be smaller
> >>>>> than the others: blk_revalidate_zone_cb() accepts that and remembers
> >>>>> the capacity of that zone in disk->last_zone_capacity. For such a zone
> >>>>> the length reported from the cached information is too large, and
> >>>>> start + len is beyond the end of the device. A conventional last zone
> >>>>> is also given the capacity of a full zone.
> >>>>>
> >>>>> Example with a zoned null_blk device of 10 MiB (20480 sectors) with
> >>>>> 4 MiB zones, last zone:
> >>>>>
> >>>>>   BLKREPORTZONE:       start 16384 len 4096 capacity 4096
> >>>>>   BLKREPORTZONEV2 with
> >>>>>   BLK_ZONE_REP_CACHED: start 16384 len 8192 capacity 4096
> >>>>
> >>>> Can you add this to blktests as a reproducer?
> >>>>
> >>>> The patch looks good:
> >>>>
> >>>>
> >>>> Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> >>
> >>
> >> --
> >> Damien Le Moal
> >> Western Digital Research
>
>
> --
> Damien Le Moal
> Western Digital Research