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@xxxxxxxxxxxxxx>
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
