From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH] fstests: btrfs/226: skip the test for bs > ps cases
Date: Tue, 9 Dec 2025 18:55:04 +1030 [thread overview]
Message-ID: <20251209082504.107995-1-wqu@suse.com> (raw)
[RANDOM FAILURE]
Sometimes btrfs/226 can fail but sometimes it can also pass with 8K
fs block size and 4K page size:
[adam@btrfs-vm xfstests]$ sudo ./check btrfs/226
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 btrfs-vm 6.18.0-custom+ #323 SMP PREEMPT_DYNAMIC Mon Dec 8 07:38:30 ACDT 2025
MKFS_OPTIONS -- -s 8k /dev/mapper/test-scratch1
MOUNT_OPTIONS -- /dev/mapper/test-scratch1 /mnt/scratch
btrfs/226 2s ... 3s
Ran: btrfs/226
Passed all 1 tests
[adam@btrfs-vm xfstests]$ sudo ./check btrfs/226
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 btrfs-vm 6.18.0-custom+ #323 SMP PREEMPT_DYNAMIC Mon Dec 8 07:38:30 ACDT 2025
MKFS_OPTIONS -- -s 8k /dev/mapper/test-scratch1
MOUNT_OPTIONS -- /dev/mapper/test-scratch1 /mnt/scratch
btrfs/226 3s ... - output mismatch (see /home/adam/xfstests/results//btrfs/226.out.bad)
--- tests/btrfs/226.out 2024-04-12 14:04:03.080000035 +0930
+++ /home/adam/xfstests/results//btrfs/226.out.bad 2025-12-09 18:46:44.416878799 +1030
@@ -39,14 +39,11 @@
Testing write against prealloc extent at eof
wrote 65536/65536 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 65536
-XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+pwrite: Resource temporarily unavailable
File after write:
...
(Run 'diff -u /home/adam/xfstests/tests/btrfs/226.out /home/adam/xfstests/results//btrfs/226.out.bad' to see the entire diff)
Ran: btrfs/226
Failures: btrfs/226
Failed 1 of 1 tests
[CAUSE]
For the failure case, the failure is from check_direct_IO(), which find
out that the buffer provided is only aligned to PAGE_SIZE (4K), not to the
fs block size (8K).
The user space can only ensure the allocated memory is contiguous in the
user space, but the user space can not ensure the underlying physical
memory layout, thus depending on the memory allocation situation, the
user space can not always get physically contiguous memory, and fail the
check_direct_IO() call.
After failed check_direct_IO(), we fall back to buffered IO, but since
this particular test case is using RWF_NOWAIT, rejecting buffered IO
fallback, the direct IO failed with -EAGAIN.
[FIX]
Since we can not ensure the physical memory layout for direct IO, just
skip this test case if the fs block size is larger than page size.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
tests/btrfs/226 | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tests/btrfs/226 b/tests/btrfs/226
index afab5868..110a1239 100755
--- a/tests/btrfs/226
+++ b/tests/btrfs/226
@@ -26,6 +26,10 @@ _scratch_mkfs >>$seqres.full 2>&1
# nodatasum (otherwise it falls back to buffered IO).
_scratch_mount -o nodatasum
+if [ "$(_get_block_size $SCRATCH_MNT)" -gt "$(_get_page_size)" ]; then
+ _notrun "fs block size larger than page size, unreliable direct IO buffer alignment"
+fi
+
# Test a write against COW file/extent - should fail with -EAGAIN. Disable the
# NOCOW attribute of the file just in case MOUNT_OPTIONS has "-o nodatacow".
echo "Testing write against COW file"
--
2.51.2
next reply other threads:[~2025-12-09 8:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 8:25 Qu Wenruo [this message]
2025-12-11 18:15 ` [PATCH] fstests: btrfs/226: skip the test for bs > ps cases David Sterba
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=20251209082504.107995-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