From: Qu Wenruo Date: Fri, 24 Apr 2026 08:51:33 +0000 (+0930) Subject: btrfs: remove 2K block size support X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=bac3c2910c0c37f2e504994eeb1d2102ec8a0d23;p=thirdparty%2Flinux.git btrfs: remove 2K block size support Originally 2K block size support was introduced to test subpage (block size < page size) on x86_64 where the page size is exactly the original minimal block size. However that 2K block size support has some problems: - No 2K nodesize support This is critical, as there is still no way to exercise the subpage metadata routine. - Very easy to test subpage data path now With the currently experimental large folio support, it's very easy to test the subpage data folio path already, as when a folio larger than 4K is encountered on x86_64, we will need all the subpage folio states and bitmaps. So there is no need to use 2K block size just to verify subpage data path even on x86_64. And with the incoming huge folio (2M on x86_64) support, the 2K block size will easily double the bitmap size, considering the burden to maintain and the limited extra coverage, I believe it's time to remove it for the incoming huge folio support. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba --- diff --git a/fs/btrfs/fs.h b/fs/btrfs/fs.h index 248014d3a1ee0..ef66e2fd30af0 100644 --- a/fs/btrfs/fs.h +++ b/fs/btrfs/fs.h @@ -50,18 +50,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) #define BTRFS_MAX_EXTENT_SIZE SZ_128M