[PATCH v2 0/4] btrfs: move some features out of experimental

[PATCH v2 0/4] btrfs: move some features out of experimental

[Qu Wenruo]

[CHANGELOG]
v2:
- Move bs < ps && bs != 4K out of experimental
  That feature is a pretty small niche though.
  The basis is already there from the bs < ps support for a while.

- Remove 2K block size support
  That is too niche, considering how easy to trigger subpage routine
  with the larger data folio support, there is not much need for it.

The following features can be moved out of experimental in v7.1:

- Large data folios
  It's introduced in v6.17, but we still have a bug fix related for it
  in v6.19.
  If there is no new bug exposed I believe it's time to expose this
  feature to end users.

- Shutdown and remove_bdev callbacks
  It's introduced in v6.19, but there is no major known bug exposed yet.
  Furthermore the remove_bdev callback, aka auto-shutdown/degradation
  when a device is missing, can affect end users.

  Thus we want some feedbacks from early adopters.

- Block size smaller than page size but not 4K support
  The requirement for 4K block size is purely artificial to reduce our
  test load.
  But since we're moving towards supporting all block sizes, the
  artifical limit can be lifted now.

Qu Wenruo (4):
  btrfs: drop 2K block size support
  btrfs: move shutdown and remove_bdev callbacks out of experimental
    features
  btrfs: move larger data folios out of experimental features
  btrfs: move block size < page size support out of experimental
    features

 fs/btrfs/Kconfig       |  4 +---
 fs/btrfs/btrfs_inode.h |  2 --
 fs/btrfs/fs.c          | 16 ++++------------
 fs/btrfs/fs.h          | 11 +----------
 fs/btrfs/super.c       |  4 ----
 5 files changed, 6 insertions(+), 31 deletions(-)

-- 
2.53.0

[PATCH v2 1/4] btrfs: drop 2K block size support

[Qu Wenruo]

Commit 306a75e647fe ("btrfs: allow debug builds to accept 2K block
size") added a new block size, 2K as the minimal block size if the
kernel is built with CONFIG_BTRFS_DEBUG.

This is to allow testing subpage routines on x86_64 (page size is fixed
at 4K).

But it turns out that the support is not that widely adopted, and there
are extra limits inside btrfs-progs, e.g. 2K node size is not supported.

Finally with the larger data folio support already in experimental
builds for a while, it's very easy to trigger a large folio and testing
subpage routines by just doing a 64K block sized buffered write.

Let's just remove the seldom utilized 2K block size completely.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/fs.c | 10 ++--------
 fs/btrfs/fs.h | 11 +----------
 2 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/fs/btrfs/fs.c b/fs/btrfs/fs.c
index 14d83565cdee..d7e7011a48c2 100644
--- a/fs/btrfs/fs.c
+++ b/fs/btrfs/fs.c
@@ -129,18 +129,12 @@ void btrfs_csum_final(struct btrfs_csum_ctx *ctx, u8 *out)
 /*
  * We support the following block sizes for all systems:
  *
- * - 4K
+ * - MIN_BLOCKSIZE (4K)
  *   This is the most common block size. For PAGE SIZE > 4K cases the subpage
  *   mode is used.
  *
  * - PAGE_SIZE
  *   The straightforward block size to support.
- *
- * And extra support for the following block sizes based on the kernel config:
- *
- * - MIN_BLOCKSIZE
- *   This is either 4K (regular builds) or 2K (debug builds)
- *   This allows testing subpage routines on x86_64.
  */
 bool __attribute_const__ btrfs_supported_blocksize(u32 blocksize)
 {
@@ -148,7 +142,7 @@ bool __attribute_const__ btrfs_supported_blocksize(u32 blocksize)
 	ASSERT(is_power_of_2(blocksize) && blocksize >= BTRFS_MIN_BLOCKSIZE &&
 	       blocksize <= BTRFS_MAX_BLOCKSIZE);
 
-	if (blocksize == PAGE_SIZE || blocksize == SZ_4K || blocksize == BTRFS_MIN_BLOCKSIZE)
+	if (blocksize == PAGE_SIZE || blocksize == BTRFS_MIN_BLOCKSIZE)
 		return true;
 #ifdef CONFIG_BTRFS_EXPERIMENTAL
 	/*
diff --git a/fs/btrfs/fs.h b/fs/btrfs/fs.h
index f2f4d5b747c5..3396ac6209ff 100644
--- a/fs/btrfs/fs.h
+++ b/fs/btrfs/fs.h
@@ -49,17 +49,8 @@ struct btrfs_subpage_info;
 struct btrfs_stripe_hash_table;
 struct btrfs_space_info;
 
-/*
- * Minimum data and metadata block size.
- *
- * Normally it's 4K, but for testing subpage block size on 4K page systems, we
- * allow DEBUG builds to accept 2K page size.
- */
-#ifdef CONFIG_BTRFS_DEBUG
-#define BTRFS_MIN_BLOCKSIZE	(SZ_2K)
-#else
+/* Minimum data and metadata block size. */
 #define BTRFS_MIN_BLOCKSIZE	(SZ_4K)
-#endif
 
 #define BTRFS_MAX_BLOCKSIZE	(SZ_64K)
 
-- 
2.53.0

Re: [PATCH v2 1/4] btrfs: drop 2K block size support

[David Sterba]

On Fri, Feb 27, 2026 at 02:03:43PM +1030, Qu Wenruo wrote:
> Commit 306a75e647fe ("btrfs: allow debug builds to accept 2K block
> size") added a new block size, 2K as the minimal block size if the
> kernel is built with CONFIG_BTRFS_DEBUG.
> 
> This is to allow testing subpage routines on x86_64 (page size is fixed
> at 4K).
> 
> But it turns out that the support is not that widely adopted, and there
> are extra limits inside btrfs-progs, e.g. 2K node size is not supported.
> 
> Finally with the larger data folio support already in experimental
> builds for a while, it's very easy to trigger a large folio and testing
> subpage routines by just doing a 64K block sized buffered write.
> 
> Let's just remove the seldom utilized 2K block size completely.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Can we keep it? It's under debug and not interfering with anything but
it can trigger different set of bugs than with the large folios.

Re: [PATCH v2 1/4] btrfs: drop 2K block size support

[Qu Wenruo]

在 2026/3/4 14:18, David Sterba 写道:
> On Fri, Feb 27, 2026 at 02:03:43PM +1030, Qu Wenruo wrote:
>> Commit 306a75e647fe ("btrfs: allow debug builds to accept 2K block
>> size") added a new block size, 2K as the minimal block size if the
>> kernel is built with CONFIG_BTRFS_DEBUG.
>>
>> This is to allow testing subpage routines on x86_64 (page size is fixed
>> at 4K).
>>
>> But it turns out that the support is not that widely adopted, and there
>> are extra limits inside btrfs-progs, e.g. 2K node size is not supported.
>>
>> Finally with the larger data folio support already in experimental
>> builds for a while, it's very easy to trigger a large folio and testing
>> subpage routines by just doing a 64K block sized buffered write.
>>
>> Let's just remove the seldom utilized 2K block size completely.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
> 
> Can we keep it? It's under debug and not interfering with anything but
> it can trigger different set of bugs than with the large folios.
> 

Although we can, I'd say the subpage bugs will be no different between 
using large folios and real subpage cases.

I just do not want a special case hanging there without many users.

Thanks,
Qu

[PATCH v2 2/4] btrfs: move shutdown and remove_bdev callbacks out of experimental features

[Qu Wenruo]

These two new callbacks are introduced in v6.19, and it has been two
releases in v7.1.

During that time we have not yet exposed bugs related that two features,
thus it's time to expose them for end users.

It's especially important to expose remove_bdev callback to end users.

That new callback makes btrfs automatically shutdown or go degraded
when a device is missing (depending on if the fs can maintain RW), which
is affecting end users.

We want some feedback from early adopters.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/Kconfig | 2 --
 fs/btrfs/super.c | 4 ----
 2 files changed, 6 deletions(-)

diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index ede184b6eda1..5e75438e0b73 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -112,8 +112,6 @@ config BTRFS_EXPERIMENTAL
 
 	  - large folio and block size (> page size) support
 
-	  - shutdown ioctl and auto-degradation support
-
 	  - asynchronous checksum generation for data writes
 
 	  - remap-tree - logical address remapping tree
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index b4d26ca9220a..52137366b79b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2423,7 +2423,6 @@ static long btrfs_free_cached_objects(struct super_block *sb, struct shrink_cont
 	return 0;
 }
 
-#ifdef CONFIG_BTRFS_EXPERIMENTAL
 static int btrfs_remove_bdev(struct super_block *sb, struct block_device *bdev)
 {
 	struct btrfs_fs_info *fs_info = btrfs_sb(sb);
@@ -2481,7 +2480,6 @@ static void btrfs_shutdown(struct super_block *sb)
 
 	btrfs_force_shutdown(fs_info);
 }
-#endif
 
 static int btrfs_show_stats(struct seq_file *seq, struct dentry *root)
 {
@@ -2511,10 +2509,8 @@ static const struct super_operations btrfs_super_ops = {
 	.nr_cached_objects = btrfs_nr_cached_objects,
 	.free_cached_objects = btrfs_free_cached_objects,
 	.show_stats	= btrfs_show_stats,
-#ifdef CONFIG_BTRFS_EXPERIMENTAL
 	.remove_bdev	= btrfs_remove_bdev,
 	.shutdown	= btrfs_shutdown,
-#endif
 };
 
 static const struct file_operations btrfs_ctl_fops = {
-- 
2.53.0

[PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[Qu Wenruo]

This feature is introduced in v6.17 under experimental, and we had
several small bugs related or exposed by that feature:

 e9e3b22ddfa7 ("btrfs: fix beyond-EOF write handling")
 18de34daa7c6 ("btrfs: truncate ordered extent when skipping writeback past i_size")

Otherwise the feature is being frequently tested by btrfs developers.

The latest fix only arrived in v6.19, after two releases I think it's time
to move this feature out of experimental.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/Kconfig       | 2 +-
 fs/btrfs/btrfs_inode.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 5e75438e0b73..d0451cf93849 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -110,7 +110,7 @@ config BTRFS_EXPERIMENTAL
 
 	  - extent tree v2 - complex rework of extent tracking
 
-	  - large folio and block size (> page size) support
+	  - large block size (> page size) support
 
 	  - asynchronous checksum generation for data writes
 
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 55c272fe5d92..01b147fa9801 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -532,11 +532,9 @@ static inline void btrfs_set_inode_mapping_order(struct btrfs_inode *inode)
 	ASSERT(is_data_inode(inode));
 
 	/* We only allow BITS_PER_LONGS blocks for each bitmap. */
-#ifdef CONFIG_BTRFS_EXPERIMENTAL
 	mapping_set_folio_order_range(inode->vfs_inode.i_mapping,
 				      inode->root->fs_info->block_min_order,
 				      inode->root->fs_info->block_max_order);
-#endif
 }
 
 void btrfs_calculate_block_csum_folio(struct btrfs_fs_info *fs_info,
-- 
2.53.0

Re: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[kernel test robot]

Hello,

kernel test robot noticed "xfstests.btrfs.052.fail" on:

commit: 50bb0fb60d1d55c7447535d17081ea009700cfd7 ("[PATCH v2 3/4] btrfs: move larger data folios out of experimental features")
url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-drop-2K-block-size-support/20260227-113649
base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
patch link: https://lore.kernel.org/all/0d8fe02f58ccbc0c53714ea45b0a4303f2ee8206.1772162871.git.wqu@suse.com/
patch subject: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

in testcase: xfstests
version: xfstests-x86_64-63a29724-1_20260218
with following parameters:

	disk: 6HDD
	fs: btrfs
	test: btrfs-052



config: x86_64-rhel-9.4-func
compiler: gcc-14
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 8G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202603101405.288f83f3-lkp@intel.com


2026-03-06 18:12:00 cd /lkp/benchmarks/xfstests
2026-03-06 18:12:00 export TEST_DIR=/fs/sdb1
2026-03-06 18:12:00 export TEST_DEV=/dev/sdb1
2026-03-06 18:12:00 export FSTYP=btrfs
2026-03-06 18:12:00 export SCRATCH_MNT=/fs/scratch
2026-03-06 18:12:00 mkdir /fs/scratch -p
2026-03-06 18:12:00 export SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
2026-03-06 18:12:00 echo btrfs/052
2026-03-06 18:12:00 ./check btrfs/052
FSTYP         -- btrfs
PLATFORM      -- Linux/x86_64 lkp-hsw-d01 7.0.0-rc1-00110-g50bb0fb60d1d #1 SMP PREEMPT_DYNAMIC Sat Mar  7 01:56:32 CST 2026
MKFS_OPTIONS  -- /dev/sdb2
MOUNT_OPTIONS -- /dev/sdb2 /fs/scratch

btrfs/052          [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//btrfs/052.out.bad)
    --- tests/btrfs/052.out	2026-02-18 09:47:02.000000000 +0000
    +++ /lkp/benchmarks/xfstests/results//btrfs/052.out.bad	2026-03-06 18:12:03.421371379 +0000
    @@ -91,553 +91,5 @@
     23 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05
     *
     30
    -0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    -*
    -2 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
    -*
    ...
    (Run 'diff -u /lkp/benchmarks/xfstests/tests/btrfs/052.out /lkp/benchmarks/xfstests/results//btrfs/052.out.bad'  to see the entire diff)
Ran: btrfs/052
Failures: btrfs/052
Failed 1 of 1 tests




The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260310/202603101405.288f83f3-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[Qu Wenruo]

在 2026/3/10 17:13, kernel test robot 写道:
> 
> 
> Hello,
> 
> kernel test robot noticed "xfstests.btrfs.052.fail" on:
> 
> commit: 50bb0fb60d1d55c7447535d17081ea009700cfd7 ("[PATCH v2 3/4] btrfs: move larger data folios out of experimental features")
> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-drop-2K-block-size-support/20260227-113649
> base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
> patch link: https://lore.kernel.org/all/0d8fe02f58ccbc0c53714ea45b0a4303f2ee8206.1772162871.git.wqu@suse.com/
> patch subject: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features
> 
> in testcase: xfstests
> version: xfstests-x86_64-63a29724-1_20260218
> with following parameters:
> 
> 	disk: 6HDD
> 	fs: btrfs
> 	test: btrfs-052
> 
> 
> 
> config: x86_64-rhel-9.4-func
> compiler: gcc-14
> test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 8G memory
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202603101405.288f83f3-lkp@intel.com
> 
> 
> 2026-03-06 18:12:00 cd /lkp/benchmarks/xfstests
> 2026-03-06 18:12:00 export TEST_DIR=/fs/sdb1
> 2026-03-06 18:12:00 export TEST_DEV=/dev/sdb1
> 2026-03-06 18:12:00 export FSTYP=btrfs
> 2026-03-06 18:12:00 export SCRATCH_MNT=/fs/scratch
> 2026-03-06 18:12:00 mkdir /fs/scratch -p
> 2026-03-06 18:12:00 export SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
> 2026-03-06 18:12:00 echo btrfs/052
> 2026-03-06 18:12:00 ./check btrfs/052
> FSTYP         -- btrfs
> PLATFORM      -- Linux/x86_64 lkp-hsw-d01 7.0.0-rc1-00110-g50bb0fb60d1d #1 SMP PREEMPT_DYNAMIC Sat Mar  7 01:56:32 CST 2026
> MKFS_OPTIONS  -- /dev/sdb2
> MOUNT_OPTIONS -- /dev/sdb2 /fs/scratch
> 
> btrfs/052          [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//btrfs/052.out.bad)
>      --- tests/btrfs/052.out	2026-02-18 09:47:02.000000000 +0000
>      +++ /lkp/benchmarks/xfstests/results//btrfs/052.out.bad	2026-03-06 18:12:03.421371379 +0000
>      @@ -91,553 +91,5 @@
>       23 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05
>       *
>       30
>      -0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>      -*
>      -2 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
>      -*
>      ...
>      (Run 'diff -u /lkp/benchmarks/xfstests/tests/btrfs/052.out /lkp/benchmarks/xfstests/results//btrfs/052.out.bad'  to see the entire diff)
> Ran: btrfs/052
> Failures: btrfs/052
> Failed 1 of 1 tests

Can you provide the full btrfs/052.full?

I checked my older logs (we have enabled larger folios for a while for 
experimental tests) and can not fild a similar failure.

Thus I'm wondering what is causing the failure.

Thanks,
Qu

> 
> 
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260310/202603101405.288f83f3-lkp@intel.com
> 
> 
> 

Re: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[Oliver Sang]

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

hi, Qu,

On Tue, Mar 10, 2026 at 05:33:16PM +1030, Qu Wenruo wrote:
> 
> 
> 在 2026/3/10 17:13, kernel test robot 写道:
> > 
> > 
> > Hello,
> > 
> > kernel test robot noticed "xfstests.btrfs.052.fail" on:
> > 
> > commit: 50bb0fb60d1d55c7447535d17081ea009700cfd7 ("[PATCH v2 3/4] btrfs: move larger data folios out of experimental features")
> > url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-drop-2K-block-size-support/20260227-113649
> > base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
> > patch link: https://lore.kernel.org/all/0d8fe02f58ccbc0c53714ea45b0a4303f2ee8206.1772162871.git.wqu@suse.com/
> > patch subject: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features
> > 
> > in testcase: xfstests
> > version: xfstests-x86_64-63a29724-1_20260218
> > with following parameters:
> > 
> > 	disk: 6HDD
> > 	fs: btrfs
> > 	test: btrfs-052
> > 
> > 
> > 
> > config: x86_64-rhel-9.4-func
> > compiler: gcc-14
> > test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 8G memory
> > 
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > 
> > 
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202603101405.288f83f3-lkp@intel.com
> > 
> > 
> > 2026-03-06 18:12:00 cd /lkp/benchmarks/xfstests
> > 2026-03-06 18:12:00 export TEST_DIR=/fs/sdb1
> > 2026-03-06 18:12:00 export TEST_DEV=/dev/sdb1
> > 2026-03-06 18:12:00 export FSTYP=btrfs
> > 2026-03-06 18:12:00 export SCRATCH_MNT=/fs/scratch
> > 2026-03-06 18:12:00 mkdir /fs/scratch -p
> > 2026-03-06 18:12:00 export SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
> > 2026-03-06 18:12:00 echo btrfs/052
> > 2026-03-06 18:12:00 ./check btrfs/052
> > FSTYP         -- btrfs
> > PLATFORM      -- Linux/x86_64 lkp-hsw-d01 7.0.0-rc1-00110-g50bb0fb60d1d #1 SMP PREEMPT_DYNAMIC Sat Mar  7 01:56:32 CST 2026
> > MKFS_OPTIONS  -- /dev/sdb2
> > MOUNT_OPTIONS -- /dev/sdb2 /fs/scratch
> > 
> > btrfs/052          [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//btrfs/052.out.bad)
> >      --- tests/btrfs/052.out	2026-02-18 09:47:02.000000000 +0000
> >      +++ /lkp/benchmarks/xfstests/results//btrfs/052.out.bad	2026-03-06 18:12:03.421371379 +0000
> >      @@ -91,553 +91,5 @@
> >       23 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05
> >       *
> >       30
> >      -0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >      -*
> >      -2 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
> >      -*
> >      ...
> >      (Run 'diff -u /lkp/benchmarks/xfstests/tests/btrfs/052.out /lkp/benchmarks/xfstests/results//btrfs/052.out.bad'  to see the entire diff)
> > Ran: btrfs/052
> > Failures: btrfs/052
> > Failed 1 of 1 tests
> 
> Can you provide the full btrfs/052.full?

I attached tar.gz which contains all test results. thanks

> 
> I checked my older logs (we have enabled larger folios for a while for
> experimental tests) and can not fild a similar failure.
> 
> Thus I'm wondering what is causing the failure.
> 
> Thanks,
> Qu
> 
> > 
> > 
> > 
> > 
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20260310/202603101405.288f83f3-lkp@intel.com
> > 
> > 
> > 
> 

[-- Attachment #2: results.tar.gz --]
[-- Type: application/gzip, Size: 703 bytes --]

Re: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[Qu Wenruo]

在 2026/3/10 17:51, Oliver Sang 写道:
> hi, Qu,
> 
> On Tue, Mar 10, 2026 at 05:33:16PM +1030, Qu Wenruo wrote:
>>
>>
>> 在 2026/3/10 17:13, kernel test robot 写道:
>>>
>>>
>>> Hello,
>>>
>>> kernel test robot noticed "xfstests.btrfs.052.fail" on:
>>>
>>> commit: 50bb0fb60d1d55c7447535d17081ea009700cfd7 ("[PATCH v2 3/4] btrfs: move larger data folios out of experimental features")
>>> url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-drop-2K-block-size-support/20260227-113649
>>> base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
>>> patch link: https://lore.kernel.org/all/0d8fe02f58ccbc0c53714ea45b0a4303f2ee8206.1772162871.git.wqu@suse.com/
>>> patch subject: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features
>>>
>>> in testcase: xfstests
>>> version: xfstests-x86_64-63a29724-1_20260218
>>> with following parameters:
>>>
>>> 	disk: 6HDD
>>> 	fs: btrfs
>>> 	test: btrfs-052
>>>
>>>
>>>
>>> config: x86_64-rhel-9.4-func
>>> compiler: gcc-14
>>> test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 8G memory
>>>
>>> (please refer to attached dmesg/kmsg for entire log/backtrace)
>>>
>>>
>>>
>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>> the same patch/commit), kindly add following tags
>>> | Reported-by: kernel test robot <oliver.sang@intel.com>
>>> | Closes: https://lore.kernel.org/oe-lkp/202603101405.288f83f3-lkp@intel.com
>>>
>>>
>>> 2026-03-06 18:12:00 cd /lkp/benchmarks/xfstests
>>> 2026-03-06 18:12:00 export TEST_DIR=/fs/sdb1
>>> 2026-03-06 18:12:00 export TEST_DEV=/dev/sdb1
>>> 2026-03-06 18:12:00 export FSTYP=btrfs
>>> 2026-03-06 18:12:00 export SCRATCH_MNT=/fs/scratch
>>> 2026-03-06 18:12:00 mkdir /fs/scratch -p
>>> 2026-03-06 18:12:00 export SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6"
>>> 2026-03-06 18:12:00 echo btrfs/052
>>> 2026-03-06 18:12:00 ./check btrfs/052
>>> FSTYP         -- btrfs
>>> PLATFORM      -- Linux/x86_64 lkp-hsw-d01 7.0.0-rc1-00110-g50bb0fb60d1d #1 SMP PREEMPT_DYNAMIC Sat Mar  7 01:56:32 CST 2026
>>> MKFS_OPTIONS  -- /dev/sdb2
>>> MOUNT_OPTIONS -- /dev/sdb2 /fs/scratch
>>>
>>> btrfs/052          [failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//btrfs/052.out.bad)
>>>       --- tests/btrfs/052.out	2026-02-18 09:47:02.000000000 +0000
>>>       +++ /lkp/benchmarks/xfstests/results//btrfs/052.out.bad	2026-03-06 18:12:03.421371379 +0000
>>>       @@ -91,553 +91,5 @@
>>>        23 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05 05
>>>        *
>>>        30
>>>       -0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>       -*
>>>       -2 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02
>>>       -*
>>>       ...
>>>       (Run 'diff -u /lkp/benchmarks/xfstests/tests/btrfs/052.out /lkp/benchmarks/xfstests/results//btrfs/052.out.bad'  to see the entire diff)
>>> Ran: btrfs/052
>>> Failures: btrfs/052
>>> Failed 1 of 1 tests
>>
>> Can you provide the full btrfs/052.full?
> 
> I attached tar.gz which contains all test results. thanks

Thanks a lot!

It shows it's the defrag ioctl failed, and it's indeed a bug in that 
patch, that I forgot to remove the experimental check from defrag.

Thus it won't cause bug for CONFIG_BTRFS_EXPERIMENTAL but will cause 
problems for end users.

Will get it fixed in the next update.

Thanks again for the consistent report!
Qu


> 
>>
>> I checked my older logs (we have enabled larger folios for a while for
>> experimental tests) and can not fild a similar failure.
>>
>> Thus I'm wondering what is causing the failure.
>>
>> Thanks,
>> Qu
>>
>>>
>>>
>>>
>>>
>>> The kernel config and materials to reproduce are available at:
>>> https://download.01.org/0day-ci/archive/20260310/202603101405.288f83f3-lkp@intel.com
>>>
>>>
>>>
>>

Re: [PATCH v2 3/4] btrfs: move larger data folios out of experimental features

[Oliver Sang]

hi, Qu,

On Tue, Mar 10, 2026 at 06:28:28PM +1030, Qu Wenruo wrote:

[...]

> 
> Thanks a lot!
> 
> It shows it's the defrag ioctl failed, and it's indeed a bug in that patch,
> that I forgot to remove the experimental check from defrag.
> 
> Thus it won't cause bug for CONFIG_BTRFS_EXPERIMENTAL but will cause
> problems for end users.
> 
> Will get it fixed in the next update.
> 
> Thanks again for the consistent report!

you are welcome :)

> Qu
> 

[PATCH v2 4/4] btrfs: move block size < page size support out of experimental features

[Qu Wenruo]

Commit 2ccfaf736909 ("btrfs: support all block sizes which is no larger
than page size") has expanded the supported block size to any block size
that is no larger than page size.

But that support is still only for experimental builds, and it has been
two releases without any reported bug.

We can safely move that feature out of experimental features.

Now only bs > ps support is still under experimental features.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/fs.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/fs/btrfs/fs.c b/fs/btrfs/fs.c
index d7e7011a48c2..ed3bd3cf4524 100644
--- a/fs/btrfs/fs.c
+++ b/fs/btrfs/fs.c
@@ -129,12 +129,10 @@ void btrfs_csum_final(struct btrfs_csum_ctx *ctx, u8 *out)
 /*
  * We support the following block sizes for all systems:
  *
- * - MIN_BLOCKSIZE (4K)
- *   This is the most common block size. For PAGE SIZE > 4K cases the subpage
- *   mode is used.
+ * - [MIN_BLOCKSIZE, PAGE_SIZE]
  *
- * - PAGE_SIZE
- *   The straightforward block size to support.
+ * - (PAGE_SIZE, MAX_BLOCKSIZE]
+ *   For experimental builds and no HIGHMEM.
  */
 bool __attribute_const__ btrfs_supported_blocksize(u32 blocksize)
 {
@@ -142,7 +140,7 @@ bool __attribute_const__ btrfs_supported_blocksize(u32 blocksize)
 	ASSERT(is_power_of_2(blocksize) && blocksize >= BTRFS_MIN_BLOCKSIZE &&
 	       blocksize <= BTRFS_MAX_BLOCKSIZE);
 
-	if (blocksize == PAGE_SIZE || blocksize == BTRFS_MIN_BLOCKSIZE)
+	if (blocksize <= PAGE_SIZE)
 		return true;
 #ifdef CONFIG_BTRFS_EXPERIMENTAL
 	/*
-- 
2.53.0

Re: [PATCH v2 0/4] btrfs: move some features out of experimental

[David Sterba]

On Fri, Feb 27, 2026 at 02:03:42PM +1030, Qu Wenruo wrote:
> [CHANGELOG]
> v2:
> - Move bs < ps && bs != 4K out of experimental
>   That feature is a pretty small niche though.
>   The basis is already there from the bs < ps support for a while.
> 
> - Remove 2K block size support
>   That is too niche, considering how easy to trigger subpage routine
>   with the larger data folio support, there is not much need for it.
> 
> The following features can be moved out of experimental in v7.1:
> 
> - Large data folios
>   It's introduced in v6.17, but we still have a bug fix related for it
>   in v6.19.
>   If there is no new bug exposed I believe it's time to expose this
>   feature to end users.
> 
> - Shutdown and remove_bdev callbacks
>   It's introduced in v6.19, but there is no major known bug exposed yet.
>   Furthermore the remove_bdev callback, aka auto-shutdown/degradation
>   when a device is missing, can affect end users.
> 
>   Thus we want some feedbacks from early adopters.
> 
> - Block size smaller than page size but not 4K support
>   The requirement for 4K block size is purely artificial to reduce our
>   test load.
>   But since we're moving towards supporting all block sizes, the
>   artifical limit can be lifted now.

Adding all of them at once feels a bit risky. I don't think that it has
enough exposure and testing because of number of the possible
combinations.

The shutdown is orthogonal to the rest so this can be enabled by
default. For the rest the bs/ps is namely an ARM thing with the 64K
pages, and large folios is using an internal API in a new way.
Here I'd pick just one and make sure we have it covered by CI. I'm
setting it up again on github actions but it's going slower than
expected.

Re: [PATCH v2 0/4] btrfs: move some features out of experimental

[Qu Wenruo]

在 2026/3/4 14:27, David Sterba 写道:
> On Fri, Feb 27, 2026 at 02:03:42PM +1030, Qu Wenruo wrote:
>> [CHANGELOG]
>> v2:
>> - Move bs < ps && bs != 4K out of experimental
>>    That feature is a pretty small niche though.
>>    The basis is already there from the bs < ps support for a while.
>>
>> - Remove 2K block size support
>>    That is too niche, considering how easy to trigger subpage routine
>>    with the larger data folio support, there is not much need for it.
>>
>> The following features can be moved out of experimental in v7.1:
>>
>> - Large data folios
>>    It's introduced in v6.17, but we still have a bug fix related for it
>>    in v6.19.
>>    If there is no new bug exposed I believe it's time to expose this
>>    feature to end users.
>>
>> - Shutdown and remove_bdev callbacks
>>    It's introduced in v6.19, but there is no major known bug exposed yet.
>>    Furthermore the remove_bdev callback, aka auto-shutdown/degradation
>>    when a device is missing, can affect end users.
>>
>>    Thus we want some feedbacks from early adopters.
>>
>> - Block size smaller than page size but not 4K support
>>    The requirement for 4K block size is purely artificial to reduce our
>>    test load.
>>    But since we're moving towards supporting all block sizes, the
>>    artifical limit can be lifted now.
> 
> Adding all of them at once feels a bit risky. I don't think that it has
> enough exposure and testing because of number of the possible
> combinations.
> 
> The shutdown is orthogonal to the rest so this can be enabled by
> default.

So can I add that shutdown one into for-next branch?

> For the rest the bs/ps is namely an ARM thing with the 64K
> pages,

Thus I'd say it shouldn't affect most end users (if any).

> and large folios is using an internal API in a new way.

That one has been there for testing for a while, and we have exposed 
bugs related to that (on x86_64).
(That's also why I tend to remove 2K block size, since we can reach the 
same result without subpage/2K bs on x86_64)

So it should have been tested by us.
Although I'm fine delaying this to be extra safe, I still prefer this to 
be enabled sooner than later (hopefully 7.2 merge window).

Thanks,
Qu

> Here I'd pick just one and make sure we have it covered by CI. I'm
> setting it up again on github actions but it's going slower than
> expected.

Re: [PATCH v2 0/4] btrfs: move some features out of experimental

[David Sterba]

On Wed, Mar 04, 2026 at 02:34:32PM +1030, Qu Wenruo wrote:
> > Adding all of them at once feels a bit risky. I don't think that it has
> > enough exposure and testing because of number of the possible
> > combinations.
> > 
> > The shutdown is orthogonal to the rest so this can be enabled by
> > default.
> 
> So can I add that shutdown one into for-next branch?

Yes please.

> > For the rest the bs/ps is namely an ARM thing with the 64K
> > pages,
> 
> Thus I'd say it shouldn't affect most end users (if any).

AFAIK the 64K pages are used on big machines with lots of memory and the
support for 64K/4K combinations was needed for interoperability. Yes
there are users.

Re: [PATCH v2 0/4] btrfs: move some features out of experimental

[Qu Wenruo]

在 2026/3/16 19:28, David Sterba 写道:
> On Wed, Mar 04, 2026 at 02:34:32PM +1030, Qu Wenruo wrote:
>>> Adding all of them at once feels a bit risky. I don't think that it has
>>> enough exposure and testing because of number of the possible
>>> combinations.
>>>
>>> The shutdown is orthogonal to the rest so this can be enabled by
>>> default.
>>
>> So can I add that shutdown one into for-next branch?
> 
> Yes please.
> 
>>> For the rest the bs/ps is namely an ARM thing with the 64K
>>> pages,
>>
>> Thus I'd say it shouldn't affect most end users (if any).
> 
> AFAIK the 64K pages are used on big machines with lots of memory and the
> support for 64K/4K combinations was needed for interoperability. Yes
> there are users.

My point is, the newly added feature (bs < ps and that bs is not 4K) is 
not going to affect anyone unless they are intentionally creating such fs.

As all existing users are only using 4K block size anyway.

For those big machines/main frames, they won't suddenly begin to use 
8K/16K/32K fs block size, thus it won't affect them.

But if you insist, I can also drop that all bs < ps enablement patch.

Thanks,
Qu