From: "yebin (H)" <yebin10@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext4: fix inconsistent between segment fstrim and full fstrim
Date: Sat, 16 Dec 2023 09:01:29 +0800 [thread overview]
Message-ID: <657CF6E9.602@huawei.com> (raw)
In-Reply-To: <20231215114135.qwdoscxg7myw3r6x@quack3>
On 2023/12/15 19:41, Jan Kara wrote:
> On Thu 14-12-23 14:46:35, Ye Bin wrote:
>> There will not issue discard cmd when do segment fstrim for ext4 fs, however,
>> if full fstrim for the same fs will issue discard cmd.
>> Above issue may happens as follows:
>> Precondition:
>> 1. Fstrim range [0, 15] and [16, 31];
>> 2. Discard granularity is 16;
>> Range1 Range2
>> 1111000000000000 0000111010101011
>> There's no free space length large or equal than 16 in 'Range1' or 'Range2'.
>> As ext4_try_to_trim_range() only search free space among range which user
>> specified. However, there's maximum free space length 16 in 'Range1'+ 'Range2'.
>> To solve above issue, we need to find the longest free space to discard.
> The patch looks good so feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> I'd just rephrase the changelog to make it a bit easier to read:
>
> Suppose we issue two FITRIM ioctls for ranges [0,15] and [16,31] with
> mininum length of trimmed range set to 8 blocks. If we have say a range of
> blocks 10-22 free, this range will not be trimmed because it straddles the
> boundary of the two FITRIM ranges and neither part is big enough. This is a
> bit surprising to some users that call FITRIM on smaller ranges of blocks
> to limit impact on the system. Also XFS trims all free space extents that
> overlap with the specified range so we are inconsistent among filesystems.
> Let's change ext4_try_to_trim_range() to consider for trimming the whole
> free space extent that straddles the end of specified range, not just the
> part of it within the range.
>
> Honza
>
Thank you very much for your clear explanation of the patch. I'll
update patch's
changelog and resend a version.
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> ---
>> fs/ext4/mballoc.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> index d72b5e3c92ec..d195461123d8 100644
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -6753,13 +6753,15 @@ static int ext4_try_to_trim_range(struct super_block *sb,
>> __acquires(ext4_group_lock_ptr(sb, e4b->bd_group))
>> __releases(ext4_group_lock_ptr(sb, e4b->bd_group))
>> {
>> - ext4_grpblk_t next, count, free_count;
>> + ext4_grpblk_t next, count, free_count, last, origin_start;
>> bool set_trimmed = false;
>> void *bitmap;
>>
>> + last = ext4_last_grp_cluster(sb, e4b->bd_group);
>> bitmap = e4b->bd_bitmap;
>> - if (start == 0 && max >= ext4_last_grp_cluster(sb, e4b->bd_group))
>> + if (start == 0 && max >= last)
>> set_trimmed = true;
>> + origin_start = start;
>> start = max(e4b->bd_info->bb_first_free, start);
>> count = 0;
>> free_count = 0;
>> @@ -6768,7 +6770,10 @@ __releases(ext4_group_lock_ptr(sb, e4b->bd_group))
>> start = mb_find_next_zero_bit(bitmap, max + 1, start);
>> if (start > max)
>> break;
>> - next = mb_find_next_bit(bitmap, max + 1, start);
>> +
>> + next = mb_find_next_bit(bitmap, last + 1, start);
>> + if (origin_start == 0 && next >= last)
>> + set_trimmed = true;
>>
>> if ((next - start) >= minblocks) {
>> int ret = ext4_trim_extent(sb, start, next - start, e4b);
>> --
>> 2.31.1
>>
prev parent reply other threads:[~2023-12-16 1:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 6:46 [PATCH] ext4: fix inconsistent between segment fstrim and full fstrim Ye Bin
2023-12-14 8:58 ` Jan Kara
2023-12-14 13:06 ` yebin (H)
2023-12-15 11:11 ` Jan Kara
2023-12-15 11:32 ` Jan Kara
2023-12-15 11:41 ` Jan Kara
2023-12-16 1:01 ` yebin (H) [this message]
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=657CF6E9.602@huawei.com \
--to=yebin10@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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