Re: [PATCH] fstests: generic/260: don't fail for certain fstrim ops on btrfs

[Eryu Guan <guan@eryu.me>]

On Mon, Nov 22, 2021 at 05:08:10PM -0500, Josef Bacik wrote:
> We have always failed generic/260, because it tests to see if the file
> system will reject a trim range that is above the reported fs size.
> However for btrfs we will happily remap logical byte offsets within the
> file system, so you can end up with bye offsets past the end of the
> reported end of the file system.  Thus we do not fail these weird
> ranges.  We also don't have the concept of allocation groups, so the
> other test that tries to catch overflow doesn't apply to us either.  Fix
> this by simply using an offset that will fail (once a related kernel
> path is applied) for btrfs.  This will allow us to test the different
> overflow cases that do apply to btrfs, and not muddy up test results by
> giving us a false negative for the cases that do not apply to btrfs.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

I'd like an ACK from btrfs folks as well.

Thanks,
Eryu

> ---
>  tests/generic/260 | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/tests/generic/260 b/tests/generic/260
> index b15b4e57..b4d72e0f 100755
> --- a/tests/generic/260
> +++ b/tests/generic/260
> @@ -31,6 +31,7 @@ fssize=$($DF_PROG -k | grep "$SCRATCH_MNT" | grep "$SCRATCH_DEV"  | awk '{print
>  
>  beyond_eofs=$(_math "$fssize*2048")
>  max_64bit=$(_math "2^64 - 1")
> +[ $FSTYP == "btrfs" ] && beyond_eofs=$max_64bit
>  
>  # All these tests should return EINVAL
>  # since the start is beyond the end of
> @@ -128,6 +129,12 @@ case $FSTYP in
>  		len=$start
>  		export MKFS_OPTIONS="-f -d agsize=$(_math "$agsize*$bsize") -b size=$bsize"
>  		;;
> +	btrfs)
> +		# Btrfs doesn't care about any of this, just test max_64bit
> +		# since it'll fail
> +		start=$max_64bit
> +		len=$(_math "$start / 2")
> +		;;
>  	*)
>  		# (2^32-1) * 4096 * 65536 == 32bit max size * block size * ag size
>  		start=$(_math "(2^32 - 1) * 4096 * 65536")
> -- 
> 2.26.3