From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
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: Wed, 28 May 2025 15:37:57 -0700 [thread overview]
Message-ID: <20250528223757.GD8303@frogsfrogsfrogs> (raw)
In-Reply-To: <aC54_ucTlwh189MG@dread.disaster.area>
On Thu, May 22, 2025 at 11:08:14AM +1000, Dave Chinner wrote:
> 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()....
Or my preferred solution: a special purpose wrapper with a different
name that takes only a bdev path and has a comment that says it requires
a bdev path.
--D
>
> -Dave.
>
> --
> Dave Chinner
> david@fromorbit.com
>
next prev parent reply other threads:[~2025-05-28 22:37 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
2025-05-28 22:37 ` Darrick J. Wong [this message]
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=20250528223757.GD8303@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=david@fromorbit.com \
--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