From: fdmanana@kernel.org
To: fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH] btrfs/280: run defrag after creating file to get expected extent layout
Date: Wed, 5 Jun 2024 12:26:20 +0100 [thread overview]
Message-ID: <837d97d52fee15653d1dac216d1d75a14bb1916d.1717586749.git.fdmanana@suse.com> (raw)
From: Filipe Manana <fdmanana@suse.com>
The test writes a 128M file and expects to end up with 1024 extents, each
with a size of 128K, which is the maximum size for compressed extents.
Generally this is what happens, but often it's possibly for writeback to
kick in while creating the file (due to memory pressure, or something
calling sync in parallel, etc) which may result in creating more and
smaller extents, which makes the test fail since its golden output
expects exactly 1024 extents with a size of 128K each.
So to work around run defrag after creating the file, which will ensure
we get only 128K extents in the file.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
tests/btrfs/280 | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tests/btrfs/280 b/tests/btrfs/280
index d4f613ce..0f7f8a37 100755
--- a/tests/btrfs/280
+++ b/tests/btrfs/280
@@ -13,7 +13,7 @@
# the backref walking code, used by fiemap to determine if an extent is shared.
#
. ./common/preamble
-_begin_fstest auto quick compress snapshot fiemap
+_begin_fstest auto quick compress snapshot fiemap defrag
. ./common/filter
. ./common/punch # for _filter_fiemap_flags
@@ -36,6 +36,14 @@ _scratch_mount -o compress
# extent tree (if the root was a leaf, we would have only data references).
$XFS_IO_PROG -f -c "pwrite -b 1M 0 128M" $SCRATCH_MNT/foo | _filter_xfs_io
+# While writing the file it's possible, but rare, that writeback kicked in due
+# to memory pressure or a concurrent sync call for example, so we may end up
+# with extents smaller than 128K (the maximum size for compressed extents) and
+# therefore make the test expectations fail because we get more extents than
+# what the golden output expects. So run defrag to make sure we get exactly
+# the expected number of 128K extents (1024 extents).
+$BTRFS_UTIL_PROG filesystem defrag "$SCRATCH_MNT/foo" >> $seqres.full
+
# Create a RW snapshot of the default subvolume.
_btrfs subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap
--
2.43.0
next reply other threads:[~2024-06-05 11:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 11:26 fdmanana [this message]
2024-06-05 12:10 ` [PATCH] btrfs/280: run defrag after creating file to get expected extent layout David Disseldorp
2024-06-05 15:27 ` David Sterba
2024-06-05 22:30 ` Qu Wenruo
2024-06-05 23:17 ` Filipe Manana
2024-06-06 0:52 ` Qu Wenruo
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=837d97d52fee15653d1dac216d1d75a14bb1916d.1717586749.git.fdmanana@suse.com \
--to=fdmanana@kernel.org \
--cc=fdmanana@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).