From: "Darrick J. Wong" <djwong@kernel.org>
To: zlang@redhat.com, Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH v2 1/3] xfs/178: don't fail when SCRATCH_DEV contains random xfs superblocks
Date: Thu, 12 Oct 2023 08:09:22 -0700 [thread overview]
Message-ID: <20231012150922.GF21298@frogsfrogsfrogs> (raw)
In-Reply-To: <169687551395.3948976.8425812597156927952.stgit@frogsfrogsfrogs>
From: Darrick J. Wong <djwong@kernel.org>
When I added an fstests config for "RAID" striping (aka MKFS_OPTIONS='-d
su=128k,sw=4'), I suddenly started seeing this test fail sporadically
with:
--- /tmp/fstests/tests/xfs/178.out 2023-07-11 12:18:21.714970364 -0700
+++ /var/tmp/fstests/xfs/178.out.bad 2023-07-25 22:05:39.756000000 -0700
@@ -10,6 +10,20 @@ bad primary superblock - bad magic numbe
attempting to find secondary superblock...
found candidate secondary superblock...
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb root inode INO inconsistent with calculated value INO
Eventually I tracked this down to a mis-interaction between the test,
xfs_repair, and the storage device.
If the device doesn't support discard, _scratch_mkfs won't zero the
entire disk to remove old dead superblocks that might have been written
by previous tests. After we shatter the primary super, the xfs_repair
scanning code can still trip over those old supers when it goes looking
for secondary supers.
Most of the time it finds the actual AG 1 secondary super, but sometimes
it finds ghosts from previous formats. When that happens, xfs_repair
will talk quite a bit about those failed secondaries, even if it
eventually finds an acceptable secondary sb and completes the repair.
Filter out the messages about secondary supers.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
v2: fix commit message to identify the problem in fstests, drop the
irrelevant mumbbling about SCSI UNMAP
---
tests/xfs/178 | 9 ++++++++-
tests/xfs/178.out | 2 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tests/xfs/178 b/tests/xfs/178
index a65197cde3..fee1e92bf3 100755
--- a/tests/xfs/178
+++ b/tests/xfs/178
@@ -10,13 +10,20 @@
. ./common/preamble
_begin_fstest mkfs other auto
+filter_repair() {
+ _filter_repair | sed \
+ -e '/unable to verify superblock, continuing/d' \
+ -e '/found candidate secondary superblock/d' \
+ -e '/error reading superblock.*-- seek to offset/d'
+}
+
# dd the 1st sector then repair
_dd_repair_check()
{
#dd first sector
dd if=/dev/zero of=$1 bs=$2 count=1 2>&1 | _filter_dd
#xfs_repair
- _scratch_xfs_repair 2>&1 | _filter_repair
+ _scratch_xfs_repair 2>&1 | filter_repair
#check repair
if _check_scratch_fs; then
echo "repair passed"
diff --git a/tests/xfs/178.out b/tests/xfs/178.out
index 0bebe553eb..711e90cc26 100644
--- a/tests/xfs/178.out
+++ b/tests/xfs/178.out
@@ -9,7 +9,6 @@ Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
-found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb root inode INO inconsistent with calculated value INO
@@ -45,7 +44,6 @@ Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
-found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb root inode INO inconsistent with calculated value INO
next prev parent reply other threads:[~2023-10-12 15:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 18:18 [PATCHSET 0/3] fstests: random fixes for v2023.10.08 Darrick J. Wong
2023-10-09 18:18 ` [PATCH 1/3] xfs/178: don't fail when SCRATCH_DEV contains random xfs superblocks Darrick J. Wong
2023-10-10 7:01 ` Christoph Hellwig
2023-10-11 19:10 ` Darrick J. Wong
2023-10-12 4:26 ` Christoph Hellwig
2023-10-12 5:03 ` Darrick J. Wong
2023-10-12 8:30 ` Christoph Hellwig
2023-10-12 15:09 ` Darrick J. Wong [this message]
2023-10-12 15:10 ` [PATCH v2 " Christoph Hellwig
2023-10-09 18:18 ` [PATCH 2/3] generic/465: only complain about stale disk contents when racing directio Darrick J. Wong
2023-10-10 7:03 ` Christoph Hellwig
2023-10-09 18:18 ` [PATCH 3/3] generic/269,xfs/051: don't drop fsstress failures to stdout Darrick J. Wong
2023-10-10 7:03 ` Christoph Hellwig
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=20231012150922.GF21298@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
--cc=hch@infradead.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