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
next prev parent 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