diff mbox series

[2/3] xfs/155: discard stderr when checking for NEEDSREPAIR

Message ID 168609055400.2590724.12890017891103418739.stgit@frogsfrogsfrogs (mailing list archive)
State New, archived
Headers show
Series fstests: random fixes for v2023.05.28 | expand

Commit Message

Darrick J. Wong June 6, 2023, 10:29 p.m. UTC 
From: Darrick J. Wong <djwong@kernel.org>

This test deliberate crashes xfs_repair midway through writing metadata
to check that NEEDSREPAIR is always triggered by filesystem writes.
However, the subsequent scan for the NEEDSREPAIR feature bit prints
verifier errors to stderr.

On a filesystem with metadata directories, this leads to the test
failing with this recorded in the golden output:

+Metadata CRC error detected at 0x55c0a2dd0d38, xfs_dir3_block block 0xc0/0x1000
+dir block owner 0x82 doesnt match block 0xbb8cd37e44eb3623

This isn't specific to metadata directories -- any repair crash could
leave a metadata structure in a weird state such that starting xfs_db
will spray verifier errors.  For _check_scratch_xfs_features here, we
don't care if the filesystem is corrupt; we /only/ care that the
superblock feature bit is set.  Route all that noise to devnull.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/155 |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Andrey Albershteyn June 8, 2023, 9:12 a.m. UTC | #1 
On 2023-06-06 15:29:14, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> This test deliberate crashes xfs_repair midway through writing metadata
> to check that NEEDSREPAIR is always triggered by filesystem writes.
> However, the subsequent scan for the NEEDSREPAIR feature bit prints
> verifier errors to stderr.
> 
> On a filesystem with metadata directories, this leads to the test
> failing with this recorded in the golden output:
> 
> +Metadata CRC error detected at 0x55c0a2dd0d38, xfs_dir3_block block 0xc0/0x1000
> +dir block owner 0x82 doesnt match block 0xbb8cd37e44eb3623
> 
> This isn't specific to metadata directories -- any repair crash could
> leave a metadata structure in a weird state such that starting xfs_db
> will spray verifier errors.  For _check_scratch_xfs_features here, we
> don't care if the filesystem is corrupt; we /only/ care that the
> superblock feature bit is set.  Route all that noise to devnull.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---

Looks good to me.
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
diff mbox series

Patch

diff --git a/tests/xfs/155 b/tests/xfs/155
index c4ee8e20ef..25cc84069c 100755
--- a/tests/xfs/155
+++ b/tests/xfs/155
@@ -55,7 +55,7 @@  for ((nr_writes = 1; nr_writes < max_writes; nr_writes += nr_incr)); do
 	# but repair -n says the fs is clean, then it's possible that the
 	# injected error caused it to abort immediately after the write that
 	# cleared NEEDSREPAIR.
-	if ! _check_scratch_xfs_features NEEDSREPAIR > /dev/null &&
+	if ! _check_scratch_xfs_features NEEDSREPAIR &> /dev/null &&
 	   ! _scratch_xfs_repair -n &>> $seqres.full; then
 		echo "NEEDSREPAIR should be set on corrupt fs"
 	fi
@@ -63,7 +63,7 @@  done
 
 # If NEEDSREPAIR is still set on the filesystem, ensure that a full run
 # cleans everything up.
-if _check_scratch_xfs_features NEEDSREPAIR > /dev/null; then
+if _check_scratch_xfs_features NEEDSREPAIR &> /dev/null; then
 	echo "Clearing NEEDSREPAIR" >> $seqres.full
 	_scratch_xfs_repair 2>> $seqres.full
 	_check_scratch_xfs_features NEEDSREPAIR > /dev/null && \