Re: [PATCH v2] fstests: generic/746: skip if btrfs' new block-group-tree is involved

[Qu Wenruo <wqu@suse.com>]

This is replaced by this newer patch:

  https://lore.kernel.org/linux-btrfs/20251128063137.67274-1-wqu@suse.com/

The newer patch adds proper block-group-tree support by a new python 
based script, that accepts an extra block group tree dump to properly 
handle the block group boundary case.

Thanks,
Qu

在 2025/11/28 08:26, Qu Wenruo 写道:
> [FALSE ALERT]
> The test case will fail on btrfs if the new block-group-tree feature is
> enabled:
> 
> FSTYP         -- btrfs
> PLATFORM      -- Linux/x86_64 btrfs-vm 6.18.0-rc6-custom+ #321 SMP PREEMPT_DYNAMIC Sun Nov 23 16:34:33 ACDT 2025
> MKFS_OPTIONS  -- -O block-group-tree /dev/mapper/test-scratch1
> MOUNT_OPTIONS -- /dev/mapper/test-scratch1 /mnt/scratch
> 
> generic/746 44s ... [failed, exit status 1]- output mismatch (see xfstests-dev/results//generic/746.out.bad)
>      --- tests/generic/746.out	2024-06-27 13:55:51.286338519 +0930
>      +++ xfstests-dev/results//generic/746.out.bad	2025-11-28 07:47:17.039827837 +1030
>      @@ -2,4 +2,4 @@
>       Generating garbage on loop...done.
>       Running fstrim...done.
>       Detecting interesting holes in image...done.
>      -Comparing holes to the reported space from FS...done.
>      +Comparing holes to the reported space from FS...Sectors 256-2111 are not marked as free!
>      ...
>      (Run 'diff -u xfstests-dev/tests/generic/746.out xfstests-dev/results//generic/746.out.bad'  to see the entire diff)
> 
> [CAUSE]
> Sectors [256, 2048) are the reserved 1M free space.
> Sectors [2048, 2112) are the leading free space in the chunk tree.
> Sectors [2112, 2144) is the first tree block in the chunk tree.
> 
> However the reported free sectors from get_free_sectors() looks like this:
> 
>    2144 10566
>    10688 11711
>    ...
> 
> Note that there should be a free sector range in [2048, 2112) but it's
> not reported in get_free_sectors().
> 
> The get_free_sectors() call is fs dependent, and for btrfs it's using
> parse-extent-tree.awk script to handle the extent tree dump.
> 
> The script uses BLOCK_GROUP_ITEM items to detect the beginning of a
> block group so that it can calculate the hole between the bginning of a
> block group and the first data/metadata item.
> 
> However block-group-tree feature moves BLOCK_GROUP_ITEM items to a
> dedicated tree, making the existing script unable to parse the free
> space at the beginning of a block group.
> 
> [FIX]
> For block-group-tree feature, we need to parse both block group tree and
> extent tree and do cross-reference.
> It is not that simple to do in a single awk script, so unfortunately
> skip the test if the btrfs has block-group-tree feature enabled.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> Changelog
> v2:
> - Fix several typos in the commit message
>    Mostly related to the sequence between 1 and 2, have all kinds of typos
>    like: 2122 (should be 2112) 1244 (should be 2144)
> ---
>   tests/generic/746 | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/tests/generic/746 b/tests/generic/746
> index 6f02b1cc3547..c62fdbc9de20 100755
> --- a/tests/generic/746
> +++ b/tests/generic/746
> @@ -162,6 +162,18 @@ mkdir $loop_mnt
>   _mkfs_dev $loop_dev
>   _mount $loop_dev $loop_mnt
>   
> +# The new block-group-tree will feature screw up the extent tree parsing, as
> +# there is no more block group item in that tree to mark the start
> +# of a block group, causing the free space between the beginning of bg
> +# and the first data/metadata block not counted as free space.
> +# So reject fs with block-group-tree feature for now.
> +if [ $FSTYP = "btrfs" ]; then
> +	if $BTRFS_UTIL_PROG inspect-internal dump-super $loop_dev |\
> +		grep -q BLOCK_GROUP_TREE; then
> +		_notrun "No support for block-group-tree extent tree parsing yet"
> +	fi
> +fi
> +
>   echo -n "Generating garbage on loop..."
>   # Goal is to fill it up, ignore any errors.
>   for i in `seq 1 10`; do