From: Zhang Yi <yi.zhang@huaweicloud.com>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
ritesh.list@gmail.com, yi.zhang@huawei.com,
yi.zhang@huaweicloud.com, chengzhihao1@huawei.com,
yukuai3@huawei.com
Subject: [PATCH v3 04/10] ext4: trim delalloc extent
Date: Wed, 8 May 2024 14:12:14 +0800 [thread overview]
Message-ID: <20240508061220.967970-5-yi.zhang@huaweicloud.com> (raw)
In-Reply-To: <20240508061220.967970-1-yi.zhang@huaweicloud.com>
From: Zhang Yi <yi.zhang@huawei.com>
In ext4_da_map_blocks(), we could found four kind of extents in the
extent status tree: hole, unwritten, written and delayed extent. Now we
only trim the map len if we found an unwritten extent or a written
extent. This is okay now since map->m_len is always set to one and we
always insert one delayed block at a time. But this will become isn't
okay for other two cases if ext4_insert_delayed_block() and
ext4_da_map_blocks() support inserting multiple map->len blocks later.
1. If we found a hole in the extent status tree which es->es_len is
shorter than the length we want to write, we should trim the
map->m_len to prevent adding extra delay more blocks than we
expected. For example, assume we write data [A, C) to a file that
contains a hole extent [A, B) and a written extent [B, D) in the
cache.
A B C D
before da write: ...hhhhhh|wwwwww....
Then we will get extent [A, B), we should trim map->m_len to B-A
before inserting new delalloc blocks, if not, the range [B, C) will
be duplicated.
2. If we found a delayed extent in the extent status tree which
es->es_len is shorter than the length we want to write, we should
trim the map->m_len to es->es_len and return directly since the front
part of this map has been delayed, we can't insert the delalloc
extent that contains the latter part in this round, we should return
the delayed length and the caller should increase the position and
call ext4_da_map_blocks() again. For example, assume we write data
[A, C) to a file that contains a delayed extent [A, B) in the cache.
A B C
before da write: ...dddddd|hhh....
Then we will get delayed extent [A, B), we should also trim map->m_len
to B-A and return, if not, we will incorrectly assume that the write
is complete and won't insert [B, C).
So we need to always trim the map->m_len if the found es->es_len in the
extent status tree is shorter than the map->m_len, prearing for
inserting a extent with multiple delalloc blocks. This patch only does a
pre-fix, the handle is crude and ext4_da_map_blocks() deserve a cleanup,
we will do that later.
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
---
fs/ext4/inode.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 6114ca79f464..fb76016e2ab7 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1734,6 +1734,11 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
/* Lookup extent status tree firstly */
if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) {
+ retval = es.es_len - (iblock - es.es_lblk);
+ if (retval > map->m_len)
+ retval = map->m_len;
+ map->m_len = retval;
+
if (ext4_es_is_hole(&es))
goto add_delayed;
@@ -1750,10 +1755,6 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
}
map->m_pblk = ext4_es_pblock(&es) + iblock - es.es_lblk;
- retval = es.es_len - (iblock - es.es_lblk);
- if (retval > map->m_len)
- retval = map->m_len;
- map->m_len = retval;
if (ext4_es_is_written(&es))
map->m_flags |= EXT4_MAP_MAPPED;
else if (ext4_es_is_unwritten(&es))
@@ -1790,6 +1791,11 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
* the extent status tree.
*/
if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) {
+ retval = es.es_len - (iblock - es.es_lblk);
+ if (retval > map->m_len)
+ retval = map->m_len;
+ map->m_len = retval;
+
if (!ext4_es_is_hole(&es)) {
up_write(&EXT4_I(inode)->i_data_sem);
goto found;
--
2.39.2
next prev parent reply other threads:[~2024-05-08 6:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 6:12 [PATCH v3 00/10] ext4: support adding multi-delalloc blocks Zhang Yi
2024-05-08 6:12 ` [PATCH v3 01/10] ext4: factor out a common helper to query extent map Zhang Yi
2024-05-08 6:12 ` [PATCH v3 02/10] ext4: check the extent status again before inserting delalloc block Zhang Yi
2024-05-08 15:02 ` Markus Elfring
2024-05-09 8:26 ` Zhang Yi
2024-05-08 6:12 ` [PATCH v3 03/10] ext4: warn if delalloc counters are not zero on inactive Zhang Yi
2024-05-12 15:10 ` Jan Kara
2024-05-13 14:17 ` Zhang Yi
2024-05-08 6:12 ` Zhang Yi [this message]
2024-05-08 15:21 ` [PATCH v3 04/10] ext4: trim delalloc extent Markus Elfring
2024-05-09 8:27 ` Zhang Yi
2024-05-08 6:12 ` [PATCH v3 05/10] ext4: drop iblock parameter Zhang Yi
2024-05-08 6:12 ` [PATCH v3 06/10] ext4: make ext4_es_insert_delayed_block() insert multi-blocks Zhang Yi
2024-05-12 15:19 ` Jan Kara
2024-05-08 6:12 ` [PATCH v3 07/10] ext4: make ext4_da_reserve_space() reserve multi-clusters Zhang Yi
2024-05-08 6:12 ` [PATCH v3 08/10] ext4: factor out check for whether a cluster is allocated Zhang Yi
2024-05-12 15:40 ` Jan Kara
2024-05-14 2:37 ` Zhang Yi
2024-05-08 6:12 ` [PATCH v3 09/10] ext4: make ext4_insert_delayed_block() insert multi-blocks Zhang Yi
2024-05-12 21:47 ` Jan Kara
2024-05-08 6:12 ` [PATCH v3 10/10] ext4: make ext4_da_map_blocks() buffer_head unaware Zhang Yi
2024-05-12 21:51 ` Jan Kara
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=20240508061220.967970-5-yi.zhang@huaweicloud.com \
--to=yi.zhang@huaweicloud.com \
--cc=adilger.kernel@dilger.ca \
--cc=chengzhihao1@huawei.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@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 read-only IMAP folder(s) and NNTP newsgroup(s).