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@xxxxxxxxxxxxxx> --- tests/btrfs/156 | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tests/btrfs/156 b/tests/btrfs/156 index 11bf4638..4f323f37 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)) -- 2.26.3
