FS/XFS testing framework
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Cc: Long An <lan@suse.com>
Subject: [PATCH] btrfs/321: make the filter to handle older btrfs-progs
Date: Wed, 13 Nov 2024 19:58:38 +1030	[thread overview]
Message-ID: <20241113092838.302247-1-wqu@suse.com> (raw)

[FALSE ALERT]
With much older distros like SLE12SP5, which is using btrfs-progs 4.5.3,
test case btrfs/321 fails like this:

 btrfs/321       QA output created by 321
 unable to locate the last csum tree leaf
 (see /opt/xfstests/results//btrfs/321.full for details)
 [failed, exit status 1]- output mismatch (see /opt/xfstests/results//btrfs/321.out.bad)
     --- tests/btrfs/321.out	2024-10-28 07:03:54.000000000 -0400
     +++ /opt/xfstests/results//btrfs/321.out.bad	2024-11-07 09:33:58.238442033 -0500
     @@ -1,2 +1,3 @@
      QA output created by 321
     -Silence is golden
     +unable to locate the last csum tree leaf
     +(see /opt/xfstests/results//btrfs/321.full for details)
     ...
     (Run diff -u /opt/xfstests/tests/btrfs/321.out /opt/xfstests/results//btrfs/321.out.bad  to see the entire diff)

[CAUSE]
The full output shows the regular csum tree as usual:

 btrfs-progs v4.5.3+20160729
 checksum tree key (CSUM_TREE ROOT_ITEM 0)
 node 4247552 level 1 items 9 free 112 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
 	key (EXTENT_CSUM EXTENT_CSUM 20971520) block 4243456 (1036) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 25006080) block 4251648 (1038) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 29040640) block 4255744 (1039) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 33075200) block 4259840 (1040) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 37109760) block 4263936 (1041) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 41144320) block 4268032 (1042) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 45178880) block 4272128 (1043) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 49213440) block 4276224 (1044) gen 7
 	key (EXTENT_CSUM EXTENT_CSUM 53248000) block 4280320 (1045) gen 7
 leaf 4243456 items 1 free space 30 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
 	item 0 key (EXTENT_CSUM EXTENT_CSUM 20971520) itemoff 55 itemsize 3940
 		extent csum item
 [...]
 leaf 4280320 items 1 free space 2722 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
 	item 0 key (EXTENT_CSUM EXTENT_CSUM 53248000) itemoff 2747 itemsize 1248
 		extent csum item
 total bytes 25768755200
 bytes used 34213888
 uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48

But notice the header for each leaf, there is no flags for the leaf.
On newer btrfs-progs, the leaf header lines looks like this:

 leaf 5423104 items 1 free space 2918 generation 7 owner CSUM_TREE
 leaf 5423104 flags 0x1(WRITTEN) backref revision 1

It's two lines, not the old one line output.
The new behavior is introduced in btrfs-progs commit 9cc9c9ab3220
("btrfs-progs: print the eb flags for nodes as well"), included by v5.10
release.

So the test case doesn't handle older output format and failed to locate
the target leaf.

[FIX]
Instead of relying on the leaf flags line, use the much older
"leaf <bytenr> items" line as the filter target, so we can support much
older distros.

Reported-by: Long An <lan@suse.com>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1233303
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 tests/btrfs/321 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/btrfs/321 b/tests/btrfs/321
index c13ccc1e..35caade6 100755
--- a/tests/btrfs/321
+++ b/tests/btrfs/321
@@ -43,7 +43,7 @@ _scratch_unmount
 
 # Search for the last leaf of the csum tree, that will be the target to destroy.
 $BTRFS_UTIL_PROG inspect-internal dump-tree -t 7 $SCRATCH_DEV >> $seqres.full
-target_bytenr=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 7 $SCRATCH_DEV | grep "leaf.*flags" | sort | tail -n1 | cut -f2 -d\ )
+target_bytenr=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 7 $SCRATCH_DEV | grep "^leaf.*items" | sort | tail -n1 | cut -f2 -d\ )
 
 if [ -z "$target_bytenr" ]; then
 	_fail "unable to locate the last csum tree leaf"
-- 
2.46.0


             reply	other threads:[~2024-11-13  9:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13  9:28 Qu Wenruo [this message]
2024-11-13 11:49 ` [PATCH] btrfs/321: make the filter to handle older btrfs-progs Filipe Manana
2024-11-14  1:10 ` Anand Jain

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=20241113092838.302247-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=lan@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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