Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH v3] fstests: btrfs: add a new test case to verify compressed read
Date: Wed, 27 Aug 2025 11:12:50 +0930	[thread overview]
Message-ID: <20250827014250.170552-1-wqu@suse.com> (raw)

The new test case is a regression test related to the block size < page
size handling of compressed read.

The test case will only be triggered with 64K page size and 4K btrfs
block size.
I'm using aarch64 with 64K page size to trigger the regression.

The test case will create the following file layout:

  base:
  [0, 64K): Single compressed data extent at bytenr X.

  new:
  [0, 32K): Reflinked from base [32K, 64K)
  [32K, 60K): Reflinked from base [0, 28K)
  [60K, 64K): New 4K write

  The range [0, 32K) and [32K, 64K) are pointing to the same compressed
  data.

  The last 4K write is a special workaround. It is a block aligned
  write, thus it will create the folio but without reading out the
  remaing part.

  This is to avoid readahead path, which has the proper fix.
  We want single folio read without readahead.

Then output the file "new" just after the last 4K write, then cycle
mount and output the content again.

For patched kernel, or with 4K page sized system, the test will pass,
the resulted content will not change during mount cycles.

For unpatched kernel and with 64K page size, the test will fail, the
content after the write will be incorrect (the range [32K, 60K) will be
zero), but after a mount cycle the content is correct again.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Changelog:
v3:
- Fix the golden output which is generated by an unpatched kernel

v2:
- Remove the unnecessary sync inherited from the kernel fix
- Use _hexdump instead of open-coded od dumps
- Use the correct 'clone' group instead of 'reflink'
- Minor grammar fixes
  All thanks to Filipe.
---
 tests/btrfs/337     | 55 +++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/337.out | 23 +++++++++++++++++++
 2 files changed, 78 insertions(+)
 create mode 100755 tests/btrfs/337
 create mode 100644 tests/btrfs/337.out

diff --git a/tests/btrfs/337 b/tests/btrfs/337
new file mode 100755
index 00000000..9c409e4d
--- /dev/null
+++ b/tests/btrfs/337
@@ -0,0 +1,55 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2025 SUSE Linux Products GmbH.  All Rights Reserved.
+#
+# FS QA Test 337
+#
+# Test compressed read with shared extents, especially for bs < ps cases.
+#
+. ./common/preamble
+_begin_fstest auto quick compress clone
+
+_fixed_by_kernel_commit xxxxxxxxxxxx \
+	"btrfs: fix corruption reading compressed range when block size is smaller than page size"
+
+. ./common/filter
+. ./common/reflink
+
+_require_btrfs_support_sectorsize 4096
+_require_scratch_reflink
+
+# The layout used in the test case is all 4K based, and can only be reproduced
+# with page size larger than 4K.
+_scratch_mkfs -s 4k >> $seqres.full
+_scratch_mount "-o compress"
+
+# Create the reflink source, which must be a compressed extent.
+$XFS_IO_PROG -f -c "pwrite -S 0x0f 0 32K" \
+		-c "pwrite -S 0xf0 32K 32K" \
+		$SCRATCH_MNT/base >> $seqres.full
+echo "Reflink source:"
+_hexdump $SCRATCH_MNT/base
+
+# Create the reflink dest, which reverses the order of the two 32K ranges.
+#
+# And do a further aligned write into the last block.
+# This write is to make sure the folio exists in filemap, so that we won't go
+# through the readahead path (which has the proper handling) for the folio.
+$XFS_IO_PROG -f -c "reflink $SCRATCH_MNT/base 32K 0 32K" \
+		-c "reflink $SCRATCH_MNT/base 0 32K 32K" \
+		-c "pwrite 60K 4K" $SCRATCH_MNT/new >> $seqres.full
+
+# This will result an incorrect output for unpatched kernel.
+# The range [32K, 60K) will be zero due to incorrectly merged compressed read.
+echo "Before mount cycle:"
+_hexdump $SCRATCH_MNT/new
+
+_scratch_cycle_mount
+
+# This will go through readahead path, which has the proper handling, thus give
+# the correct content.
+echo "After mount cycle:"
+_hexdump $SCRATCH_MNT/new
+
+status=0
+_exit 0
diff --git a/tests/btrfs/337.out b/tests/btrfs/337.out
new file mode 100644
index 00000000..cecbbbcf
--- /dev/null
+++ b/tests/btrfs/337.out
@@ -0,0 +1,23 @@
+QA output created by 337
+Reflink source:
+000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f  >................<
+*
+008000 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0  >................<
+*
+010000
+Before mount cycle:
+000000 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0  >................<
+*
+008000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f  >................<
+*
+00f000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  >................<
+*
+010000
+After mount cycle:
+000000 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0  >................<
+*
+008000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f  >................<
+*
+00f000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd  >................<
+*
+010000
-- 
2.49.0


             reply	other threads:[~2025-08-27  1:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27  1:42 Qu Wenruo [this message]
2025-08-27  8:48 ` [PATCH v3] fstests: btrfs: add a new test case to verify compressed read Filipe Manana
2025-08-27 16:30 ` Zorro Lang
2025-08-27 16:39   ` Zorro Lang

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=20250827014250.170552-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox