From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH 1/2] fstests: btrfs/131: add explicit v1 space cache requirement
Date: Fri, 26 Dec 2025 08:45:52 +1030 [thread overview]
Message-ID: <20251225221553.19254-2-wqu@suse.com> (raw)
In-Reply-To: <20251225221553.19254-1-wqu@suse.com>
The test case is utilizing v1 space cache, meanwhile v1 space cache
is already marked deprecated for a while since kernel commit
1e7bec1f7d65 ("btrfs: emit a warning about space cache v1 being
deprecated").
Furthermore quite some features are not compatible with v1 cache,
including the soon-to-be-default block-group-tree, and hardware
dependent zoned features.
Currently we reject those features for btrfs/131, but what we really
want is to only run the test case for supported features/kernels.
The current way to reject will not handle future kernels that completely
rejects v1 space cache.
Add a new helper, _require_btrfs_v1_cache() to do the check, which
checks the following criteria:
- "space_cache=v1" mount option is supported
And to handle default v2 cache behavior, also add "clear_cache".
If the kernel has completely dropped v1 cache support, such mount
should fail.
- Check if FREE_SPACE_TREE feature exists after above mount
For bs != ps cases, v2 cache is enforced to replace v1 cache, thus
we need to double check to make sure above mount didn't result v2
cache.
- Check if cache generation is correct
If v1 cache is working, the cache_generation should be some valid
value other than 0 nor (u64)-1.
And replace the existing checks on zoned and block-group-tree with the
new one.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
common/btrfs | 25 +++++++++++++++++++++++++
tests/btrfs/131 | 7 +------
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/common/btrfs b/common/btrfs
index 6a1095ff..c2d616aa 100644
--- a/common/btrfs
+++ b/common/btrfs
@@ -630,6 +630,31 @@ _btrfs_no_v1_cache_opt()
echo -n "-onospace_cache"
}
+# v1 space cache is already deprecated and will be removed soon. Furthermore
+# the soon-to-be-default block-group-tree has dependency on v2 space cache, and
+# will reject v1 cache mount option.
+# Make sure v1 space cache is still supported for test cases still utilizing
+# v1 space cache.
+_require_btrfs_v1_cache()
+{
+ _scratch_mkfs &> /dev/null
+ _try_scratch_mount -o clear_cache,space_cache=v1 || _notrun "v1 space cache is not supported"
+ _scratch_unmount
+
+ # Make sure no FREE_SPACE_TREE enabled.
+ if $BTRFS_UTIL_PROG inspect-internal dump-super $SCRATCH_DEV |\
+ grep -q "FREE_SPACE_TREE"; then
+ _notrun "v1 space cache is not supported"
+ fi
+
+ # Make sure the cache generation is not 0 nor -1.
+ local cache_gen=$($BTRFS_UTIL_PROG inspect-internal dump-super $SCRATCH_DEV |\
+ grep "cache_generation" | $AWK_PROG '{ print $2 }' )
+ if [ "$cache_gen" -eq 0 -o $(( $test_num + 1 )) -eq 0 ]; then
+ _notrun "v1 space cache is not supported"
+ fi
+}
+
# Require certain sectorsize support
_require_btrfs_support_sectorsize()
{
diff --git a/tests/btrfs/131 b/tests/btrfs/131
index b4756a5f..026d11e6 100755
--- a/tests/btrfs/131
+++ b/tests/btrfs/131
@@ -14,14 +14,9 @@ _begin_fstest auto quick
_require_scratch
_require_btrfs_command inspect-internal dump-super
_require_btrfs_fs_feature free_space_tree
-# Zoned btrfs does not support space_cache(v1)
-_require_non_zoned_device "${SCRATCH_DEV}"
-# Block group tree does not support space_cache(v1)
-_require_btrfs_no_block_group_tree
+_require_btrfs_v1_cache
_scratch_mkfs >/dev/null 2>&1
-[ "$(_get_page_size)" -gt "$(_scratch_btrfs_sectorsize)" ] && \
- _notrun "cannot run with subpage sectorsize"
mkfs_v1()
{
--
2.51.2
next prev parent reply other threads:[~2025-12-25 22:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 22:15 [PATCH 0/2] fstests: btrfs: make space cache related tests future proof Qu Wenruo
2025-12-25 22:15 ` Qu Wenruo [this message]
2026-01-18 18:30 ` [PATCH 1/2] fstests: btrfs/131: add explicit v1 space cache requirement Zorro Lang
2025-12-25 22:15 ` [PATCH 2/2] fstests: btrfs: add a new test case that is future-proof Qu Wenruo
2026-01-18 18:31 ` 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=20251225221553.19254-2-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