Re: [PATCH 5/6] xfs: adjust datadev sector count to reflect internal rt volumes

On Thu, Jul 30, 2026 at 10:22:04AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 29, 2026 at 10:27:20PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <[email protected]>
> > 
> > A media scan of a filesystem containing an internal rt volume produced
> > an error in xfs_scrub phase 6 complaining about a truncated realtime
> > device.  The rt device wasn't truncated, but the media scan code thought
> > we were trying to start a scan past the end of m_rtdev_targp.  That in
> > turn is an alias for m_ddev_targp, but in xfs_configure_buftarg we set
> > nr_sectors to the size of the data section.  Oops.
> > 
> > On these filesystems, the internal rt section comes immediately after
> > the data section.  We need to set the sector count for the data device
> > buftarg to the size of both sections.  Without this, media scans don't
> > work and media failure notifications from the kernel will be discarded
> > silently.
> > 
> > We also need to fix the superblock buffer recovery code to do the same.
> 
> This feels wrong.  Nothing should acess the internal rtdev through
> the data device buftarg.

It's the only one available, because xfs_setup_devices aliases
ddev_targp to rtdev_targp for internal rt volumes:

	if (mp->m_sb.sb_rtstart) {
		if (mp->m_rtdev_targp) {
			xfs_warn(mp,
		"can't use internal and external rtdev at the same time");
			return -EINVAL;
		}
		mp->m_rtdev_targp = mp->m_ddev_targp;
	}

So we're doing that anyway.  We could separate them by creating a second
buftarg with a duplicate struct file, but that would involve a bunch of
rototillingi because a fair amount of code changes behavior on
rtdev==ddev now.

The only field that the media verification code uses is bt_nr_sectors,
which it uses to trim verification requests to wherever the filesystem
thinks is the end of the device.  I could change that to call
bdev_nr_sectors() to fix the bug, but then we'd have to deal with media
failures for LBAs outside of the filesystem, which didn't seem ideal.

Also, if someone asynchronously reports a media error in the internal
rtdev to us through fs_holder_ops, the report will mention a range that
is beyond bt_nr_sectors but actually within the filesystem.
xfs_dax_notify_failure currently does the right thing because it doesn't
check bt_nr_sectors, but that also feels wrong. ;)

So I went with making bt_nr_sectors bigger because that felt the least
awkward.  IIRC it's supposed to represent the location of the end of the
filesystem on a particular blockdev, not the highest LBA that the fs
can xfs_buf_read(), right?

> Is this an LLM report bug, or did you actually run it using scrub?  If
> so can you help with the reproducer?

I found it accidentally while triaging another bug that LOLLM found.
I turned on the tracepoints (and btrace) for debugging and noticed that
it wasn't issuing reads for the internal rt device:

# mkfs.xfs /dev/sda -r zoned=1
# mount /dev/sda /mnt/scratch
# trace-cmd <big ugly command line> &
# xfs_io -x -c 'verifymedia -r' /mnt/scratch

--D