Re: [PATCH 29/45] xfs_repair: validate rt groups vs reported hardware zones

["Darrick J. Wong" <djwong@kernel.org>]

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