[PATCH v3 3/3] ext4: support flex_bg in ext4_mb_normalize_request

Baokun Li posted 3 patches 3 years, 8 months ago
[PATCH v3 3/3] ext4: support flex_bg in ext4_mb_normalize_request
Posted by Baokun Li 3 years, 8 months ago
In ext4_mb_normalize_request, the size of the allocation request is
limited to no more than EXT4_BLOCKS_PER_GROUP. Ritesh mentions that this
does not take into account the case of flex_bg groups. So we should add
support for flex_bg to make the physical blocks of large files contiguous.

Signed-off-by: Baokun Li <libaokun1@huawei.com>
---
 fs/ext4/mballoc.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 9e06334771a3..253fc250e9a0 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4028,6 +4028,7 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
 	loff_t size, start_off;
 	loff_t orig_size __maybe_unused;
 	ext4_lblk_t start;
+	ext4_lblk_t bpg;
 	struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
 	struct ext4_prealloc_space *pa;
 
@@ -4051,6 +4052,11 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
 	}
 
 	bsbits = ac->ac_sb->s_blocksize_bits;
+	bpg = EXT4_BLOCKS_PER_GROUP(ac->ac_sb);
+	if (ext4_has_feature_flex_bg(ac->ac_sb) && sbi->s_log_groups_per_flex) {
+		if (check_shl_overflow(bpg, sbi->s_log_groups_per_flex, &bpg))
+			bpg = EXT_MAX_BLOCKS;
+	}
 
 	/* first, let's learn actual file size
 	 * given current request is allocated */
@@ -4110,8 +4116,7 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
 	 * alignment does not move allocation to a different group which
 	 * makes mballoc fail assertions later.
 	 */
-	start = max(start, rounddown(ac->ac_o_ex.fe_logical,
-			(ext4_lblk_t)EXT4_BLOCKS_PER_GROUP(ac->ac_sb)));
+	start = max(start, rounddown(ac->ac_o_ex.fe_logical, bpg));
 
 	/* don't cover already allocated blocks in selected range */
 	if (ar->pleft && start <= ar->lleft) {
@@ -4125,8 +4130,8 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
 	 * Trim allocation request for filesystems with artificially small
 	 * groups.
 	 */
-	if (size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb))
-		size = EXT4_BLOCKS_PER_GROUP(ac->ac_sb);
+	if (size > bpg)
+		size = bpg;
 
 	end = start + size;
 
@@ -4208,7 +4213,7 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
 			 (unsigned long) ac->ac_o_ex.fe_logical);
 		BUG();
 	}
-	BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
+	BUG_ON(size <= 0 || size > bpg);
 
 	/* now prepare goal request */
 
-- 
2.31.1
Re: [PATCH v3 3/3] ext4: support flex_bg in ext4_mb_normalize_request
Posted by Ritesh Harjani 3 years, 8 months ago
On 22/05/28 07:00PM, Baokun Li wrote:
> In ext4_mb_normalize_request, the size of the allocation request is
> limited to no more than EXT4_BLOCKS_PER_GROUP. Ritesh mentions that this
> does not take into account the case of flex_bg groups. So we should add
> support for flex_bg to make the physical blocks of large files contiguous.

My only concern here was that what if we are at the flex group end boundary and
decide to take the size as of flex group size. How are we detecting that case.

But, I haven't yet looked at this patch of yours (as I am on travel for next few days),
but if this requires further discussion, we can work on this seperately and let
the other two patches go in as those are part of the bug fixes which you
identified (just my thoughts).

-ritesh
Re: [PATCH v3 3/3] ext4: support flex_bg in ext4_mb_normalize_request
Posted by Baokun Li 3 years, 8 months ago
在 2022/5/28 23:09, Ritesh Harjani 写道:
> On 22/05/28 07:00PM, Baokun Li wrote:
>> In ext4_mb_normalize_request, the size of the allocation request is
>> limited to no more than EXT4_BLOCKS_PER_GROUP. Ritesh mentions that this
>> does not take into account the case of flex_bg groups. So we should add
>> support for flex_bg to make the physical blocks of large files contiguous.
> My only concern here was that what if we are at the flex group end boundary and
> decide to take the size as of flex group size. How are we detecting that case.
>
> But, I haven't yet looked at this patch of yours (as I am on travel for next few days),
> but if this requires further discussion, we can work on this seperately and let
> the other two patches go in as those are part of the bug fixes which you
> identified (just my thoughts).
>
> -ritesh
> .

All right, work on this separately.

Have a nice trip!

-- 
With Best Regards,
Baokun Li