From: Ye Bin <yebin10@huawei.com>
To: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <jack@suse.cz>,
Ye Bin <yebin10@huawei.com>
Subject: [PATCH] ext4: fix inconsistent between segment fstrim and full fstrim
Date: Thu, 14 Dec 2023 14:46:35 +0800 [thread overview]
Message-ID: <20231214064635.4128391-1-yebin10@huawei.com> (raw)
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.
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
next reply other threads:[~2023-12-14 6:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 6:46 Ye Bin [this message]
2023-12-14 8:58 ` [PATCH] ext4: fix inconsistent between segment fstrim and full fstrim 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)
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=20231214064635.4128391-1-yebin10@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