[PATCH] ext4: Use optimized mballoc scanning regardless of inode format

[PATCH] ext4: Use optimized mballoc scanning regardless of inode format

[Jan Kara]

Currently we don't used mballoc optimized scanning (using max free
extent order and avg free extent order group lists) for inodes with
indirect block based format. This is confusing for users and I don't see
a good reason for that. Even with indirect block based inode format we
can spend big amount of time searching for free blocks for large
filesystems with fragmented free space. To add to the confusion before
commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount
option work with extents") optimized scanning was applied *only* to
indirect block based inodes so that commit appears as a performance
regression to some users. Just use optimized scanning whenever it is
enabled by mount options.

Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/ext4/mballoc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 56d50fd3310b..4ee7ab4ce86e 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -1133,8 +1133,6 @@ static inline int should_optimize_scan(struct ext4_allocation_context *ac)
 		return 0;
 	if (ac->ac_criteria >= CR_GOAL_LEN_SLOW)
 		return 0;
-	if (!ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS))
-		return 0;
 	return 1;
 }
 
-- 
2.51.0

Re: [PATCH] ext4: Use optimized mballoc scanning regardless of inode format

[Baokun Li]

On 2026-01-09 00:09, Jan Kara wrote:
> Currently we don't used mballoc optimized scanning (using max free
> extent order and avg free extent order group lists) for inodes with
> indirect block based format. This is confusing for users and I don't see
> a good reason for that. Even with indirect block based inode format we
> can spend big amount of time searching for free blocks for large
> filesystems with fragmented free space. To add to the confusion before
> commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount
> option work with extents") optimized scanning was applied *only* to
> indirect block based inodes so that commit appears as a performance
> regression to some users. Just use optimized scanning whenever it is
> enabled by mount options.
>
> Signed-off-by: Jan Kara <jack@suse.cz>

Makes sense. Block allocation should not be tied to the inode format,
and we should remove this restriction.

However, inodes with the indirect block based format only support
32-bit physical block numbers. We already check the maximum supported
block group in ext4_mb_scan_groups_linear, but we don’t perform the
same check in ext4_mb_scan_groups_xa_range.

So if we want to drop this restriction, we need to specify the
appropriate end value for inodes using the indirect block based format
in ext4_mb_scan_groups_xa_range; otherwise, an overflow could occur and
lead to corrupted block allocation.


Regards,
Baokun

> ---
>  fs/ext4/mballoc.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 56d50fd3310b..4ee7ab4ce86e 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -1133,8 +1133,6 @@ static inline int should_optimize_scan(struct ext4_allocation_context *ac)
>  		return 0;
>  	if (ac->ac_criteria >= CR_GOAL_LEN_SLOW)
>  		return 0;
> -	if (!ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS))
> -		return 0;
>  	return 1;
>  }
>  

Re: [PATCH] ext4: Use optimized mballoc scanning regardless of inode format

[Jan Kara]

On Fri 09-01-26 10:00:33, Baokun Li wrote:
> On 2026-01-09 00:09, Jan Kara wrote:
> > Currently we don't used mballoc optimized scanning (using max free
> > extent order and avg free extent order group lists) for inodes with
> > indirect block based format. This is confusing for users and I don't see
> > a good reason for that. Even with indirect block based inode format we
> > can spend big amount of time searching for free blocks for large
> > filesystems with fragmented free space. To add to the confusion before
> > commit 077d0c2c78df ("ext4: make mb_optimize_scan performance mount
> > option work with extents") optimized scanning was applied *only* to
> > indirect block based inodes so that commit appears as a performance
> > regression to some users. Just use optimized scanning whenever it is
> > enabled by mount options.
> >
> > Signed-off-by: Jan Kara <jack@suse.cz>
> 
> Makes sense. Block allocation should not be tied to the inode format,
> and we should remove this restriction.
> 
> However, inodes with the indirect block based format only support
> 32-bit physical block numbers. We already check the maximum supported
> block group in ext4_mb_scan_groups_linear, but we don’t perform the
> same check in ext4_mb_scan_groups_xa_range.
> 
> So if we want to drop this restriction, we need to specify the
> appropriate end value for inodes using the indirect block based format
> in ext4_mb_scan_groups_xa_range; otherwise, an overflow could occur and
> lead to corrupted block allocation.

Good point. I'll fix that up and send v2. Thanks for review!

								Honza

> 
> 
> Regards,
> Baokun
> 
> > ---
> >  fs/ext4/mballoc.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> > index 56d50fd3310b..4ee7ab4ce86e 100644
> > --- a/fs/ext4/mballoc.c
> > +++ b/fs/ext4/mballoc.c
> > @@ -1133,8 +1133,6 @@ static inline int should_optimize_scan(struct ext4_allocation_context *ac)
> >  		return 0;
> >  	if (ac->ac_criteria >= CR_GOAL_LEN_SLOW)
> >  		return 0;
> > -	if (!ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS))
> > -		return 0;
> >  	return 1;
> >  }
> >  
> 
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR