| Message ID | 20241113092838.302247-1-wqu@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | btrfs/321: make the filter to handle older btrfs-progs | expand |
On Wed, Nov 13, 2024 at 9:28 AM Qu Wenruo <wqu@suse.com> wrote: > > [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> Looks good, thanks. > --- > 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 > >
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Thx.
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"
[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(-)