btrfs/321: make the filter to handle older btrfs-progs

[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>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

diff --git a/tests/btrfs/321 b/tests/btrfs/321
index c13ccc1e9472012e6e80d6b58e347c18b9996fc2..35caade6473cfc82af862505edaf44e5a6e374d1 100755 (executable)
--- 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"