| Message ID | 175b1ef92bbd2a48e2efb80d0064ca91aab1402e.1637618880.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fstests: generic/260: don't fail for certain fstrim ops on btrfs | expand |
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
On Sun, Nov 28, 2021 at 11:19:50PM +0800, Eryu Guan wrote: > 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. Ack.
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")
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> --- tests/generic/260 | 7 +++++++ 1 file changed, 7 insertions(+)