From nobody Tue Dec 2 01:28:17 2025 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 EC70A2DD61E; Fri, 21 Nov 2025 06:10:28 +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=1763705432; cv=none; b=qc982Fakj/Y+ps0EDnqdD4yFU4rs7WmFPRUTiZ+BwMJjJh4cKEkUqH/HiJRZQYXvqh8shsnOVmPpN3L9tPv/zH8+rr0H3PIFj0B6xNAImb7d4JIJRll6LsuxuqCya5UUFvXp+rK7vQcyGxFGVsOhWooHGV6IKlGbYzLBna/b6g0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705432; c=relaxed/simple; bh=0MLoO882ewegjXjHICfHQsZgqfYKYwtxuiA0T5zEelo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PlJD81FbXLvxRhV3B0F6/vp+Y9Wgxoz1yPvdTWu+25seVG1DrTiyhlUcMiSGFYgebceXhVqH2wJsQfNtceEa3g7WKmHtmOWgK0lAink/AZ7Ym5kS11Pw5zfxl5hC8quTRp46wXsGNmJkEqJIyx0g1ZzMQq7V/VnAt30EhZT2kk4= 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.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvR4GXbzKHMYZ; Fri, 21 Nov 2025 14:09:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 5A2291A018D; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S5; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 01/13] ext4: cleanup zeroout in ext4_split_extent_at() Date: Fri, 21 Nov 2025 14:07:59 +0800 Message-ID: <20251121060811.1685783-2-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S5 X-Coremail-Antispam: 1UD129KBjvJXoWxGFWDCr47JFy5uFyxWw18Grg_yoW5AFWfpw nIkF9xKr1fJ34UW3yxJF47Zr1UC3WfWw4UGFWfGw1fGay7Xr9agFyfKa40qFyrKFW8Xa4Y qFWrJ34UCanrGFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVW5JVWrJwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JU2dgAUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi zero_ex is a temporary variable used only for writing zeros and inserting extent status entry, it will not be directly inserted into the tree. Therefore, it can be assigned values from the target extent in various scenarios, eliminating the need to explicitly assign values to each variable individually. Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 63 ++++++++++++++++++----------------------------- 1 file changed, 24 insertions(+), 39 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index c7d219e6c6d8..91682966597d 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3278,46 +3278,31 @@ static struct ext4_ext_path *ext4_split_extent_at(h= andle_t *handle, ex =3D path[depth].p_ext; =20 if (EXT4_EXT_MAY_ZEROOUT & split_flag) { - if (split_flag & (EXT4_EXT_DATA_VALID1|EXT4_EXT_DATA_VALID2)) { - if (split_flag & EXT4_EXT_DATA_VALID1) { - err =3D ext4_ext_zeroout(inode, ex2); - zero_ex.ee_block =3D ex2->ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(ex2)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(ex2)); - } else { - err =3D ext4_ext_zeroout(inode, ex); - zero_ex.ee_block =3D ex->ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(ex)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(ex)); - } - } else { - err =3D ext4_ext_zeroout(inode, &orig_ex); - zero_ex.ee_block =3D orig_ex.ee_block; - zero_ex.ee_len =3D cpu_to_le16( - ext4_ext_get_actual_len(&orig_ex)); - ext4_ext_store_pblock(&zero_ex, - ext4_ext_pblock(&orig_ex)); - } + if (split_flag & EXT4_EXT_DATA_VALID1) + memcpy(&zero_ex, ex2, sizeof(zero_ex)); + else if (split_flag & EXT4_EXT_DATA_VALID2) + memcpy(&zero_ex, ex, sizeof(zero_ex)); + else + memcpy(&zero_ex, &orig_ex, sizeof(zero_ex)); =20 - if (!err) { - /* update the extent length and mark as initialized */ - ex->ee_len =3D cpu_to_le16(ee_len); - ext4_ext_try_to_merge(handle, inode, path, ex); - err =3D ext4_ext_dirty(handle, inode, path + path->p_depth); - if (!err) - /* update extent status tree */ - ext4_zeroout_es(inode, &zero_ex); - /* If we failed at this point, we don't know in which - * state the extent tree exactly is so don't try to fix - * length of the original extent as it may do even more - * damage. - */ - goto out; - } + err =3D ext4_ext_zeroout(inode, &zero_ex); + if (err) + goto fix_extent_len; + + /* update the extent length and mark as initialized */ + ex->ee_len =3D cpu_to_le16(ee_len); + ext4_ext_try_to_merge(handle, inode, path, ex); + err =3D ext4_ext_dirty(handle, inode, path + path->p_depth); + if (!err) + /* update extent status tree */ + ext4_zeroout_es(inode, &zero_ex); + /* + * If we failed at this point, we don't know in which + * state the extent tree exactly is so don't try to fix + * length of the original extent as it may do even more + * damage. + */ + goto out; } =20 fix_extent_len: --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 DF4BD2DD60F; Fri, 21 Nov 2025 06:10:28 +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=1763705432; cv=none; b=fY9p5GTVjrodnxwxHPOZkDGv9ex0W7vGIJqPhCSL9UbwA0x4wGaILUZXLp0AqKJ+zfltdfNVOUn6cfOp4FBiG1xUhlbdttZEvUP/ZgAv5U7X4h2k0e4fxwhXNMCGl3ShmtVt9czD3u1HpgMmPQxbupQQuC+b7x0DtQ66+HNkfM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705432; c=relaxed/simple; bh=9Ooy/oQpCjUXAKw1o+tuTKgpG+8iKnY6A2jeSENc168=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RfUoRlG59+V+pIb6K9QhYMZbKF2M6xVbndBDcMSfYXD94ZEe4xBFMIKBKVXyytyP6dOaLPwanfOyIx/wPcZbOa8t6CZsoL/HoUSMCP0taRErpL1wSPEA7YMssDCqQp9BG4CBqmy58bxGucPrwEFoFmB2s1Gtv2Q/2K+2gz/ZSrY= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvR4pfyzKHLy4; Fri, 21 Nov 2025 14:09:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 6E0B01A0905; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S6; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 02/13] ext4: subdivide EXT4_EXT_DATA_VALID1 Date: Fri, 21 Nov 2025 14:08:00 +0800 Message-ID: <20251121060811.1685783-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S6 X-Coremail-Antispam: 1UD129KBjvJXoWxAr15KryxZr43Xw15tw15CFg_yoW5uF4Upr 4S9ayUGr1Dt34F934xtF4Dur45Ww1xGw4DAr9xWw15tay3Ga4aqFn5Kw1aqa4Ygrs3ZrWU ZrWrtr4UCas8Ca7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_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 When splitting an extent, if the EXT4_GET_BLOCKS_CONVERT flag is set and it is necessary to split the target extent in the middle, ext4_split_extent() first handles splitting the latter half of the extent and passes the EXT4_EXT_DATA_VALID1 flag. This flag implies that all blocks before the split point contain valid data; however, this assumption is incorrect. Therefore, subdivid EXT4_EXT_DATA_VALID1 into EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_DATA_PARTIAL_VALID1, which indicate that the first half of the extent is either entirely valid or only partially valid, respectively. These two flags cannot be set simultaneously. This patch does not use EXT4_EXT_DATA_PARTIAL_VALID1, it only replaces EXT4_EXT_DATA_VALID1 with EXT4_EXT_DATA_ENTIRE_VALID1 at the location where it is set, no logical changes. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91682966597d..f7aa497e5d6c 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -43,8 +43,13 @@ #define EXT4_EXT_MARK_UNWRIT1 0x2 /* mark first half unwritten */ #define EXT4_EXT_MARK_UNWRIT2 0x4 /* mark second half unwritten */ =20 -#define EXT4_EXT_DATA_VALID1 0x8 /* first half contains valid data */ -#define EXT4_EXT_DATA_VALID2 0x10 /* second half contains valid data */ +/* first half contains valid data */ +#define EXT4_EXT_DATA_ENTIRE_VALID1 0x8 /* has partially valid data */ +#define EXT4_EXT_DATA_PARTIAL_VALID1 0x10 /* has entirely valid data */ +#define EXT4_EXT_DATA_VALID1 (EXT4_EXT_DATA_ENTIRE_VALID1 | \ + EXT4_EXT_DATA_PARTIAL_VALID1) + +#define EXT4_EXT_DATA_VALID2 0x20 /* second half contains valid data */ =20 static __le32 ext4_extent_block_csum(struct inode *inode, struct ext4_extent_header *eh) @@ -3190,8 +3195,9 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, unsigned int ee_len, depth; int err =3D 0; =20 - BUG_ON((split_flag & (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)) =3D= =3D - (EXT4_EXT_DATA_VALID1 | EXT4_EXT_DATA_VALID2)); + BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) =3D=3D EXT4_EXT_DATA_VALID1); + BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) && + (split_flag & EXT4_EXT_DATA_VALID2)); =20 ext_debug(inode, "logical block %llu\n", (unsigned long long)split); =20 @@ -3358,7 +3364,7 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, split_flag1 |=3D EXT4_EXT_MARK_UNWRIT1 | EXT4_EXT_MARK_UNWRIT2; if (split_flag & EXT4_EXT_DATA_VALID2) - split_flag1 |=3D EXT4_EXT_DATA_VALID1; + split_flag1 |=3D EXT4_EXT_DATA_ENTIRE_VALID1; path =3D ext4_split_extent_at(handle, inode, path, map->m_lblk + map->m_len, split_flag1, flags1); if (IS_ERR(path)) @@ -3717,7 +3723,7 @@ static struct ext4_ext_path *ext4_split_convert_exten= ts(handle_t *handle, =20 /* Convert to unwritten */ if (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN) { - split_flag |=3D EXT4_EXT_DATA_VALID1; + split_flag |=3D EXT4_EXT_DATA_ENTIRE_VALID1; /* Convert to initialized */ } else if (flags & EXT4_GET_BLOCKS_CONVERT) { split_flag |=3D ee_block + ee_len <=3D eof_block ? --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 DC91C2DC333; Fri, 21 Nov 2025 06:10:28 +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=1763705431; cv=none; b=rkbuFaBCSTJ7qv1WFCHyWicxKCjycUbZu2vCbiJTNmhESUoHfGSIi2fkPXn7ABsOr8sDsy3MZ9k18Td9U/K84nh4UGza49C78krltcwdVzQfERHaMjST8Wepwgj09oBytMS+XDSA1qc9L/Yv2jpQE8n+HIDbPQbbrkAqK6iuzYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705431; c=relaxed/simple; bh=4ejDECnxboUjc1R3nYMDj5/PH3R8SK8sJnrCQ1s7mcg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TMb4r7UnV9fm/4P6ed83Vo4g+VTTYD99funjC4rlMrw1fd3yk3EpmqiNc/FSHR9h183MpZa7qvJmGxRf2Xgs+mkBP43tVfPFknbmvijy5BaRrxYcZEJpSPNxajuBDqvF5DH+AsjgWrd5xt8y5wsm5jHsgVZkw4Zr7SqyG8kc9kw= 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.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvR5LzMzKHLy4; Fri, 21 Nov 2025 14:09:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 838301A18D4; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S7; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 03/13] ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 Date: Fri, 21 Nov 2025 14:08:01 +0800 Message-ID: <20251121060811.1685783-4-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S7 X-Coremail-Antispam: 1UD129KBjvJXoWxGF1DGryxXr4Uur1UZF43ZFb_yoW5WrWrpF 4S9ay8Gr4DX34v934xJ3WkZr1qk3WrWrW7Cr98Grn8tayqg342gFs3Ka1jqFyFgr48ZFyU Ar4FyrW5C3Z8JaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWU JVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVj vjDU0xZFpf9x0JUHWlkUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index f7aa497e5d6c..cafe66cb562f 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3294,6 +3294,13 @@ static struct ext4_ext_path *ext4_split_extent_at(ha= ndle_t *handle, err =3D ext4_ext_zeroout(inode, &zero_ex); if (err) goto fix_extent_len; + /* + * The first half contains partially valid data, the splitting + * of this extent has not been completed, fix extent length + * and ext4_split_extent() split will the first half again. + */ + if (split_flag & EXT4_EXT_DATA_PARTIAL_VALID1) + goto fix_extent_len; =20 /* update the extent length and mark as initialized */ ex->ee_len =3D cpu_to_le16(ee_len); @@ -3364,7 +3371,9 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, split_flag1 |=3D EXT4_EXT_MARK_UNWRIT1 | EXT4_EXT_MARK_UNWRIT2; if (split_flag & EXT4_EXT_DATA_VALID2) - split_flag1 |=3D EXT4_EXT_DATA_ENTIRE_VALID1; + split_flag1 |=3D map->m_lblk > ee_block ? + EXT4_EXT_DATA_PARTIAL_VALID1 : + EXT4_EXT_DATA_ENTIRE_VALID1; path =3D ext4_split_extent_at(handle, inode, path, map->m_lblk + map->m_len, split_flag1, flags1); if (IS_ERR(path)) --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 C8C5F1C8FBA; Fri, 21 Nov 2025 06:10:28 +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=1763705432; cv=none; b=qe5xIfJG3j3SV9+PBnvUmmfQ/f5UTSvTymVmpEOE8iQog/lJTfuvUVgEj5vMqPduOlklLNrDEhdFuNwUxVMVRVLYNQ/VwT97FZmqLYOlzhrO4CUDuL+fmypwxkqQwkTV9EUO96G+wvSao4OVvG9/QnWg1/G5Gi1hIeNXegJPFjo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705432; c=relaxed/simple; bh=zi3AN8i8AXlP66f3R7EElNkmkBR6iT++xtTay90h6ao=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QxEFG/SPYib9CivRYGmifTQVvg8yPkub49BbQ8J5+YRUcnMfNHmlUlAZBhb2Wo+1ZVOUDEftF6bqYtiqKfnKOoYlNCG7UiORw/4MbPVwLgJFtGnLmFgQYyThX9c6XcWlEKm+WIgjXhUgMc4FYKsNhsGN0JT3iXFXJg4ZlSqYAuQ= 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.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvC45PyzYQv44; Fri, 21 Nov 2025 14:09:43 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 9AC9C1A0D66; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S8; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 04/13] ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O Date: Fri, 21 Nov 2025 14:08:02 +0800 Message-ID: <20251121060811.1685783-5-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S8 X-Coremail-Antispam: 1UD129KBjvJXoWxGF1fJFyftw17XF17Kr4xXrb_yoW5KFW8pF 4I9F1xJr4vy34ru34xJ3Wqqr17uw18GrsrAryYg3yUKayDtrySgF1Fka4rWFyFgr4rZayY yrWFva4Ykas8G37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_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 When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index cafe66cb562f..2db84f6b0056 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3733,11 +3733,15 @@ static struct ext4_ext_path *ext4_split_convert_ext= ents(handle_t *handle, /* Convert to unwritten */ if (flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN) { split_flag |=3D EXT4_EXT_DATA_ENTIRE_VALID1; - /* Convert to initialized */ - } else if (flags & EXT4_GET_BLOCKS_CONVERT) { + /* Split the existing unwritten extent */ + } else if (flags & (EXT4_GET_BLOCKS_UNWRIT_EXT | + EXT4_GET_BLOCKS_CONVERT)) { split_flag |=3D ee_block + ee_len <=3D eof_block ? EXT4_EXT_MAY_ZEROOUT : 0; - split_flag |=3D (EXT4_EXT_MARK_UNWRIT2 | EXT4_EXT_DATA_VALID2); + split_flag |=3D EXT4_EXT_MARK_UNWRIT2; + /* Convert to initialized */ + if (flags & EXT4_GET_BLOCKS_CONVERT) + split_flag |=3D EXT4_EXT_DATA_VALID2; } flags |=3D EXT4_GET_BLOCKS_PRE_IO; return ext4_split_extent(handle, inode, path, map, split_flag, flags, @@ -3913,7 +3917,7 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, s= truct inode *inode, /* get_block() before submitting IO, split the extent */ if (flags & EXT4_GET_BLOCKS_PRE_IO) { path =3D ext4_split_convert_extents(handle, inode, map, path, - flags | EXT4_GET_BLOCKS_CONVERT, allocated); + flags, allocated); if (IS_ERR(path)) return path; /* --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 DC99A2DCBF2; Fri, 21 Nov 2025 06:10:28 +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=1763705431; cv=none; b=IfqmOzmgmClgHy6rVADLkQmUxGfTeYgNnHyiqnXII9BhfSom5PyAV9BOJYaue1fEAcS8634rj2GsZ5FVWX/v96V9iOeFB+RozRJFlPjOu/fGumxfgHx2rDfmpqV0p0XtJxIXa9pWmR0VZ0D1HYRKmYCDyXVpoJU69pkuy6R6N2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705431; c=relaxed/simple; bh=STYeGxJAFvHud+GfnAY6pRfEKgGU0O7QjI24y13MnBk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=px5+m4TszayTrdHXSrdnJGhowwNabBkZHLHJN6YfpCSicj9Enzy73zLvyJujxxecyJwLoMxlh6xGKKJG0O9DonJbrZQqTvE2gSkUcAsPiw/CAUsUqvgwEMCvCzF0HRSOK5qm2K6Yq961hhaVUItLgqgOTU+LTqMaL442nGzSMU0= 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.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvR6bpqzKHMfQ; Fri, 21 Nov 2025 14:09:55 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id B0F441A1A36; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S9; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 05/13] ext4: correct the mapping status if the extent has been zeroed Date: Fri, 21 Nov 2025 14:08:03 +0800 Message-ID: <20251121060811.1685783-6-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S9 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr15XFW8XF1rGw15XF43ZFb_yoW8Ar1xpF yxAF1rGr4j9a4j93yI9F48Zr17C3W8Gr4UAr4fX3yYgas3Kr1Fgr15ta4FyFyrW3y8Zayj vFW0k345GasxCaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Before submitting I/O and allocating blocks with the EXT4_GET_BLOCKS_PRE_IO flag set, ext4_split_convert_extents() may convert the target extent range to initialized due to ENOSPC, ENOMEM, or EQUOTA errors. However, it still marks the mapping as incorrectly unwritten. Although this may not seem to cause any practical problems, it will result in an unnecessary extent conversion operation after I/O completion. Therefore, it's better to correct the returned mapping status. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 2db84f6b0056..19338f488550 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3916,6 +3916,8 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, s= truct inode *inode, =20 /* get_block() before submitting IO, split the extent */ if (flags & EXT4_GET_BLOCKS_PRE_IO) { + int depth; + path =3D ext4_split_convert_extents(handle, inode, map, path, flags, allocated); if (IS_ERR(path)) @@ -3931,7 +3933,13 @@ ext4_ext_handle_unwritten_extents(handle_t *handle, = struct inode *inode, err =3D -EFSCORRUPTED; goto errout; } - map->m_flags |=3D EXT4_MAP_UNWRITTEN; + /* 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 */ --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 DCA092DCF45; Fri, 21 Nov 2025 06:10:28 +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=1763705431; cv=none; b=IMcOiDxMX7V8zFc11+erjZXMeDAY2rPK7vPDhArxzHZ8CHqXPHilOugilRMxIlyiIV9rRy0J1q+Y3nU3O+LEJG20zg8qGmXE+UE69HdilaA8gjpDAGOoLy4aEueU/WP3/9ULvTH3yYKdOXFIVaqguKnRuBOoVEuS1AwIxLbG/aY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705431; c=relaxed/simple; bh=6+dhuf7c1QK4jBUCFsaFi9oHujThwiLX8HCoz3KISTo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gDZ+9LqUHDAMtgH7OzTT0Jd3tFtje8mR8hwDMvL34/n78a4VflIuAoisfPJlV0irVzBgMW7CdbFDOaN7xc/TDwAKVMXll1zYzX9srrEEAEwLtewWs3Hudx5gSmsNuG3dwLsCqsVaq2ibu3GWBcLxF/XA8IRAlKZn8oOvylA/TLQ= 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.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvS056gzKHLy4; Fri, 21 Nov 2025 14:09:56 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id BFCE01A018D; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S10; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 06/13] ext4: don't cache extent during splitting extent Date: Fri, 21 Nov 2025 14:08:04 +0800 Message-ID: <20251121060811.1685783-7-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S10 X-Coremail-Antispam: 1UD129KBjvJXoWxAw17tF17tr1xKrW7Ww4fAFb_yoW5XF1rpr ZakF1UGr4kC34vka4xCF4kG3409w4kJrW7Ar93Gw1Y9ayUJFySgF1xt3WYvFyrWr48Za45 Zr48K3WUCa4DAFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split. Signed-off-by: Zhang Yi Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 19338f488550..2b5aec3f8882 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3199,6 +3199,9 @@ static struct ext4_ext_path *ext4_split_extent_at(han= dle_t *handle, BUG_ON((split_flag & EXT4_EXT_DATA_VALID1) && (split_flag & EXT4_EXT_DATA_VALID2)); =20 + /* Do not cache extents that are in the process of being modified. */ + flags |=3D EXT4_EX_NOCACHE; + ext_debug(inode, "logical block %llu\n", (unsigned long long)split); =20 ext4_ext_show_leaf(inode, path); @@ -3364,6 +3367,9 @@ static struct ext4_ext_path *ext4_split_extent(handle= _t *handle, ee_len =3D ext4_ext_get_actual_len(ex); unwritten =3D ext4_ext_is_unwritten(ex); =20 + /* Do not cache extents that are in the process of being modified. */ + flags |=3D EXT4_EX_NOCACHE; + if (map->m_lblk + map->m_len < ee_block + ee_len) { split_flag1 =3D split_flag & EXT4_EXT_MAY_ZEROOUT; flags1 =3D flags | EXT4_GET_BLOCKS_PRE_IO; --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 6F7432FF670; Fri, 21 Nov 2025 06:10:33 +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=1763705436; cv=none; b=FQjdEjcQ57CMMvPS0LedW2srj5E/Z/hSKd524kvhvU1fzYYo0yOz3vwZS2QnTLGEM78e7sGN2HrAm0KLj2Dw3KOUjwCNMpf80lKZBxFc05jh8CfhU7F5yTuXzdy/OmVa8EJpz2otwZdW7gnQewk4kuWWpWTTi9/m614JDEGd0jg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705436; c=relaxed/simple; bh=tfElMXijn9LujEgOHitaRMBO3gvCAdVQNYKSPpQ6oT8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lAFoWZl8X5RoReTlnBrotGpuZPiCqW/rj4dQWsytKKsq8QoluZ2CJqg7GA4WLx6ZxbqUf9bALK0PW7vRIY99jf+NmKzFi3qt03SxDVOnE3pcKyZHbZ/yycew5nWMeN8jqeeih3sfZe+Lu1T1cNACNppt9JLD6wxjHg9pE4+P78I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvS0cLVzKHLy4; Fri, 21 Nov 2025 14:09:56 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id D5CDB1A1A35; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S11; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 07/13] ext4: drop extent cache before splitting extent Date: Fri, 21 Nov 2025 14:08:05 +0800 Message-ID: <20251121060811.1685783-8-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S11 X-Coremail-Antispam: 1UD129KBjvJXoW7Ww4fur4xKFyDCrW7Wr15urg_yoW8Kr17pa s2kF1DGr4kA34vg34fG3WDKr1kuw1kGrW7ArW5Gw1jv3WDGryakrn7GayUZFySgFW8ZF15 Zr48ta45Ga4DJFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UU|WWWWWWWWWW] on-disk extent W: written extent [UU|UUUUUUUUUU] extent status tree [--|DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UU|WWWWWWWWWW] on-disk extent W: written extent [UU|WWWWWWWWUU] extent status tree [--|DDDDDDDDZZ] Fix this issue by always remove cached extent status entry before splitting extent. Signed-off-by: Zhang Yi --- fs/ext4/extents.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 2b5aec3f8882..9bb80af4b5cf 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3367,6 +3367,12 @@ static struct ext4_ext_path *ext4_split_extent(handl= e_t *handle, ee_len =3D ext4_ext_get_actual_len(ex); unwritten =3D ext4_ext_is_unwritten(ex); =20 + /* + * Drop extent cache to prevent stale unwritten extents remaining + * after zeroing out. + */ + ext4_es_remove_extent(inode, ee_block, ee_len); + /* Do not cache extents that are in the process of being modified. */ flags |=3D EXT4_EX_NOCACHE; =20 --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 599A72E1C6F; Fri, 21 Nov 2025 06:10:28 +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=1763705431; cv=none; b=IZos1j4jfDnOZVmKrbbWU+a2PClv2lfbnescj2jVbtjE3hOzGl7hoXNS+lLSjyZSgx4rkgCN084lF8i/4VIxs89NqRFpNXfxZh2dWP88JiAh1/7myXwpo0c0AxIiQ5kX8cChfExk9WzqKj2HvKOTXhTaNlbqbNOgXGaziT8ghDQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705431; c=relaxed/simple; bh=+lzYgEZSn1+GQtREZCXiiSon7j+Jz5t9UWVUhwwF2aI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=czPQADLlDLG+5BAVL3H7UCZ9qPMsbB40NqEKVb5TCqh5+TAWsjPcrDDl3JL8Hgx2Hnu6HcqCuL4dCdF8Bsg1dBkFq4zCF0xdD/y7E1bI9xwJDWvNZzd2WDA4quswkyfXGlyk6HRBGzXvarqh57g21BYkPLyiz43P+Ugt9P/MfHg= 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.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvC6cFKzYQv4J; Fri, 21 Nov 2025 14:09:43 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id F0EDA1A0359; Fri, 21 Nov 2025 14:10:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S12; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 08/13] ext4: cleanup useless out tag in __es_remove_extent() Date: Fri, 21 Nov 2025 14:08:06 +0800 Message-ID: <20251121060811.1685783-9-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S12 X-Coremail-Antispam: 1UD129KBjvJXoW7uFWDuFWfGrWkGryfJFyxZrb_yoW8Cr13pw 4rZ34DWryrZw10g397tw1Durya9a40krWUWryftw1fuFy5XryFgF10ya1YvFyFqFW0gw4j qF40yw1jkay7tFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnI WIevJa73UjIFyTuYvjfUOyIUUUUUU X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi The out tag in __es_remove_extent() is just return err value, we can return it directly if something bad happens. Therefore, remove the useless out tag and rename out_get_reserved to out. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/extents_status.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index e04fbf10fe4f..04d56f8f6c0c 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1434,7 +1434,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, struct extent_status orig_es; ext4_lblk_t len1, len2; ext4_fsblk_t block; - int err =3D 0; + int err; bool count_reserved =3D true; struct rsvd_count rc; =20 @@ -1443,9 +1443,9 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 es =3D __es_tree_search(&tree->root, lblk); if (!es) - goto out; + return 0; if (es->es_lblk > end) - goto out; + return 0; =20 /* Simply invalidate cache_es. */ tree->cache_es =3D NULL; @@ -1480,7 +1480,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 es->es_lblk =3D orig_es.es_lblk; es->es_len =3D orig_es.es_len; - goto out; + return err; } } else { es->es_lblk =3D end + 1; @@ -1494,7 +1494,7 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, if (count_reserved) count_rsvd(inode, orig_es.es_lblk + len1, orig_es.es_len - len1 - len2, &orig_es, &rc); - goto out_get_reserved; + goto out; } =20 if (len1 > 0) { @@ -1536,11 +1536,10 @@ static int __es_remove_extent(struct inode *inode, = ext4_lblk_t lblk, } } =20 -out_get_reserved: +out: if (count_reserved) *reserved =3D get_rsvd(inode, end, es, &rc); -out: - return err; + return 0; } =20 /* --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 8ED8D2FFDF0; Fri, 21 Nov 2025 06:10:33 +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=1763705436; cv=none; b=WMcykw3qFBlvbqc43zJGWlrM9sAru4+gCasMJrJOnbpWxsmMrFLly/Ubg5gmmCqITdMu+soH72uGb0RZVaDP/UVWHoWU93TRJig2AANnzkL/8UrrJLHLpamDScgv8c1WFhOxAmgLGafpR6LxM+kh6JB4QRkBbF+ZnfYiUe8FQBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705436; c=relaxed/simple; bh=OnA7iEfHBNCW25SJAXQi33bhCw+yZi4pL58P+1eKdTM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n/rLVgOFf/fBFwoqFZApLo5oKXUx87ZwcOrR3JmmlVFLuHsou9fB/ibRZhiRuAAECiBpWqBfFq4+1NTtJiECOATLksDpT4SV5XFYFCPCv6SYnyaXgu+eHsafXqF2glxZYAoodBZ7zhnS3ngvymeY99J9phN2J1+LP0y/GTjyvk0= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvS26jwzKHMfC; Fri, 21 Nov 2025 14:09:56 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 1110D1A0D66; Fri, 21 Nov 2025 14:10:27 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S13; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 09/13] ext4: make __es_remove_extent() check extent status Date: Fri, 21 Nov 2025 14:08:07 +0800 Message-ID: <20251121060811.1685783-10-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S13 X-Coremail-Antispam: 1UD129KBjvJXoW3Jr1DCF1kJF15tryUWF4kZwb_yoW7Zw1kpF ZrZr1UGryUXayI93yxtw1UWr1ag3W0krW7JrZxKw1fuF15Jrya9F10yFy2vFyFqrW0ga1U ZF40yw1UGa12gFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 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 Currently, __es_remove_extent() unconditionally removes extent status entries within the specified range. In order to prepare for extending the ext4_es_cache_extent() function to cache on-disk extents, which may overwrite some existing short-length extents with the same status, allow __es_remove_extent() to check the specified extent type before removing it, and return error and pass out the conflicting extent if the status does not match. Signed-off-by: Zhang Yi --- fs/ext4/extents_status.c | 49 +++++++++++++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 8 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 04d56f8f6c0c..818007bb613f 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -178,7 +178,8 @@ static struct kmem_cache *ext4_pending_cachep; static int __es_insert_extent(struct inode *inode, struct extent_status *n= ewes, struct extent_status *prealloc); static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, - ext4_lblk_t end, int *reserved, + ext4_lblk_t end, unsigned int status, + int *reserved, struct extent_status *res, struct extent_status *prealloc); static int es_reclaim_extents(struct ext4_inode_info *ei, int *nr_to_scan); static int __es_shrink(struct ext4_sb_info *sbi, int nr_to_scan, @@ -242,6 +243,21 @@ static inline void ext4_es_inc_seq(struct inode *inode) WRITE_ONCE(ei->i_es_seq, ei->i_es_seq + 1); } =20 +static inline int __es_check_extent_status(struct extent_status *es, + unsigned int status, + struct extent_status *res) +{ + if (ext4_es_type(es) & status) + return 0; + + if (res) { + res->es_lblk =3D es->es_lblk; + res->es_len =3D es->es_len; + res->es_pblk =3D es->es_pblk; + } + return -EINVAL; +} + /* * search through the tree for an delayed extent with a given offset. If * it can't be found, try to find next extent. @@ -929,7 +945,7 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lb= lk_t lblk, pr =3D __alloc_pending(true); write_lock(&EXT4_I(inode)->i_es_lock); =20 - err1 =3D __es_remove_extent(inode, lblk, end, &resv_used, es1); + err1 =3D __es_remove_extent(inode, lblk, end, 0, &resv_used, NULL, es1); if (err1 !=3D 0) goto error; /* Free preallocated extent if it didn't get used. */ @@ -1409,23 +1425,27 @@ static unsigned int get_rsvd(struct inode *inode, e= xt4_lblk_t end, return rc->ndelayed; } =20 - /* * __es_remove_extent - removes block range from extent status tree * * @inode - file containing range * @lblk - first block in range * @end - last block in range + * @status - the extent status to be checked * @reserved - number of cluster reservations released + * @res - return the extent if the status is not match * @prealloc - pre-allocated es to avoid memory allocation failures * * If @reserved is not NULL and delayed allocation is enabled, counts * block/cluster reservations freed by removing range and if bigalloc - * enabled cancels pending reservations as needed. Returns 0 on success, - * error code on failure. + * enabled cancels pending reservations as needed. If @status is not + * zero, check extent status type while removing extent, return -EINVAL + * and pass out the extent through @res if not match. Returns 0 on + * success, error code on failure. */ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, - ext4_lblk_t end, int *reserved, + ext4_lblk_t end, unsigned int status, + int *reserved, struct extent_status *res, struct extent_status *prealloc) { struct ext4_es_tree *tree =3D &EXT4_I(inode)->i_es_tree; @@ -1440,6 +1460,8 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, =20 if (reserved =3D=3D NULL || !test_opt(inode->i_sb, DELALLOC)) count_reserved =3D false; + if (status =3D=3D 0) + status =3D ES_TYPE_MASK; =20 es =3D __es_tree_search(&tree->root, lblk); if (!es) @@ -1447,6 +1469,10 @@ static int __es_remove_extent(struct inode *inode, e= xt4_lblk_t lblk, if (es->es_lblk > end) return 0; =20 + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; + /* Simply invalidate cache_es. */ tree->cache_es =3D NULL; if (count_reserved) @@ -1509,6 +1535,9 @@ static int __es_remove_extent(struct inode *inode, ex= t4_lblk_t lblk, } =20 while (es && ext4_es_end(es) <=3D end) { + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; if (count_reserved) count_rsvd(inode, es->es_lblk, es->es_len, es, &rc); node =3D rb_next(&es->rb_node); @@ -1524,6 +1553,10 @@ static int __es_remove_extent(struct inode *inode, e= xt4_lblk_t lblk, if (es && es->es_lblk < end + 1) { ext4_lblk_t orig_len =3D es->es_len; =20 + err =3D __es_check_extent_status(es, status, res); + if (err) + return err; + len1 =3D ext4_es_end(es) - end; if (count_reserved) count_rsvd(inode, es->es_lblk, orig_len - len1, @@ -1581,7 +1614,7 @@ void ext4_es_remove_extent(struct inode *inode, ext4_= lblk_t lblk, * is reclaimed. */ write_lock(&EXT4_I(inode)->i_es_lock); - err =3D __es_remove_extent(inode, lblk, end, &reserved, es); + err =3D __es_remove_extent(inode, lblk, end, 0, &reserved, NULL, es); if (err) goto error; /* Free preallocated extent if it didn't get used. */ @@ -2173,7 +2206,7 @@ void ext4_es_insert_delayed_extent(struct inode *inod= e, ext4_lblk_t lblk, } write_lock(&EXT4_I(inode)->i_es_lock); =20 - err1 =3D __es_remove_extent(inode, lblk, end, NULL, es1); + err1 =3D __es_remove_extent(inode, lblk, end, 0, NULL, NULL, es1); if (err1 !=3D 0) goto error; /* Free preallocated extent if it didn't get used. */ --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 8EC872FFDED; Fri, 21 Nov 2025 06:10:33 +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=1763705436; cv=none; b=RAYi6wm5e4ha3N5wKyUsJ/2aQ7RkHCY9eZ6K9TP8CrX0wgfQke5uaLVLVHUpo+2oSb/KxjRuK4sHiH+BNJNJTa0PFVxzLqFlkYhJau09P/ZQnwkFQR6AQo8n/9FpSF1wi6u1QE4JYlzmbZ1I0IYjZEFWQpKhOagPIQ6R6HePr4M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705436; c=relaxed/simple; bh=OZJLwBCrIAEq12lU7vFFrCObmgIi+k8a2wBnBYgJdM8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VerV0Qn4C3gjjLheaI+TzyuOXDkZDg5E96iLhEGv9cRBlkrFbssWS45LUv3/mstTWjPIAN5wkeUOLK1xRv0KtG4cxnQm0jZ6gDdz/NdnPG8hx9Lb8xb/IluxKFWeoRrrhZgnDBY8eDFyzghD23WaWZrj6cdme/O/e/ZRZdCvU2Q= 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.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvS2sF8zKHMgB; Fri, 21 Nov 2025 14:09:56 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 2A1921A0EE7; Fri, 21 Nov 2025 14:10:27 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S14; Fri, 21 Nov 2025 14:10:26 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 10/13] ext4: make ext4_es_cache_extent() support overwrite existing extents Date: Fri, 21 Nov 2025 14:08:08 +0800 Message-ID: <20251121060811.1685783-11-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S14 X-Coremail-Antispam: 1UD129KBjvJXoWxury7GFW3Ar15Kw18JF4Utwb_yoWrArykp3 9xCr15Jr18Xa4kKayfJa1UXr1rKw4rJrW7Jry3Kr1fCFy5JFyagF1jka4jvFyfWrW8Xr1Y vF40kw1UWa1DC3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Currently, ext4_es_cache_extent() is used to load extents into the extent status tree when reading on-disk extent blocks. But it inserts information into the extent status tree if and only if there isn't information about the specified range already. So it only used for the initial loading and does not support overwrit extents. However, there are many other places in ext4 where on-disk extents are inserted into the extent status tree, such as in ext4_map_query_blocks(). Currently, they call ext4_es_insert_extent() to perform the insertion, but they don't modify the extents, so ext4_es_cache_extent() would be a more appropriate choice. However, when ext4_map_query_blocks() inserts an extent, it may overwrite a short existing extent of the same type. Therefore, to prepare for the replacements, we need to extend ext4_es_cache_extent() to allow it to overwrite existing extents with the same status. So it checks the found extents before removing and inserting. (There is one exception, a hole in the on-disk extent but a delayed extent in the extent status tree is allowed.) In addition, since cached extents can be more lenient than the extents they modify and do not involve modifying reserved blocks, it is not necessary to ensure that the insertion operation succeeds as strictly as in the ext4_es_insert_extent() function. Signed-off-by: Zhang Yi --- fs/ext4/extents_status.c | 47 ++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 7 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 818007bb613f..2643d7a31e7b 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1014,17 +1014,23 @@ void ext4_es_insert_extent(struct inode *inode, ext= 4_lblk_t lblk, } =20 /* - * ext4_es_cache_extent() inserts information into the extent status - * tree if and only if there isn't information about the range in - * question already. + * ext4_es_cache_extent() inserts information into the extent status tree + * only if there is no existing information about the specified range or + * if the existing extents have the same status. + * + * Note that this interface is only used for caching on-disk extent + * information and cannot be used to convert existing extents in the extent + * status tree. To convert existing extents, use ext4_es_insert_extent() + * instead. */ void ext4_es_cache_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len, ext4_fsblk_t pblk, unsigned int status) { struct extent_status *es; - struct extent_status newes; + struct extent_status chkes, newes; ext4_lblk_t end =3D lblk + len - 1; + bool conflict =3D false; =20 if (EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) return; @@ -1040,11 +1046,38 @@ void ext4_es_cache_extent(struct inode *inode, ext4= _lblk_t lblk, BUG_ON(end < lblk); =20 write_lock(&EXT4_I(inode)->i_es_lock); - es =3D __es_tree_search(&EXT4_I(inode)->i_es_tree.root, lblk); - if (!es || es->es_lblk > end) - __es_insert_extent(inode, &newes, NULL); + if (es && es->es_lblk <=3D end) { + /* Found an extent that covers the entire range. */ + if (es->es_lblk <=3D lblk && es->es_lblk + es->es_len > end) { + if (__es_check_extent_status(es, status, &chkes)) + conflict =3D true; + goto unlock; + } + /* Check and remove all extents in range. */ + if (__es_remove_extent(inode, lblk, end, status, NULL, + &chkes, NULL)) { + conflict =3D true; + goto unlock; + } + } + __es_insert_extent(inode, &newes, NULL); +unlock: write_unlock(&EXT4_I(inode)->i_es_lock); + if (!conflict) + return; + /* + * A hole in the on-disk extent but a delayed extent in the extent + * status tree, is allowed. + */ + if (status =3D=3D EXTENT_STATUS_HOLE && + ext4_es_type(&chkes) =3D=3D EXTENT_STATUS_DELAYED) + return; + + ext4_warning_inode(inode, + "ES cache extent failed: add [%d,%d,%llu,0x%x] conflict with existin= g [%d,%d,%llu,0x%x]\n", + lblk, len, pblk, status, chkes.es_lblk, chkes.es_len, + ext4_es_pblock(&chkes), ext4_es_status(&chkes)); } =20 /* --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 16817824BD; Fri, 21 Nov 2025 06:10:28 +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=1763705432; cv=none; b=qS1gE56u40jSnS7w9EwcHZzOcLLMN2sbAQATe3tOOiFvesc0WHHivUJlLYZeF1nDkhswSiNb1VI00TUuqR2oCno71Srmjclhe2p9vuOXt13jXn+5MRYuaAJS0Q83aQ0YZk+XNXL1lOXLRWm2gphkQW4wVgjPVOZT8F7u4H1AWH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705432; c=relaxed/simple; bh=zNrACHIq5YR+U8CSFEVQr7/8NsAnsdeu2boygnxpoWE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dLpgDMArkuZGeq2yQNBoQwL1QX26IWuDrUg0cPIjuKufrl4azmZk2JCjPjOpZU8E+gDC7h7r1jx8o+UnA5KskwdWsxJCiMBVIlwNM7vzG8UNvIsL/37+30St5xTE68B2G7891dwxc9AdsgFb7jKniaW4Gz7ANPT6b/TOsExuTSw= 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.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvD1MrHzYQv4M; Fri, 21 Nov 2025 14:09:44 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 3A4991A0EEC; Fri, 21 Nov 2025 14:10:27 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S15; Fri, 21 Nov 2025 14:10:27 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 11/13] ext4: adjust the debug info in ext4_es_cache_extent() Date: Fri, 21 Nov 2025 14:08:09 +0800 Message-ID: <20251121060811.1685783-12-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S15 X-Coremail-Antispam: 1UD129KBjvJXoWruw4fCr43Ary5Cw4rCFy8Zrb_yoW8Jr4Upa s3CF1UJr1rXw1q9ayxWa18Jr13Gay8GrW7J397tw1ruayrZryrKF1qyFyYvFyUXFWxXw43 ZF40kw1UWa1jy3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Print a trace point after successfully inserting an extent in the ext4_es_cache_extent() function. Additionally, similar to other extent cache operation functions, call ext4_print_pending_tree() to display the extent debug information of the inode when in ES_DEBUG mode. Signed-off-by: Zhang Yi --- fs/ext4/extents_status.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 2643d7a31e7b..e370240555ec 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1038,7 +1038,6 @@ void ext4_es_cache_extent(struct inode *inode, ext4_l= blk_t lblk, newes.es_lblk =3D lblk; newes.es_len =3D len; ext4_es_store_pblock_status(&newes, pblk, status); - trace_ext4_es_cache_extent(inode, &newes); =20 if (!len) return; @@ -1062,6 +1061,8 @@ void ext4_es_cache_extent(struct inode *inode, ext4_l= blk_t lblk, } } __es_insert_extent(inode, &newes, NULL); + trace_ext4_es_cache_extent(inode, &newes); + ext4_es_print_tree(inode); unlock: write_unlock(&EXT4_I(inode)->i_es_lock); if (!conflict) --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 8E8562FFDEB; Fri, 21 Nov 2025 06:10:33 +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=1763705435; cv=none; b=DpibThHfaZ5Jeck8JRzBNg9VPKbPUujLo5GWyYN8kbK7OY0AKH6gO4WoUSkL5UoKu45tdp8TzBBXk7PwgoRqE25jWKtAcUX3elzALTK8VJmyp56qwIIVMoy3tXHL1LVCvbQJbWXNLsYpob4hyWA+UwbO7RaAqfo6DEXVvzHf0ps= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705435; c=relaxed/simple; bh=wIbAMO9b2CGV/QT3DLQZdhKQ3uPbTj5pyfA0UQ8r71E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OWNYvAlj3a7m8l74t/oZ2FjUgjNIU7ui2R12t9SauvFquZYQxJcoJOrOgumpRhkFrH/wgHr9TfmnyV6xRHmO8AzbnmiD9djEbrTvYI8Tpro/AmzvPnYlLRtC80jHjHB1DYD+2CLLd+wLvpMPMCttSB89JqfQUh/IFyE6DIy5TNQ= 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.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvS3vdkzKHMgB; Fri, 21 Nov 2025 14:09:56 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 4CA2E1A07BB; Fri, 21 Nov 2025 14:10:27 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S16; Fri, 21 Nov 2025 14:10:27 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 12/13] ext4: replace ext4_es_insert_extent() when caching on-disk extents Date: Fri, 21 Nov 2025 14:08:10 +0800 Message-ID: <20251121060811.1685783-13-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S16 X-Coremail-Antispam: 1UD129KBjvJXoWxWF4fuF4DGr1DCrWDKr4xtFb_yoW5AF48pr ZrCr1rGws8Ww1q9ayxtF4UZF15Ca4akrW7Gw4xX34rAayrJFyfJF1UtF42vFWvqrW8Xw1r XF4Ut34UCayfGa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi In ext4, the remaining places for inserting extents into the extent status tree within ext4_ext_determine_insert_hole() and ext4_map_query_blocks() directly cache on-disk extents. We can use ext4_es_cache_extent() instead of ext4_es_insert_extent() in these cases. This will help reduce unnecessary increases in extent sequence numbers and cache invalidations after supporting IOMAP in the future. Suggested-by: Jan Kara Signed-off-by: Zhang Yi --- fs/ext4/extents.c | 3 +-- fs/ext4/inode.c | 18 +++++++++--------- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 9bb80af4b5cf..f61a1b57974e 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4184,8 +4184,7 @@ static ext4_lblk_t ext4_ext_determine_insert_hole(str= uct inode *inode, insert_hole: /* Put just found gap into cache to speed up subsequent requests */ ext_debug(inode, " -> %u:%u\n", hole_start, len); - ext4_es_insert_extent(inode, hole_start, len, ~0, - EXTENT_STATUS_HOLE, false); + ext4_es_cache_extent(inode, hole_start, len, ~0, EXTENT_STATUS_HOLE); =20 /* Update hole_len to reflect hole size after lblk */ if (hole_start !=3D lblk) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 5e588accc35a..6ac7602afc39 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -503,8 +503,8 @@ static int ext4_map_query_blocks_next_in_leaf(handle_t = *handle, retval =3D ext4_ext_map_blocks(handle, inode, &map2, 0); =20 if (retval <=3D 0) { - ext4_es_insert_extent(inode, map->m_lblk, map->m_len, - map->m_pblk, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); return map->m_len; } =20 @@ -525,13 +525,13 @@ static int ext4_map_query_blocks_next_in_leaf(handle_= t *handle, */ if (map->m_pblk + map->m_len =3D=3D map2.m_pblk && status =3D=3D status2) { - ext4_es_insert_extent(inode, map->m_lblk, - map->m_len + map2.m_len, map->m_pblk, - status, false); + ext4_es_cache_extent(inode, map->m_lblk, + map->m_len + map2.m_len, map->m_pblk, + status); map->m_len +=3D map2.m_len; } else { - ext4_es_insert_extent(inode, map->m_lblk, map->m_len, - map->m_pblk, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); } =20 return map->m_len; @@ -573,8 +573,8 @@ static int ext4_map_query_blocks(handle_t *handle, stru= ct inode *inode, map->m_len =3D=3D orig_mlen) { 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, status, false); + ext4_es_cache_extent(inode, map->m_lblk, map->m_len, + map->m_pblk, status); } else { retval =3D ext4_map_query_blocks_next_in_leaf(handle, inode, map, orig_mlen); --=20 2.46.1 From nobody Tue Dec 2 01:28:17 2025 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 184B52DEA75; Fri, 21 Nov 2025 06:10:28 +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=1763705431; cv=none; b=ttDyHqcF9fMDM5+IrmVeumgNwy6NsWQlavCIVxr/aOfM4EnrBN1IKZXUPHB2wpQ8/5zixkJ0daubI3YspvBjOZjEXtwUYJoNuqwHznxibvKSK65kc9Gp2pwMkmM/WSYsTFDavmYnVlAqpmgC/dhCbTnY/McI8NWZW65meutWXMw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763705431; c=relaxed/simple; bh=AEEiqz0MmrNjByI5u5ZZOfzdxppiSBGwo4kurejNhaE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T27VrpBLMzN9/rr28s/4FVSVww5nudEMuBNuAx5twmLvn8jEaHYdq6+9lJPRV/KcXEUVnzgGXpF+xVQG9qLma6O0yqpz10RnJ1JxOcIlMb8/bdrSDyY7bMBnMlD+90cAs4CxsvibnLwXPd6BdnwFcHA5ttDCvqAjGFJgtah8a7o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=none 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=none smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4dCPvD22SYzYQv4M; Fri, 21 Nov 2025 14:09:44 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 53EA21A0EE7; Fri, 21 Nov 2025 14:10:27 +0800 (CST) Received: from huaweicloud.com (unknown [10.50.85.155]) by APP2 (Coremail) with SMTP id Syh0CgD3VHtAAiBp_of0BQ--.63807S17; Fri, 21 Nov 2025 14:10:27 +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, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, yizhang089@gmail.com, libaokun1@huawei.com, yangerkun@huawei.com Subject: [PATCH v2 13/13] ext4: drop the TODO comment in ext4_es_insert_extent() Date: Fri, 21 Nov 2025 14:08:11 +0800 Message-ID: <20251121060811.1685783-14-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.46.1 In-Reply-To: <20251121060811.1685783-1-yi.zhang@huaweicloud.com> References: <20251121060811.1685783-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: Syh0CgD3VHtAAiBp_of0BQ--.63807S17 X-Coremail-Antispam: 1UD129KBjvJXoW7uF4kXw4kAF15Xw13GF4kWFg_yoW8JF4fpr sxCw48Jr4fXa1vkayxGF4UXryfGa40krW7Cr97Kw4SkFW5JFyS9F1qyFWYvFyfWrWxXrW5 ZFW8Kwn8Wa15JaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmS14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkE bVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBI daVFxhVjvjDU0xZFpf9x0JUQFxUUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Zhang Yi Now we have ext4_es_cache_extent() to cache on-disk extents instead of ext4_es_insert_extent(), so drop the TODO comment. Signed-off-by: Zhang Yi --- fs/ext4/extents_status.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index e370240555ec..b681bd0c3dc0 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -898,7 +898,8 @@ static int __es_insert_extent(struct inode *inode, stru= ct extent_status *newes, =20 /* * ext4_es_insert_extent() adds information to an inode's extent - * status tree. + * status tree. This interface is used for modifying extents. To cache + * on-disk extents, use ext4_es_cache_extent() instead. */ void ext4_es_insert_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len, ext4_fsblk_t pblk, @@ -977,10 +978,6 @@ void ext4_es_insert_extent(struct inode *inode, ext4_l= blk_t lblk, } pending =3D err3; } - /* - * TODO: For cache on-disk extents, there is no need to increment - * the sequence counter, this requires future optimization. - */ ext4_es_inc_seq(inode); error: write_unlock(&EXT4_I(inode)->i_es_lock); --=20 2.46.1