aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2021-11-29 10:27:58 -0500
committerEryu Guan <guaneryu@gmail.com>2021-12-05 21:51:29 +0800
commit462886a9012cedf900ad1a200720ff3a5eea1497 (patch)
treee98a054109aac3a931aa3b51f0fe18da7bc03f3f
parent50cd778c0a3daf1e3723dc5800c9e9dc9b42a93f (diff)
downloadxfstests-dev-462886a9012cedf900ad1a200720ff3a5eea1497.tar.gz
btrfs/156: require no compress
This test fails on my overnight tests that use zlib, because the data usage doesn't get high enough for the fstrim math to work out. We are testing that fstrim properly trims the while file system when the block groups are relocated to > total_bytes. However it tries to validate this by making sure that we trim > total_bytes / 2, which we won't with compression on because we won't actually allocate total_bytes / 2. The free extents that are trimmed in the first go around don't get trimmed the second time. With some compression algorithms we move the free extents around enough that they'll get re-trimmed and thus pass, but others it won't work out properly. Simply require that we don't have compression enabled so that the results are consistent. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Eryu Guan <guaneryu@gmail.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
-rwxr-xr-xtests/btrfs/1567
1 files changed, 7 insertions, 0 deletions
diff --git a/tests/btrfs/156 b/tests/btrfs/156
index 11bf4638c7..4f323f3703 100755
--- a/tests/btrfs/156
+++ b/tests/btrfs/156
@@ -27,6 +27,13 @@ _supported_fs btrfs
_require_scratch
_require_fstrim
+# We need the allocated space to actually use that amount so the trim amount
+# comes out correctly. Because we mark free extents as TRIMMED we won't trim
+# the free extents on the second fstrim and thus we'll get a trimmed bytes at <
+# half of the device if we have compression enabled, even though fs trim did the
+# correct thing.
+_require_no_compress
+
# 1024fs size
fs_size=$((1024 * 1024 * 1024))