Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Carlos Maiolino <cem@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: hch@lst.de, stable@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: fix media verification ioctl for internal rt volumes
Date: Mon, 31 Aug 2026 08:59:56 +0200	[thread overview]
Message-ID: <apUmXKFPrBJJQnd6@andromeda.toxiclabs.cc> (raw)
In-Reply-To: <20260821035806.GJ6072@frogsfrogsfrogs>

On Thu, Aug 20, 2026 at 08:58:06PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> 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.  We don't account for an
> internal realtime section, so the kernel doesn't scan any part of it.
> Oops.
> 
> Reproducer:
> 
>  # mkfs.xfs -f /dev/sda -r zoned=1 -d rtinherit=1
>  # mount /dev/sda /mnt
>  # dd if=/dev/zero of=/mnt/a bs=1024k count=100
>  # sync
>  # xfs_info /mnt
>  meta-data=/dev/sda               isize=512    agcount=4, agsize=32768 blks
>           =                       sectsz=512   attr=2, projid32bit=1
>           =                       crc=1        finobt=1, sparse=1, rmapbt=1
>           =                       reflink=0    bigtime=1 inobtcount=1 nrext64=1
>           =                       exchange=1   metadir=1
>  data     =                       bsize=4096   blocks=131072, imaxpct=25
>           =                       sunit=0      swidth=0 blks
>  naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
>  log      =internal log           bsize=4096   blocks=16384, version=2
>           =                       sectsz=512   sunit=0 blks, lazy-count=1
>  realtime =internal               extsz=4096   blocks=1114112, rtextents=1114112
>           =                       rgcount=17   rgsize=65536 extents
>           =                       zoned=1      start=131072 reserved=53248
> 
> IOWS: 512M data volume, 3.1G internal rt section.  Now let's try some
> media verification:
> 
>  # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt
>  verified 536870912/536870912 bytes at offset 0
>  512 MiB, 1 ops; 0.0496 sec (10.067 GiB/sec and 20.1345 ops/sec)
>  verified 536870912/536870912 bytes at offset 0
>  512 MiB, 1 ops; 0.0409 sec (12.222 GiB/sec and 24.4439 ops/sec)
> 
> Notice how xfs_io says we only verified 512M of the rt volume?  If you
> run btrace in the background you'll see that we read the first 512M of
> the volume (aka the data section) twice and never read anything from the
> rt section.
> 
> An earlier fix tried messing with the buftarg geometry, but I've decided
> on a more targetted fix for the media verification code.  All we have to
> do is calculate the starting and ending daddr for the device that we're
> verifying, and clamp the user's input values to that range.  This leads
> to some bogosity in the output reporting:
> 
>  # xfs_io -c 'verifymedia -d' -c 'verifymedia -r' /mnt/t
>  verified 536870912/536870912 bytes at offset 0
>  512 MiB, 1 ops; 0.0606 sec (8.248 GiB/sec and 16.4968 ops/sec)
>  verified 5100273664/5100273664 bytes at offset 0
>  4.750 GiB, 1 ops; 0.3329 sec (14.267 GiB/sec and 3.0035 ops/sec)
> 
> Because we don't have a way to report that we didn't really do anything
> at all for that first 512M of address space of the rt "device".  But at
> least we're no longer ignoring real media.
> 
> (Note that the fsmap/bmap/fiemap calls all report physical addresses for
> the internal rt volume as offsets from the start of the data device, and
> the media verifier call consumes the same.  We baked that into the
> user-visible behavior in 6.15, so we're stuck with that sparse hole at
> the beginning.)
> 
> Cc: <stable@vger.kernel.org> # v6.15
> Fixes: bdc03eb5f98f6f ("xfs: allow internal RT devices for zoned mode")
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>

Looks good:

Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>

> ---
>  fs/xfs/xfs_verify_media.c |   24 +++++++++++++++++-------
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/xfs/xfs_verify_media.c b/fs/xfs/xfs_verify_media.c
> index 5ead3976d51151..b75c81f8fcc037 100644
> --- a/fs/xfs/xfs_verify_media.c
> +++ b/fs/xfs/xfs_verify_media.c
> @@ -268,6 +268,8 @@ xfs_verify_media(
>  	struct xfs_buftarg	*btp = NULL;
>  	struct bio		*bio;
>  	struct folio		*folio;
> +	xfs_daddr_t		dev_start = 0;
> +	xfs_daddr_t		dev_end = 0;
>  	xfs_daddr_t		daddr;
>  	uint64_t		bbcount;
>  	int			error = 0;
> @@ -277,24 +279,33 @@ xfs_verify_media(
>  	switch (me->me_dev) {
>  	case XFS_DEV_DATA:
>  		btp = mp->m_ddev_targp;
> +		dev_end = XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks);
>  		break;
>  	case XFS_DEV_LOG:
> -		if (mp->m_logdev_targp != mp->m_ddev_targp)
> +		if (mp->m_logdev_targp != mp->m_ddev_targp) {
>  			btp = mp->m_logdev_targp;
> +			dev_end = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks);
> +		}
>  		break;
>  	case XFS_DEV_RT:
>  		btp = mp->m_rtdev_targp;
> +		dev_start = XFS_FSB_TO_BB(mp, mp->m_sb.sb_rtstart);
> +		dev_end = XFS_FSB_TO_BB(mp, mp->m_sb.sb_rtstart +
> +					    mp->m_sb.sb_rblocks);
>  		break;
>  	}
>  	if (!btp)
>  		return -ENODEV;
>  
>  	/*
> -	 * If the caller told us to verify beyond the end of the disk, tell the
> -	 * user exactly where that was.
> +	 * If the caller told us to verify before the start or beyond the end
> +	 * of the disk volume, tell the user exactly where the volume starts
> +	 * and ends.
>  	 */
> -	if (me->me_end_daddr > btp->bt_nr_sectors)
> -		me->me_end_daddr = btp->bt_nr_sectors;
> +	if (me->me_end_daddr > dev_end)
> +		me->me_end_daddr = dev_end;
> +	if (me->me_start_daddr < dev_start)
> +		me->me_start_daddr = dev_start;
>  
>  	/* start and end have to be aligned to the lba size */
>  	if (!IS_ALIGNED(BBTOB(me->me_start_daddr | me->me_end_daddr),
> @@ -323,8 +334,7 @@ xfs_verify_media(
>  	 *    verifying.
>  	 */
>  	daddr = me->me_start_daddr;
> -	bbcount = min_t(sector_t, me->me_end_daddr, btp->bt_nr_sectors) -
> -			  me->me_start_daddr;
> +	bbcount = me->me_end_daddr - me->me_start_daddr;
>  
>  	folio = xfs_verify_alloc_folio(xfs_verify_iosize(me, btp, bbcount));
>  	if (!folio)
> 

  parent reply	other threads:[~2026-08-31  7:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  3:58 [PATCH] xfs: fix media verification ioctl for internal rt volumes Darrick J. Wong
2026-08-24  4:50 ` Christoph Hellwig
2026-08-24  5:31   ` Darrick J. Wong
2026-08-31  6:59 ` Carlos Maiolino [this message]
2026-09-03  6:05 ` Carlos Maiolino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apUmXKFPrBJJQnd6@andromeda.toxiclabs.cc \
    --to=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox