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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.