On Thu, Apr 10, 2025 at 08:34:57AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 09, 2025 at 11:41:12AM -0700, Darrick J. Wong wrote:
> > > +#define ZONES_PER_IOCTL 16384
> > > +
> > > +static void
> > > +report_zones_cb(
> > > + struct xfs_mount *mp,
> > > + struct blk_zone *zone)
> > > +{
> > > + xfs_fsblock_t zsbno = xfs_daddr_to_rtb(mp, zone->start);
> >
> > ^^^^^^^^^^^^^ nit: xfs_rtblock_t ?
>
> Updated.
>
> > Nit: inconsistent styles in declaration indentation
>
> Fixed.
>
> > > + device_size /= 512; /* BLKGETSIZE64 reports a byte value */
> >
> > device_size = BTOBB(device_size); ?
>
> Sure.
>
> > > +
> > > + switch (zones[i].type) {
> > > + case BLK_ZONE_TYPE_CONVENTIONAL:
> > > + case BLK_ZONE_TYPE_SEQWRITE_REQ:
> > > + break;
> > > + case BLK_ZONE_TYPE_SEQWRITE_PREF:
> > > + do_error(
> > > +_("Found sequential write preferred zone\n"));
> >
> > I wonder, can "sequential preferred" zones be treated as if they are
> > conventional zones? Albeit really slow ones?
>
> Yes, they could. However in the kernel we've decided that dealing
> them is too painful for the few prototypes build that way and reject
> them in the block layer. So we won't ever seem them here except with
> a rather old kernel.
Ah, I hadn't realized those aren't even supported now, but yeah:
case BLK_ZONE_TYPE_SEQWRITE_PREF:
default:
pr_warn("%s: Invalid zone type 0x%x at sectors %llu\n",
disk->disk_name, (int)zone->type, zone->start);
I guess that means drive-managed SMR disks don't export zone info at
all?
--D
