[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@xxxxxxxx>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1233303
Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
---
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
