From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE6901367; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; cv=none; b=LBCTIYDNs0hI8r+AuXDG7tQxSRNk8gZcOE62GdmwopA+mV3YWdHm2D6L4vGD1v+tMonlrbaJEPoL4JkAZ/S1Vn2+bO9smdPtBxJA3AnRjIP+HzivwkboViUyOZG5cYivFk+SRl4qOWaNt8ImijbC4YErpRapDnulvt4vsdiC32U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; c=relaxed/simple; bh=d6q/zjeIncE/mA9v6xm9GVqB2a6KGFw352k6rnKR8f0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b2f2strpDtMMnnpYpDgCbM6DoSIAdv0zfff5StcQRPvfSnV4+KTtTbLrGzOBu4dFnhK3aE7cxLp65/sjAC5BhueHXarmtsDqAQ553obVExpDdqW+tkCAQe6If+t08whJZKXOiLEUTH/SkAzForxXXprWKhh+TJb4umpz7DFCLo4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY0n3pzKHMX2; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 9423940573; Mon, 5 Jan 2026 09:48:42 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S5; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 1/7] ext4: use reserved metadata blocks when splitting extent on endio Date: Mon, 5 Jan 2026 09:45:16 +0800 Message-ID: <20260105014522.1937690-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw15Ary3ZF4fKF4UGrW8Xrb_yoW8trWUpF yak3W8Gr40qw1Y9F92yF48Aryjk3W5GF47urZxtayUWay7AryrXr12kw1F9FyYvrWxJ3WY vr40vw18Zwn8Ca7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JU4OJ5UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When performing buffered writes, we may need to split and convert an unwritten extent into a written one during the end I/O process. However, we do not reserve space specifically for these metadata changes, we only reserve 2% of space or 4096 blocks. To address this, we use EXT4_GET_BLOCKS_PRE_IO to potentially split extents in advance and EXT4_GET_BLOCKS_METADATA_NOFAIL to utilize reserved space if necessary. These two approaches can reduce the likelihood of running out of space and losing data. However, these methods are merely best efforts, we could still run out of space, and there is not much difference between converting an extent during the writeback process and the end I/O process, it won't increase the risk of losing data if we postpone the conversion. Therefore, also use EXT4_GET_BLOCKS_METADATA_NOFAIL in ext4_convert_unwritten_extents_endio() to prepare for the buffered I/O iomap conversion, which may perform extent conversion during the end I/O process. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 27eb2c1df012..e53959120b04 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3794,6 +3794,8 @@ ext4_convert_unwritten_extents_endio(handle_t *handle= , struct inode *inode, * illegal. */ if (ee_block !=3D map->m_lblk || ee_len > map->m_len) { + int flags =3D EXT4_GET_BLOCKS_CONVERT | + EXT4_GET_BLOCKS_METADATA_NOFAIL; #ifdef CONFIG_EXT4_DEBUG ext4_warning(inode->i_sb, "Inode (%ld) finished: extent logical block %l= lu," " len %u; IO logical block %llu, len %u", @@ -3801,7 +3803,7 @@ ext4_convert_unwritten_extents_endio(handle_t *handle= , struct inode *inode, (unsigned long long)map->m_lblk, map->m_len); #endif path =3D ext4_split_convert_extents(handle, inode, map, path, - EXT4_GET_BLOCKS_CONVERT, NULL); + flags, NULL); if (IS_ERR(path)) return path; =20 --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE6E51E515; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577728; cv=none; b=AIfVLtmAmw0XkUECG8kDjThz8ihPSLHfbwFsnlElq8+nuZgGax0rZek2zFrze3qVgZk1M2hi77DCLk4Mi1yUazT8CEQI2yy5rotfE69xwuU7KQ8ReL/kCaJVNDvynnPkNhS4RKG6bjOuwbdB6jNeGUj2YQ2GfRB2QN/NV5QHRew= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577728; c=relaxed/simple; bh=i69k8c4PggZS90Tte9HwDeYJNoDwstKKc44HyJVvV0M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RpGxracDierepok8lII0TBEvMOMpCWxYoUYiyVIcd8BuJdwLmAvCK1Y/y9wAmSh3am5PLmKWixzjkp5l8IK3OCtpFubWX0ppxl0SXYg6oG5OBetdr4Es//hYWrleWRbsZLc9bVvDm1ybiBJ8yVQsjrKdfayy8vQLvfko+vQnRy8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY0y9BzKHMZS; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id A2E0240539; Mon, 5 Jan 2026 09:48:42 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S6; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 2/7] ext4: don't split extent before submitting I/O Date: Mon, 5 Jan 2026 09:45:17 +0800 Message-ID: <20260105014522.1937690-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S6 X-Coremail-Antispam: 1UD129KBjvJXoWxXrWUuw1fXF1rCFWkJF43ZFb_yoWruF13pF 43Cw18GF4vgayY9392qF1Uur1Ig3W7Gr4UZryYg3yUWFZ8GryFqF4fKayFva4rtrWkXayY vF4Y934Uu3W5CaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUQXo7UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, when writing back dirty pages to the filesystem with the dioread_nolock feature enabled and when doing DIO, if the area to be written back is part of an unwritten extent, the EXT4_GET_BLOCKS_IO_CREATE_EXT flag is set during block allocation before submitting I/O. The function ext4_split_convert_extents() then attempts to split this extent in advance. This approach is designed to prevents extent splitting and conversion to the written type from failing due to insufficient disk space at the time of I/O completion, which could otherwise result in data loss. However, we already have two mechanisms to ensure successful extent conversion. The first is the EXT4_GET_BLOCKS_METADATA_NOFAIL flag, which is a best effort, it permits the use of 2% of the reserved space or 4,096 blocks in the file system when splitting extents. This flag covers most scenarios where extent splitting might fail. The second is the EXT4_EXT_MAY_ZEROOUT flag, which is also set during extent splitting. If the reserved space is insufficient and splitting fails, it does not retry the allocation. Instead, it directly zeros out the extra part of the extent, thereby avoiding splitting and directly converting the entire extent to the written type. These two mechanisms also exist when I/Os are completed because there is a concurrency window between write-back and fallocate, which may still require us to split extents upon I/O completion. There is no much difference between splitting extents before submitting I/O. Therefore, It seems possible to defer the splitting until I/O completion, it won't increase the risk of I/O failure and data loss. On the contrary, if some I/Os can be merged when I/O completion, it can also reduce unnecessary splitting operations, thereby alleviating the pressure on reserved space. In addition, deferring extent splitting until I/O completion can also simplify the IO submission process and avoid initiating unnecessary journal handles when writing unwritten extents. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 13 +------------ fs/ext4/inode.c | 4 ++-- 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e53959120b04..c98f7c5482b4 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3787,21 +3787,10 @@ ext4_convert_unwritten_extents_endio(handle_t *hand= le, struct inode *inode, ext_debug(inode, "logical block %llu, max_blocks %u\n", (unsigned long long)ee_block, ee_len); =20 - /* If extent is larger than requested it is a clear sign that we still - * have some extent state machine issues left. So extent_split is still - * required. - * TODO: Once all related issues will be fixed this situation should be - * illegal. - */ if (ee_block !=3D map->m_lblk || ee_len > map->m_len) { int flags =3D EXT4_GET_BLOCKS_CONVERT | EXT4_GET_BLOCKS_METADATA_NOFAIL; -#ifdef CONFIG_EXT4_DEBUG - ext4_warning(inode->i_sb, "Inode (%ld) finished: extent logical block %l= lu," - " len %u; IO logical block %llu, len %u", - inode->i_ino, (unsigned long long)ee_block, ee_len, - (unsigned long long)map->m_lblk, map->m_len); -#endif + path =3D ext4_split_convert_extents(handle, inode, map, path, flags, NULL); if (IS_ERR(path)) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index bb8165582840..ffde24ff7347 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -2376,7 +2376,7 @@ static int mpage_map_one_extent(handle_t *handle, str= uct mpage_da_data *mpd) =20 dioread_nolock =3D ext4_should_dioread_nolock(inode); if (dioread_nolock) - get_blocks_flags |=3D EXT4_GET_BLOCKS_IO_CREATE_EXT; + get_blocks_flags |=3D EXT4_GET_BLOCKS_UNWRIT_EXT; =20 err =3D ext4_map_blocks(handle, inode, map, get_blocks_flags); if (err < 0) @@ -3744,7 +3744,7 @@ static int ext4_iomap_alloc(struct inode *inode, stru= ct ext4_map_blocks *map, else if (EXT4_LBLK_TO_B(inode, map->m_lblk) >=3D i_size_read(inode)) m_flags =3D EXT4_GET_BLOCKS_CREATE; else if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) - m_flags =3D EXT4_GET_BLOCKS_IO_CREATE_EXT; + m_flags =3D EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT; =20 if (flags & IOMAP_ATOMIC) ret =3D ext4_map_blocks_atomic_write(handle, inode, map, m_flags, --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE7181E531; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577728; cv=none; b=V7vtdwNqYmeM1+LG2lNe1iWTnT+NWrZFsaCD2BmmJ5PeMXzTGR+yCsEZY/jH6gE9BskaC2tv+H41QHjNN9srczij54d/bCivH4Zr2kmZHNOLP5L+660duKAGnHohmRcXz5xZlSPXJ6ivyvocDTxjnZvv4JpXRzHNcmEeasvnZW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577728; c=relaxed/simple; bh=S4JICoMIxRCz5h6jkLY4dAEsRHek6pHB1k+CuiYOT6A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BgdOL5eyzkhpy7GUZ2C12oi7tMbZHCjPAYXvEla4w3orfF8HF6W/0ravtdgCwcYPVPSHY//A0ZvBtymOi/46OWU2KR/5xiW61pBigq+1BNRTUJCqn5xjg5wu/d5YamC3RRa1tvCzt11+1fwuW5xlSoPdu5c5p9V7SOLndSIpVrU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.198]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY1YG7zKHMZh; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id B29C640579; Mon, 5 Jan 2026 09:48:42 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S7; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 3/7] ext4: avoid starting handle when dio writing an unwritten extent Date: Mon, 5 Jan 2026 09:45:18 +0800 Message-ID: <20260105014522.1937690-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S7 X-Coremail-Antispam: 1UD129KBjvJXoWxWw48KF18JF4DJrW7Xr43KFg_yoW5Jw1kpa 9aga4kGFWkWFyUua93u3W8XrWrKw4fKw47ZFWrKry5XryUKr10qw4YqF1FvF48trZ7WF4a qFWSyryru3Z8ArDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfUO_MaUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Since we have deferred the split of the unwritten extent until after I/O completion, it is not necessary to initiate the journal handle when submitting the I/O. This can improve the write performance of concurrent DIO for multiple files. The fio tests below show a ~25% performance improvement when wirting to unwritten files on my VM with a mem disk. [unwritten] direct=3D1 ioengine=3Dpsync numjobs=3D16 rw=3Dwrite # write/randwrite bs=3D4K iodepth=3D1 directory=3D/mnt size=3D5G runtime=3D30s overwrite=3D0 norandommap=3D1 fallocate=3Dnative ramp_time=3D5s group_reporting=3D1 [w/o] w: IOPS=3D62.5k, BW=3D244MiB/s rw: IOPS=3D56.7k, BW=3D221MiB/s [w] w: IOPS=3D79.6k, BW=3D311MiB/s rw: IOPS=3D70.2k, BW=3D274MiB/s Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/file.c | 4 +--- fs/ext4/inode.c | 9 +++++++-- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 7a8b30932189..9f571acc7782 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -418,9 +418,7 @@ static const struct iomap_dio_ops ext4_dio_write_ops = =3D { * updating inode i_disksize and/or orphan handling with exclusive lock. * * - shared locking will only be true mostly with overwrites, including - * initialized blocks and unwritten blocks. For overwrite unwritten bloc= ks - * we protect splitting extents by i_data_sem in ext4_inode_info, so we = can - * also release exclusive i_rwsem lock. + * initialized blocks and unwritten blocks. * * - Otherwise we will switch to exclusive i_rwsem lock. */ diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index ffde24ff7347..ff3ad1a2df45 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3817,9 +3817,14 @@ static int ext4_iomap_begin(struct inode *inode, lof= f_t offset, loff_t length, ret =3D ext4_map_blocks(NULL, inode, &map, 0); /* * For atomic writes the entire requested length should - * be mapped. + * be mapped. For DAX we convert extents to initialized + * ones before copying the data, otherwise we do it + * after I/O so there's no need to call into + * ext4_iomap_alloc(). */ - if (map.m_flags & EXT4_MAP_MAPPED) { + if ((map.m_flags & EXT4_MAP_MAPPED) || + (!(flags & IOMAP_DAX) && + (map.m_flags & EXT4_MAP_UNWRITTEN))) { if ((!(flags & IOMAP_ATOMIC) && ret > 0) || (flags & IOMAP_ATOMIC && ret >=3D orig_mlen)) goto out; --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCF3C200C2; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; cv=none; b=fH+KZZbZIaSAhwOlgcIETU7F4Uum04i4VnpauxJZqcz0Pgg6WFGQUm31KNy8jzpeV5yRspVQ+qxgwe0VuTzAIXFI5MZj6a5EBdJcZ+w1Q/FzyrDgtbdXFKtNaa78j+qVkMb0YrM5IgTwcX8lML/UuKyTdPyhUjjku4L/et779pw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; c=relaxed/simple; bh=KkcCWf8oYvQMoxNhiRABuGVERu+R/QdjIdCwZ2g+P+I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CK2tRr+l+R/PJ54HVflGins/SmvIvXdbcwkgpHFE7g7eixEq+8AP4HzqH4P+vUL4hFDzH6VWE0WuEpz7np9+1YmCAxbkdWsrKWDVgz8cLbNkuAaA6Q6fqATdHhh2JqdwSNuXLGP5w6zJT8BnhrXTId4B7CVjI0hoe08BmTRaOCM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY2Dp0zKHMZn; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id CF4314058C; Mon, 5 Jan 2026 09:48:42 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S8; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 4/7] ext4: remove useless ext4_iomap_overwrite_ops Date: Mon, 5 Jan 2026 09:45:19 +0800 Message-ID: <20260105014522.1937690-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S8 X-Coremail-Antispam: 1UD129KBjvJXoWxGFyUCFyrGF18Zw1DXr1kKrg_yoWrWF4Upa s8KF13GF4xXryq9r4UKFWxZryYkw17Kw48Xry3Gwn8uryqv34IqFW8Ka4Fk3W5J3yxAry2 qF1jkry8JF1akrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi ext4_iomap_overwrite_ops was introduced in commit 8cd115bdda17 ("ext4: Optimize ext4 DIO overwrites"), which can optimize pure overwrite performance by dropping the IOMAP_WRITE flag to only query the mapped mapping information. This avoids starting a new journal handle, thereby improving speed. Later, commit 9faac62d4013 ("ext4: optimize file overwrites") also optimized similar scenarios, but it performs the check later, examining the mappings status only when the actual block mapping is needed. Thus, it can handle the previous commit scenario. That means in the case of an overwrite scenario, the condition "offset + length <=3D i_size_read(inode)" in the write path must always be true. Therefore, it is acceptable to remove the ext4_iomap_overwrite_ops, which will also clarify the write and read paths of ext4_iomap_begin. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 1 - fs/ext4/file.c | 5 +---- fs/ext4/inode.c | 24 ------------------------ 3 files changed, 1 insertion(+), 29 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 56112f201cac..9a71357f192d 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3909,7 +3909,6 @@ static inline void ext4_clear_io_unwritten_flag(ext4_= io_end_t *io_end) } =20 extern const struct iomap_ops ext4_iomap_ops; -extern const struct iomap_ops ext4_iomap_overwrite_ops; extern const struct iomap_ops ext4_iomap_report_ops; =20 static inline int ext4_buffer_uptodate(struct buffer_head *bh) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 9f571acc7782..6b4b68f830d5 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -506,7 +506,6 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, = struct iov_iter *from) struct inode *inode =3D file_inode(iocb->ki_filp); loff_t offset =3D iocb->ki_pos; size_t count =3D iov_iter_count(from); - const struct iomap_ops *iomap_ops =3D &ext4_iomap_ops; bool extend =3D false, unwritten =3D false; bool ilock_shared =3D true; int dio_flags =3D 0; @@ -573,9 +572,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, = struct iov_iter *from) goto out; } =20 - if (ilock_shared && !unwritten) - iomap_ops =3D &ext4_iomap_overwrite_ops; - ret =3D iomap_dio_rw(iocb, from, iomap_ops, &ext4_dio_write_ops, + ret =3D iomap_dio_rw(iocb, from, &ext4_iomap_ops, &ext4_dio_write_ops, dio_flags, NULL, 0); if (ret =3D=3D -ENOTBLK) ret =3D 0; diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index ff3ad1a2df45..b84a2a10dfb8 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3833,10 +3833,6 @@ static int ext4_iomap_begin(struct inode *inode, lof= f_t offset, loff_t length, } ret =3D ext4_iomap_alloc(inode, &map, flags); } else { - /* - * This can be called for overwrites path from - * ext4_iomap_overwrite_begin(). - */ ret =3D ext4_map_blocks(NULL, inode, &map, 0); } =20 @@ -3865,30 +3861,10 @@ static int ext4_iomap_begin(struct inode *inode, lo= ff_t offset, loff_t length, return 0; } =20 -static int ext4_iomap_overwrite_begin(struct inode *inode, loff_t offset, - loff_t length, unsigned flags, struct iomap *iomap, - struct iomap *srcmap) -{ - int ret; - - /* - * Even for writes we don't need to allocate blocks, so just pretend - * we are reading to save overhead of starting a transaction. - */ - flags &=3D ~IOMAP_WRITE; - ret =3D ext4_iomap_begin(inode, offset, length, flags, iomap, srcmap); - WARN_ON_ONCE(!ret && iomap->type !=3D IOMAP_MAPPED); - return ret; -} - const struct iomap_ops ext4_iomap_ops =3D { .iomap_begin =3D ext4_iomap_begin, }; =20 -const struct iomap_ops ext4_iomap_overwrite_ops =3D { - .iomap_begin =3D ext4_iomap_overwrite_begin, -}; - static int ext4_iomap_begin_report(struct inode *inode, loff_t offset, loff_t length, unsigned int flags, struct iomap *iomap, struct iomap *srcmap) --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34ACA1F2B8D; Mon, 5 Jan 2026 01:48:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577732; cv=none; b=A7r2CjKe9nxihhbjFbzcQxNEyhru0PUSTFsilGwVupvdd5W2RN07JB2kfp+TO5kAtB6K6qzMJuqXt9bKQ4MhvKgnmDKOtY7GritsoZkN2BxuRruCPmAH6wotqi6ByJL/K4JB9gVWYXPJamCTUzrJeQyX6wdwtY6ywav7DB8Brgc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577732; c=relaxed/simple; bh=BD38+k0fiy4RF7enyeK/M1BHor8U/dKefAoMRUC0P+8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I/SuF2w7FJB5Iww9bHsbkA84/N3pIIKepM3cgW+ZNPwuO5TuaAsJb+K561BohmHybFxUKK+u9mMt1jWJ02AYI8vFxOrF5lm0EaVTKW9Vb5J0crEJFiIVG6wORhqs6OURamlwtpN3NqDzPNVLNlMrD+bF0jlDcnJqhutGnl+A9cQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY4C3BzKHMb2; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id DD88140575; Mon, 5 Jan 2026 09:48:42 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S9; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 5/7] ext4: remove unused unwritten parameter in ext4_dio_write_iter() Date: Mon, 5 Jan 2026 09:45:20 +0800 Message-ID: <20260105014522.1937690-6-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S9 X-Coremail-Antispam: 1UD129KBjvJXoWxuF4rXF43trykGFyrtFyDGFg_yoW5Wr4rpF 13Ka4UXFZ7W39rWrW8tay8uryYga1kC3yxWrW5W3W5Zry8AryfKF1xtFyYy3WrJrZ7J3W2 gFsYkryDZw17KrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The parameter unwritten in ext4_dio_write_iter() is no longer needed, simply remove it. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/file.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 6b4b68f830d5..fa22fc0e45f3 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -424,14 +424,14 @@ static const struct iomap_dio_ops ext4_dio_write_ops = =3D { */ static ssize_t ext4_dio_write_checks(struct kiocb *iocb, struct iov_iter *= from, bool *ilock_shared, bool *extend, - bool *unwritten, int *dio_flags) + int *dio_flags) { struct file *file =3D iocb->ki_filp; struct inode *inode =3D file_inode(file); loff_t offset; size_t count; ssize_t ret; - bool overwrite, unaligned_io; + bool overwrite, unaligned_io, unwritten; =20 restart: ret =3D ext4_generic_write_checks(iocb, from); @@ -443,7 +443,7 @@ static ssize_t ext4_dio_write_checks(struct kiocb *iocb= , struct iov_iter *from, =20 unaligned_io =3D ext4_unaligned_io(inode, from, offset); *extend =3D ext4_extending_io(inode, offset, count); - overwrite =3D ext4_overwrite_io(inode, offset, count, unwritten); + overwrite =3D ext4_overwrite_io(inode, offset, count, &unwritten); =20 /* * Determine whether we need to upgrade to an exclusive lock. This is @@ -458,7 +458,7 @@ static ssize_t ext4_dio_write_checks(struct kiocb *iocb= , struct iov_iter *from, */ if (*ilock_shared && ((!IS_NOSEC(inode) || *extend || !overwrite || - (unaligned_io && *unwritten)))) { + (unaligned_io && unwritten)))) { if (iocb->ki_flags & IOCB_NOWAIT) { ret =3D -EAGAIN; goto out; @@ -481,7 +481,7 @@ static ssize_t ext4_dio_write_checks(struct kiocb *iocb= , struct iov_iter *from, ret =3D -EAGAIN; goto out; } - if (unaligned_io && (!overwrite || *unwritten)) + if (unaligned_io && (!overwrite || unwritten)) inode_dio_wait(inode); *dio_flags =3D IOMAP_DIO_FORCE_WAIT; } @@ -506,7 +506,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, = struct iov_iter *from) struct inode *inode =3D file_inode(iocb->ki_filp); loff_t offset =3D iocb->ki_pos; size_t count =3D iov_iter_count(from); - bool extend =3D false, unwritten =3D false; + bool extend =3D false; bool ilock_shared =3D true; int dio_flags =3D 0; =20 @@ -552,7 +552,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, = struct iov_iter *from) ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); =20 ret =3D ext4_dio_write_checks(iocb, from, &ilock_shared, &extend, - &unwritten, &dio_flags); + &dio_flags); if (ret <=3D 0) return ret; =20 --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCF6725771; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; cv=none; b=bJ5Tgz4Vi4UjH83An/WYKmvMFEQWns3cQGI2eDt6Abg4o30KNh0OUGd8rQC25NOi0hV7jN2Vqopj4dVLm1bJ4/r8ImwA0AdFHq8iJZNtnAkw5EAAnVbabOndRwBIinfGjjVLci4ssVROlWdCsEquUmCqU4d+kVQoVRWAfioZCDg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; c=relaxed/simple; bh=lyqJr2AL6pJI07G3sWFtV9DhqLLWFZmbQX/2gYl7RM0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MKJ87KNB5XwJHYUcDLH/HKi09rKDYXTyEm7xqygVRQH+2XZyyfunR4RgveJgX6hFMXoxu8nCXUgzRtyrzORjlKesCvx4y5vNq6E656XKCxIDPSv8/LIjxZ0nEGZJGMO4LohFNjkyz4apmlORs30tqzu9v4GR7UnWaCFw8hWSxZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dkxyY3ZQSzKHMb2; Mon, 5 Jan 2026 09:48:05 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 0506B40571; Mon, 5 Jan 2026 09:48:43 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S10; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 6/7] ext4: simplify the mapping query logic in ext4_iomap_begin() Date: Mon, 5 Jan 2026 09:45:21 +0800 Message-ID: <20260105014522.1937690-7-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S10 X-Coremail-Antispam: 1UD129KBjvJXoW7CFWUCFW7Cw1fWFW8tFWrXwb_yoW8Ww18pa 93Ka95GFn5Xr1UurZavF93XrWUKa1xKw4UZFWfGry5Wr90gr10gr4YgF1Yqr18JrWxArWF gFW0yr18u3WUZFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUma14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsG vfC2KfnxnUUI43ZEXa7VUbPC7UUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In the write path mapping check of ext4_iomap_begin(), the return value 'ret' should never greater than orig_mlen. If 'ret' equals 'orig_mlen', it can be returned directly without checking IOMAP_ATOMIC. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/inode.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index b84a2a10dfb8..67fe7d0f47e3 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3816,17 +3816,19 @@ static int ext4_iomap_begin(struct inode *inode, lo= ff_t offset, loff_t length, if (offset + length <=3D i_size_read(inode)) { ret =3D ext4_map_blocks(NULL, inode, &map, 0); /* - * For atomic writes the entire requested length should - * be mapped. For DAX we convert extents to initialized - * ones before copying the data, otherwise we do it - * after I/O so there's no need to call into - * ext4_iomap_alloc(). + * For DAX we convert extents to initialized ones before + * copying the data, otherwise we do it after I/O so + * there's no need to call into ext4_iomap_alloc(). */ if ((map.m_flags & EXT4_MAP_MAPPED) || (!(flags & IOMAP_DAX) && (map.m_flags & EXT4_MAP_UNWRITTEN))) { - if ((!(flags & IOMAP_ATOMIC) && ret > 0) || - (flags & IOMAP_ATOMIC && ret >=3D orig_mlen)) + /* + * For atomic writes the entire requested + * length should be mapped. + */ + if (ret =3D=3D orig_mlen || + (!(flags & IOMAP_ATOMIC) && ret > 0)) goto out; } map.m_len =3D orig_mlen; --=20 2.52.0 From nobody Wed Jan 7 23:14:40 2026 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C8D23BB5A; Mon, 5 Jan 2026 01:48:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; cv=none; b=NH4yQLfotCgkW7bnI3l61vGVZkv1tkSqpoIhfXnuGXxavBswKlQlu3PKzfyUjc29rwBWtrNLzMbpVPfDX0PGDxXLF56wf5Tav/sa6phKy8ZQhmqooGIzz2pJjp/d+yEyRwoPEQE0bExMLlvKA6f+HUdXRySFjuHxTzQsLeDbiTU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767577727; c=relaxed/simple; bh=zZYvnQBA5etWrYYMEpqGReUtUXBCqXJWIkPndb5non0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Jo7aK86tEkIHmKa3vyUV0kAodMhygL76v6dWp+YDTDPJrKMC+Uah6y6rwyk43SoNlpq8bnCGWnXvNEw2gONfHHq9R0o+lUsFJ1zh8UQ/KgXxk7qDxqmYYgUEwiVD6F9PIF2n6+nB+25413Y1XLTDMVqm9LqBlhVN920QphZxt7Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.170]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dkxy903s0zYQtxm; Mon, 5 Jan 2026 09:47:45 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 146E04056F; Mon, 5 Jan 2026 09:48:43 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP4 (Coremail) with SMTP id gCh0CgBHp_dpGFtppFisCg--.42376S11; Mon, 05 Jan 2026 09:48:42 +0800 (CST) From: Zhang Yi 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, ojaswin@linux.ibm.com, ritesh.list@gmail.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com Subject: [PATCH -next v3 7/7] ext4: remove EXT4_GET_BLOCKS_IO_CREATE_EXT Date: Mon, 5 Jan 2026 09:45:22 +0800 Message-ID: <20260105014522.1937690-8-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> References: <20260105014522.1937690-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgBHp_dpGFtppFisCg--.42376S11 X-Coremail-Antispam: 1UD129KBjvJXoWxGFWUGw1UGF1xAryfXr1UJrb_yoWrXF47pa sxAF1xGr4jq3yj93yxCF1UXr12k3W8KFW7urW5JrWF9a43AryfKF18tayFyFyFgFW8ZF4Y qFWFk34UJayfGrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi We do not use EXT4_GET_BLOCKS_IO_CREATE_EXT or split extents before submitting I/O; therefore, remove the related code. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 9 --------- fs/ext4/extents.c | 29 ----------------------------- fs/ext4/inode.c | 11 ----------- 3 files changed, 49 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 9a71357f192d..174c51402864 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -707,15 +707,6 @@ enum { * found an unwritten extent, we need to split it. */ #define EXT4_GET_BLOCKS_SPLIT_NOMERGE 0x0008 - /* - * Caller is from the dio or dioread_nolock buffered IO, reqest to - * create an unwritten extent if it does not exist or split the - * found unwritten extent. Also do not merge the newly created - * unwritten extent, io end will convert unwritten to written, - * and try to merge the written extent. - */ -#define EXT4_GET_BLOCKS_IO_CREATE_EXT (EXT4_GET_BLOCKS_SPLIT_NOMERGE|\ - EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT) /* Convert unwritten extent to initialized. */ #define EXT4_GET_BLOCKS_CONVERT 0x0010 /* Eventual metadata allocation (due to growing extent tree) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c98f7c5482b4..c7c66ab825e7 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3925,34 +3925,6 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, = struct inode *inode, trace_ext4_ext_handle_unwritten_extents(inode, map, flags, *allocated, newblock); =20 - /* get_block() before submitting IO, split the extent */ - if (flags & EXT4_GET_BLOCKS_SPLIT_NOMERGE) { - int depth; - - path =3D ext4_split_convert_extents(handle, inode, map, path, - flags, allocated); - if (IS_ERR(path)) - return path; - /* - * shouldn't get a 0 allocated when splitting an extent unless - * m_len is 0 (bug) or extent has been corrupted - */ - if (unlikely(*allocated =3D=3D 0)) { - EXT4_ERROR_INODE(inode, - "unexpected allocated =3D=3D 0, m_len =3D %u", - map->m_len); - err =3D -EFSCORRUPTED; - goto errout; - } - /* Don't mark unwritten if the extent has been zeroed out. */ - path =3D ext4_find_extent(inode, map->m_lblk, path, flags); - if (IS_ERR(path)) - return path; - depth =3D ext_depth(inode); - if (ext4_ext_is_unwritten(path[depth].p_ext)) - map->m_flags |=3D EXT4_MAP_UNWRITTEN; - goto out; - } /* IO end_io complete, convert the filled extent to written */ if (flags & EXT4_GET_BLOCKS_CONVERT) { path =3D ext4_convert_unwritten_extents_endio(handle, inode, @@ -4006,7 +3978,6 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, s= truct inode *inode, goto errout; } =20 -out: map->m_flags |=3D EXT4_MAP_NEW; map_out: map->m_flags |=3D EXT4_MAP_MAPPED; diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 67fe7d0f47e3..2e79b09fe2f0 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -588,7 +588,6 @@ static int ext4_map_query_blocks(handle_t *handle, stru= ct inode *inode, static int ext4_map_create_blocks(handle_t *handle, struct inode *inode, struct ext4_map_blocks *map, int flags) { - struct extent_status es; unsigned int status; int err, retval =3D 0; =20 @@ -649,16 +648,6 @@ static int ext4_map_create_blocks(handle_t *handle, st= ruct inode *inode, return err; } =20 - /* - * If the extent has been zeroed out, we don't need to update - * extent status tree. - */ - if (flags & EXT4_GET_BLOCKS_SPLIT_NOMERGE && - ext4_es_lookup_extent(inode, map->m_lblk, NULL, &es, &map->m_seq)) { - if (ext4_es_is_written(&es)) - return retval; - } - status =3D map->m_flags & EXT4_MAP_UNWRITTEN ? EXTENT_STATUS_UNWRITTEN : EXTENT_STATUS_WRITTEN; ext4_es_insert_extent(inode, map->m_lblk, map->m_len, map->m_pblk, --=20 2.52.0