All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH] fstests: btrfs/260: detect subpage's limited compression support
Date: Tue,  2 Jan 2024 15:07:32 +1030	[thread overview]
Message-ID: <20240102043732.143225-1-wqu@suse.com> (raw)

[FALSE FAILURE]
When running test case btrfs/260 on a 64K page system (aarch64 with
64K page size config) and with 4K sector size, the test case would
always fail like this:

  FSTYP         -- btrfs
  PLATFORM      -- Linux/aarch64 btrfs-aarch64 6.7.0-rc5-custom+ #1 SMP PREEMPT_DYNAMIC Thu Dec 28 08:24:38 ACDT 2023
  MKFS_OPTIONS  -- -s 4k /dev/mapper/test-scratch1
  MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/mapper/test-scratch1 /mnt/scratch

  btrfs/260       - output mismatch (see ~/xfstests-dev/results//btrfs/260.out.bad)
      --- tests/btrfs/260.out	2023-12-28 10:39:36.510027101 +1030
      +++ ~/xfstests-dev/results//btrfs/260.out.bad	2024-01-02 15:02:12.917656055 +1030
      @@ -1,2 +1,8 @@
       QA output created by 260
      +file "/mnt/scratch/fragment" offset 0 doesn't have expected string "compression 2"
      +file "/mnt/scratch/fragment" offset 32768 doesn't have expected string "compression 2"
      +file "/mnt/scratch/fragment" offset 65536 doesn't have expected string "compression 2"
      +file "/mnt/scratch/fragment" offset 0 doesn't have expected string "compression 3"
      +file "/mnt/scratch/fragment" offset 32768 doesn't have expected string "compression 3"
      +file "/mnt/scratch/fragment" offset 65536 doesn't have expected string "compression 3"
      ...
      (Run 'diff -u ~/xfstests-dev/tests/btrfs/260.out ~/xfstests-dev/results//btrfs/260.out.bad'  to see the entire diff)
  Ran: btrfs/260
  Failures: btrfs/260
  Failed 1 of 1 tests

[CAUSE]
Since the introduce of btrfs subpage support, compression support is
always limited.

The big limitation is, the range can only be compressed if it's page
aligned (not sector aligned).
This limitation is caused by the delalloc implementation for now, and I
believe it can be resolved in the long time.

[FIX]
Introduce a new helper, _require_btrfs_compress_extent_size(), to make
sure btrfs can compress certain sized extent.

If such extent can not be compressed, just skip the test case.
Now on x86_64 the test case can pass as usual, while on 64K page sized
system (and 4K sector size) it would be skipped.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 common/btrfs    | 24 ++++++++++++++++++++++++
 tests/btrfs/260 |  5 +++++
 2 files changed, 29 insertions(+)

diff --git a/common/btrfs b/common/btrfs
index f91f8dd8..c3e801fa 100644
--- a/common/btrfs
+++ b/common/btrfs
@@ -775,3 +775,27 @@ _has_btrfs_sysfs_feature_attr()
 
 	test -e /sys/fs/btrfs/features/$feature_attr
 }
+
+# Btrfs subpage support can not compress extent smaller than a page (at least
+# for now).
+# Make sure we can detect the situation correctly.
+_require_btrfs_compress_extent_size()
+{
+	local extent_size=$1
+
+	_scratch_mkfs >>$seqres.full 2>&1
+	_scratch_mount -o compress
+
+	$XFS_IO_PROG -f -c "pwrite -b ${extent_size} 0 ${extent_size}" \
+			$SCRATCH_MNT/foo &> /dev/null
+	sync
+	$XFS_IO_PROG -c "fiemap -v" $SCRATCH_MNT/foo | tail -n 1 > $tmp.fiemap
+	_scratch_unmount
+
+	# 0x8 means encoded (in our case compressed), 0x1 means the last extent.
+	if ! grep -q "0x9" $tmp.fiemap; then
+		rm -f -- $tmp.fiemap
+		_notrun "Compression for extent size $extent_size not supported, maybe subpage?"
+	fi
+	rm -f -- $tmp.fiemap
+}
diff --git a/tests/btrfs/260 b/tests/btrfs/260
index 111a3bd6..81ff599c 100755
--- a/tests/btrfs/260
+++ b/tests/btrfs/260
@@ -83,6 +83,11 @@ check_hole()
 # Needs 4K sectorsize as the test is crafted using that sectorsize
 _require_btrfs_support_sectorsize 4096
 
+# The test case needs to create compressed extents in 16K size
+# (before compression). Some subpage page size (64K, 32K) can not handle
+# it yet.
+_require_btrfs_compress_extent_size 16K
+
 _scratch_mkfs -s 4k >> $seqres.full 2>&1
 
 # Initial data is compressed using lzo
-- 
2.42.0


             reply	other threads:[~2024-01-02  4:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02  4:37 Qu Wenruo [this message]
2024-01-04  7:19 ` [PATCH] fstests: btrfs/260: detect subpage's limited compression support Anand Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240102043732.143225-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.