btrfs/156: require no compress
authorJosef Bacik <josef@toxicpanda.com>
Mon, 29 Nov 2021 15:27:58 +0000 (10:27 -0500)
committerEryu Guan <guaneryu@gmail.com>
Sun, 5 Dec 2021 13:51:29 +0000 (21:51 +0800)
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>
tests/btrfs/156

index 11bf4638c7d1f86b5ccab6f69b2244b41ac24e43..4f323f3703de59f47365a793c0065b60d1c7a404 100755 (executable)
@@ -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))