linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Yi <yi.zhang@huaweicloud.com>
To: libaokun@huaweicloud.com, linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
	linux-kernel@vger.kernel.org, kernel@pankajraghav.com,
	mcgrof@kernel.org, ebiggers@kernel.org, willy@infradead.org,
	yangerkun@huawei.com, chengzhihao1@huawei.com,
	libaokun1@huawei.com
Subject: Re: [PATCH v3 23/24] ext4: add checks for large folio incompatibilities when BS > PS
Date: Wed, 12 Nov 2025 14:56:37 +0800	[thread overview]
Message-ID: <ba84c018-916c-4e26-889b-368d3610225d@huaweicloud.com> (raw)
In-Reply-To: <20251111142634.3301616-24-libaokun@huaweicloud.com>

On 11/11/2025 10:26 PM, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 
> Supporting a block size greater than the page size (BS > PS) requires
> support for large folios. However, several features (e.g., encrypt)
> do not yet support large folios.
> 
> To prevent conflicts, this patch adds checks at mount time to prohibit
> these features from being used when BS > PS. Since these features cannot
> be changed on remount, there is no need to check on remount.
> 
> This patch adds s_max_folio_order, initialized during mount according to
> filesystem features and mount options. If s_max_folio_order is 0, large
> folios are disabled.
> 
> With this in place, ext4_set_inode_mapping_order() can be simplified by
> checking s_max_folio_order, avoiding redundant checks.
> 
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> Reviewed-by: Jan Kara <jack@suse.cz>

Looks good to me.

Reviewed-by: Zhang Yi <yi.zhang@huawei.com>

> ---
>  fs/ext4/ext4.h  |  4 +++-
>  fs/ext4/inode.c | 38 ++++++++++----------------------------
>  fs/ext4/super.c | 39 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 52 insertions(+), 29 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 4bc0b2b7288a..79dc231d6e22 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1696,7 +1696,9 @@ struct ext4_sb_info {
>  	unsigned long s_last_trim_minblks;
>  
>  	/* minimum folio order of a page cache allocation */
> -	unsigned int s_min_folio_order;
> +	u16 s_min_folio_order;
> +	/* supported maximum folio order, 0 means not supported */
> +	u16 s_max_folio_order;
>  
>  	/* Precomputed FS UUID checksum for seeding other checksums */
>  	__u32 s_csum_seed;
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 7b979e64f481..c38cb811f2ae 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5146,41 +5146,23 @@ static int check_igot_inode(struct inode *inode, ext4_iget_flags flags,
>  	return -EFSCORRUPTED;
>  }
>  
> -static bool ext4_should_enable_large_folio(struct inode *inode)
> +void ext4_set_inode_mapping_order(struct inode *inode)
>  {
>  	struct super_block *sb = inode->i_sb;
> +	u16 min_order, max_order;
>  
> -	if (!S_ISREG(inode->i_mode))
> -		return false;
> -	if (ext4_has_feature_encrypt(sb))
> -		return false;
> -
> -	return true;
> -}
> -
> -/*
> - * Limit the maximum folio order to 2048 blocks to prevent overestimation
> - * of reserve handle credits during the folio writeback in environments
> - * where the PAGE_SIZE exceeds 4KB.
> - */
> -#define EXT4_MAX_PAGECACHE_ORDER(i)		\
> -		umin(MAX_PAGECACHE_ORDER, (11 + (i)->i_blkbits - PAGE_SHIFT))
> -void ext4_set_inode_mapping_order(struct inode *inode)
> -{
> -	u32 max_order;
> +	max_order = EXT4_SB(sb)->s_max_folio_order;
> +	if (!max_order)
> +		return;
>  
> -	if (!ext4_should_enable_large_folio(inode))
> +	min_order = EXT4_SB(sb)->s_min_folio_order;
> +	if (!min_order && !S_ISREG(inode->i_mode))
>  		return;
>  
> -	if (test_opt(inode->i_sb, DATA_FLAGS) == EXT4_MOUNT_JOURNAL_DATA ||
> -	    ext4_test_inode_flag(inode, EXT4_INODE_JOURNAL_DATA))
> -		max_order = EXT4_SB(inode->i_sb)->s_min_folio_order;
> -	else
> -		max_order = EXT4_MAX_PAGECACHE_ORDER(inode);
> +	if (ext4_test_inode_flag(inode, EXT4_INODE_JOURNAL_DATA))
> +		max_order = min_order;
>  
> -	mapping_set_folio_order_range(inode->i_mapping,
> -				      EXT4_SB(inode->i_sb)->s_min_folio_order,
> -				      max_order);
> +	mapping_set_folio_order_range(inode->i_mapping, min_order, max_order);
>  }
>  
>  struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 0d32370a459a..f1aeba47b0e3 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -5040,6 +5040,41 @@ static const char *ext4_has_journal_option(struct super_block *sb)
>  	return NULL;
>  }
>  
> +/*
> + * Limit the maximum folio order to 2048 blocks to prevent overestimation
> + * of reserve handle credits during the folio writeback in environments
> + * where the PAGE_SIZE exceeds 4KB.
> + */
> +#define EXT4_MAX_PAGECACHE_ORDER(sb)		\
> +		umin(MAX_PAGECACHE_ORDER, (11 + (sb)->s_blocksize_bits - PAGE_SHIFT))
> +static void ext4_set_max_mapping_order(struct super_block *sb)
> +{
> +	struct ext4_sb_info *sbi = EXT4_SB(sb);
> +
> +	if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_JOURNAL_DATA)
> +		sbi->s_max_folio_order = sbi->s_min_folio_order;
> +	else
> +		sbi->s_max_folio_order = EXT4_MAX_PAGECACHE_ORDER(sb);
> +}
> +
> +static int ext4_check_large_folio(struct super_block *sb)
> +{
> +	const char *err_str = NULL;
> +
> +	if (ext4_has_feature_encrypt(sb))
> +		err_str = "encrypt";
> +
> +	if (!err_str) {
> +		ext4_set_max_mapping_order(sb);
> +	} else if (sb->s_blocksize > PAGE_SIZE) {
> +		ext4_msg(sb, KERN_ERR, "bs(%lu) > ps(%lu) unsupported for %s",
> +			 sb->s_blocksize, PAGE_SIZE, err_str);
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static int ext4_load_super(struct super_block *sb, ext4_fsblk_t *lsb,
>  			   int silent)
>  {
> @@ -5316,6 +5351,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
>  
>  	ext4_apply_options(fc, sb);
>  
> +	err = ext4_check_large_folio(sb);
> +	if (err < 0)
> +		goto failed_mount;
> +
>  	err = ext4_encoding_init(sb, es);
>  	if (err)
>  		goto failed_mount;


  reply	other threads:[~2025-11-12  6:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 14:26 [PATCH v3 00/24] ext4: enable block size larger than page size libaokun
2025-11-11 14:26 ` [PATCH v3 01/24] ext4: remove page offset calculation in ext4_block_zero_page_range() libaokun
2025-11-11 14:26 ` [PATCH v3 02/24] ext4: remove page offset calculation in ext4_block_truncate_page() libaokun
2025-11-11 14:26 ` [PATCH v3 03/24] ext4: remove PAGE_SIZE checks for rec_len conversion libaokun
2025-11-11 14:26 ` [PATCH v3 04/24] ext4: make ext4_punch_hole() support large block size libaokun
2025-11-11 14:26 ` [PATCH v3 05/24] ext4: enable DIOREAD_NOLOCK by default for BS > PS as well libaokun
2025-11-11 14:26 ` [PATCH v3 06/24] ext4: introduce s_min_folio_order for future BS > PS support libaokun
2025-11-11 14:26 ` [PATCH v3 07/24] ext4: support large block size in ext4_calculate_overhead() libaokun
2025-11-11 14:26 ` [PATCH v3 08/24] ext4: support large block size in ext4_readdir() libaokun
2025-11-11 14:26 ` [PATCH v3 09/24] ext4: add EXT4_LBLK_TO_B macro for logical block to bytes conversion libaokun
2025-11-11 14:26 ` [PATCH v3 10/24] ext4: add EXT4_LBLK_TO_PG and EXT4_PG_TO_LBLK for block/page conversion libaokun
2025-11-11 14:26 ` [PATCH v3 11/24] ext4: support large block size in ext4_mb_load_buddy_gfp() libaokun
2025-11-11 14:26 ` [PATCH v3 12/24] ext4: support large block size in ext4_mb_get_buddy_page_lock() libaokun
2025-11-11 14:26 ` [PATCH v3 13/24] ext4: support large block size in ext4_mb_init_cache() libaokun
2025-11-11 14:26 ` [PATCH v3 14/24] ext4: prepare buddy cache inode for BS > PS with large folios libaokun
2025-11-11 14:26 ` [PATCH v3 15/24] ext4: rename 'page' references to 'folio' in multi-block allocator libaokun
2025-11-11 14:26 ` [PATCH v3 16/24] ext4: support large block size in ext4_mpage_readpages() libaokun
2025-11-11 14:26 ` [PATCH v3 17/24] ext4: support large block size in ext4_block_write_begin() libaokun
2025-11-11 14:26 ` [PATCH v3 18/24] ext4: support large block size in mpage_map_and_submit_buffers() libaokun
2025-11-11 14:26 ` [PATCH v3 19/24] ext4: support large block size in mpage_prepare_extent_to_map() libaokun
2025-11-11 14:26 ` [PATCH v3 20/24] ext4: support large block size in __ext4_block_zero_page_range() libaokun
2025-11-11 14:26 ` [PATCH v3 21/24] ext4: make data=journal support large block size libaokun
2025-11-12  6:52   ` Zhang Yi
2025-11-12 15:56   ` Jan Kara
2025-11-19 12:41   ` Dan Carpenter
2025-11-20  1:21     ` Baokun Li
2025-11-20 15:41       ` Theodore Tso
2025-11-21  1:59         ` Baokun Li
2025-11-11 14:26 ` [PATCH v3 22/24] ext4: support verifying data from large folios with fs-verity libaokun
2025-11-12  6:54   ` Zhang Yi
2025-11-12 15:57   ` Jan Kara
2025-11-11 14:26 ` [PATCH v3 23/24] ext4: add checks for large folio incompatibilities when BS > PS libaokun
2025-11-12  6:56   ` Zhang Yi [this message]
2025-11-11 14:26 ` [PATCH v3 24/24] ext4: enable block size larger than page size libaokun
2025-11-11 18:01   ` Pankaj Raghav
2025-11-11 21:11     ` Theodore Ts'o
2025-11-12  1:20       ` Baokun Li

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=ba84c018-916c-4e26-889b-368d3610225d@huaweicloud.com \
    --to=yi.zhang@huaweicloud.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=chengzhihao1@huawei.com \
    --cc=ebiggers@kernel.org \
    --cc=jack@suse.cz \
    --cc=kernel@pankajraghav.com \
    --cc=libaokun1@huawei.com \
    --cc=libaokun@huaweicloud.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    --cc=yangerkun@huawei.com \
    /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 NNTP newsgroup(s).