Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: zlang@redhat.com, fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/4] xfs/432: fix metadump loop device blocksize problems
Date: Thu, 22 May 2025 11:08:14 +1000	[thread overview]
Message-ID: <aC54_ucTlwh189MG@dread.disaster.area> (raw)
In-Reply-To: <174786719464.1398726.8513251082673880762.stgit@frogsfrogsfrogs>

On Wed, May 21, 2025 at 03:41:51PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Make sure the lba size of the loop devices created for the metadump
> tests actually match that of the real SCRATCH_ devices or else the tests
> will fail.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  common/metadump |   12 ++++++++++--
>  common/rc       |    7 +++++++
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/common/metadump b/common/metadump
> index 61ba3cbb91647c..4ae03c605563fc 100644
> --- a/common/metadump
> +++ b/common/metadump
> @@ -76,6 +76,7 @@ _xfs_verify_metadump_v1()
>  
>  	# Create loopdev for data device so we can mount the fs
>  	METADUMP_DATA_LOOP_DEV=$(_create_loop_device $data_img)
> +	_force_loop_device_blocksize $METADUMP_DATA_LOOP_DEV $SCRATCH_DEV

That doesn't look right. You're passing the scratch device as a
block size parameter. 

>  
>  	# Mount fs, run an extra test, fsck, and unmount
>  	SCRATCH_DEV=$METADUMP_DATA_LOOP_DEV _scratch_mount
> @@ -123,12 +124,19 @@ _xfs_verify_metadump_v2()
>  
>  	# Create loopdev for data device so we can mount the fs
>  	METADUMP_DATA_LOOP_DEV=$(_create_loop_device $data_img)
> +	_force_loop_device_blocksize $METADUMP_DATA_LOOP_DEV $SCRATCH_DEV
>  
>  	# Create loopdev for log device if we recovered anything
> -	test -s "$log_img" && METADUMP_LOG_LOOP_DEV=$(_create_loop_device $log_img)
> +	if [ -s "$log_img" ]; then
> +		METADUMP_LOG_LOOP_DEV=$(_create_loop_device $log_img)
> +		_force_loop_device_blocksize $METADUMP_LOG_LOOP_DEV $SCRATCH_LOGDEV
> +	fi
>  
>  	# Create loopdev for rt device if we recovered anything
> -	test -s "$rt_img" && METADUMP_RT_LOOP_DEV=$(_create_loop_device $rt_img)
> +	if [ -s "$rt_img" ]; then
> +		METADUMP_RT_LOOP_DEV=$(_create_loop_device $rt_img)
> +		_force_loop_device_blocksize $METADUMP_RT_LOOP_DEV $SCRATCH_RTDEV
> +	fi
>  
>  	# Mount fs, run an extra test, fsck, and unmount
>  	SCRATCH_DEV=$METADUMP_DATA_LOOP_DEV SCRATCH_LOGDEV=$METADUMP_LOG_LOOP_DEV SCRATCH_RTDEV=$METADUMP_RT_LOOP_DEV _scratch_mount
> diff --git a/common/rc b/common/rc
> index 4e3917a298e072..9e27f7a4afba44 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -4527,6 +4527,8 @@ _create_loop_device()
>  }
>  
>  # Configure the loop device however needed to support the given block size.
> +# The first argument is the loop device; the second is either an integer block
> +# size, or a different block device whose blocksize we want to match.
>  _force_loop_device_blocksize()
>  {
>  	local loopdev="$1"
> @@ -4539,6 +4541,11 @@ _force_loop_device_blocksize()
>  		return 1
>  	fi
>  
> +	# second argument is really a bdev; copy its lba size
> +	if [ -b "$blksize" ]; then
> +		blksize="$(blockdev --getss "${blksize}")"
> +	fi

Oh, you're overloading the second parameter with different types -
that's pretty nasty.  It would be much cleaner to write a wrapper
function that extracts the block size from the device before calling
_force_loop_device_blocksize()....

-Dave.

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2025-05-22  1:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21 22:40 [PATCHSET 1/2] fstests: check new 6.15 behaviors Darrick J. Wong
2025-05-21 22:41 ` [PATCH 1/4] xfs/273: fix test for internal zoned filesystems Darrick J. Wong
2025-05-23  5:17   ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 2/4] xfs/259: drop the 512-byte fsblock logic from this test Darrick J. Wong
2025-05-23  5:17   ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 3/4] xfs/259: try to force loop device block size Darrick J. Wong
2025-05-22  1:21   ` Dave Chinner
2025-05-28 22:36     ` Darrick J. Wong
2025-05-23  5:19   ` Christoph Hellwig
2025-05-28 22:22     ` Darrick J. Wong
2025-06-02  5:07       ` Christoph Hellwig
2025-06-03 14:36         ` Darrick J. Wong
2025-06-03 14:37           ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 4/4] xfs/432: fix metadump loop device blocksize problems Darrick J. Wong
2025-05-22  1:08   ` Dave Chinner [this message]
2025-05-28 22:37     ` Darrick J. Wong
2025-07-10 16:16 ` [PATCHSET 1/2] fstests: check new 6.15 behaviors Darrick J. Wong
2025-07-10 18:26   ` Zorro Lang

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=aC54_ucTlwh189MG@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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