Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7116889rdb; Wed, 3 Jan 2024 05:21:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IEqJpI+qvFbdeFpmYxUcZbLp2tl9ujR+bB4oJJ7iHSQPPImZDe5dSICPOY9ZP6okg5Iaka2 X-Received: by 2002:a05:6214:2481:b0:67a:a721:830a with SMTP id gi1-20020a056214248100b0067aa721830amr29342058qvb.100.1704288069475; Wed, 03 Jan 2024 05:21:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704288069; cv=none; d=google.com; s=arc-20160816; b=wrADnv0L4qHE9qEz5GLHHxGfmdQJcjp9w11AKpSOo2/7bAWLBbq5/BSnQvS1x2qUiC JY0iA9HjVNXd2hEPOo22Zr5ldJvSpERvpQXLLRCuib0sX8ldYU09QwsXYnYTUlycb7ga X6+EG8DMcBTX6OwileeB62qKCtfYpc52/EPra3aOjY4n0p5XKrA9/lqDpvXnyCHcwXJO BdgarWRUGVRW5EEy5xPWzuMn7E/Wb5DNovLITA5ezLsUhAzuVyu+WzP7TReS+rRieZ/0 vH19ZclW8RMHlXJAxyqJQCy2I3AtBp56sOp4rPfvTLOrqgUANnirBYcgqNwjZxJ151XF Xkqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:user-agent:date :message-id:from:references:cc:to:subject; bh=qhdnYO418KS7S/jodLhk0KOiC6v//jZI8NQRK6avQT4=; fh=mbHNq5NvycgV7Rm/qo7rqMpyl3r2rsA9BgjI5SgR5dg=; b=JVDfrK9DfcXy73kYwNUEOMQpBrvkwW6GGq2kxuHT3shedhPxM2ZEwV7z4SSmnjOuDH kqkPTeRMlDxHGN6yTC2SpVROqLp7Pq7N3vE8Tlj8Wi3H58TunRV0/WaR+4sNnYiVLIL6 41EiAPTV7nB44ul9wDswQVZBPTIWQlbRxbJ2noaehUOz9BfGL/DscRKT0x53PxW/l3nx 8vPrKY6FwGldUpz5NBji9PTBQRcfl7cBdbE+HlNTW0J0u74Q1iZ1sFKox2eOz4wR3b6J XMxfaJgyIlQ97HaMYf1pd2COo9AZT5F9PKB0LOPik9s2AS1sEKvunTzKmhoatAjvsJlo V2TQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4+bounces-660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-660-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id z15-20020a0cf24f000000b0067f1e9d3a15si28877679qvl.81.2024.01.03.05.21.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 05:21:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4+bounces-660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4+bounces-660-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-660-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 2E1B01C230AF for ; Wed, 3 Jan 2024 13:21:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 72C97199A9; Wed, 3 Jan 2024 13:21:03 +0000 (UTC) X-Original-To: linux-ext4@vger.kernel.org Received: from dggsgout11.his.huawei.com (unknown [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 CA2FB1947B; Wed, 3 Jan 2024 13:20:59 +0000 (UTC) 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 dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4T4r2B0dB3z4f3lfZ; Wed, 3 Jan 2024 21:20:50 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id BC6371A0AB2; Wed, 3 Jan 2024 21:20:55 +0800 (CST) Received: from [10.174.176.34] (unknown [10.174.176.34]) by APP1 (Coremail) with SMTP id cCh0CgAHVw00X5VlKmyqFQ--.15497S3; Wed, 03 Jan 2024 21:20:53 +0800 (CST) Subject: Re: [RFC PATCH v2 05/25] ext4: make ext4_map_blocks() distinguish delalloc only extent To: Jan Kara Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org, willy@infradead.org, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com References: <20240102123918.799062-1-yi.zhang@huaweicloud.com> <20240102123918.799062-6-yi.zhang@huaweicloud.com> <20240103113131.z4jhwim7bzynhrlx@quack3> From: Zhang Yi Message-ID: <62da3bfb-6d50-2eb9-1b9a-13f5287f562d@huaweicloud.com> Date: Wed, 3 Jan 2024 21:20:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20240103113131.z4jhwim7bzynhrlx@quack3> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CM-TRANSID:cCh0CgAHVw00X5VlKmyqFQ--.15497S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZFWxGw47CFy5AF43trWkZwb_yoW5Zw48pa 95AF1UKan8Ww1UuayIqF1UJr1UKa1Fkay7Cr4rtryFkasxGr1fKFn09FsxZFWDtrWxJF1U XFW5t3WUCanIkFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q 6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf 9x07UWE__UUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ On 2024/1/3 19:31, Jan Kara wrote: > On Tue 02-01-24 20:38:58, Zhang Yi wrote: >> From: Zhang Yi >> >> Add a new map flag EXT4_MAP_DELAYED to indicate the mapping range is a >> delayed allocated only (not unwritten) one, and making >> ext4_map_blocks() can distinguish it, no longer mixing it with holes. >> >> Signed-off-by: Zhang Yi > > One small comment below. > >> --- >> fs/ext4/ext4.h | 4 +++- >> fs/ext4/extents.c | 5 +++-- >> fs/ext4/inode.c | 2 ++ >> 3 files changed, 8 insertions(+), 3 deletions(-) >> >> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h >> index a5d784872303..55195909d32f 100644 >> --- a/fs/ext4/ext4.h >> +++ b/fs/ext4/ext4.h >> @@ -252,8 +252,10 @@ struct ext4_allocation_request { >> #define EXT4_MAP_MAPPED BIT(BH_Mapped) >> #define EXT4_MAP_UNWRITTEN BIT(BH_Unwritten) >> #define EXT4_MAP_BOUNDARY BIT(BH_Boundary) >> +#define EXT4_MAP_DELAYED BIT(BH_Delay) >> #define EXT4_MAP_FLAGS (EXT4_MAP_NEW | EXT4_MAP_MAPPED |\ >> - EXT4_MAP_UNWRITTEN | EXT4_MAP_BOUNDARY) >> + EXT4_MAP_UNWRITTEN | EXT4_MAP_BOUNDARY |\ >> + EXT4_MAP_DELAYED) >> >> struct ext4_map_blocks { >> ext4_fsblk_t m_pblk; >> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c >> index 0892d0568013..fc69f13cf510 100644 >> --- a/fs/ext4/extents.c >> +++ b/fs/ext4/extents.c >> @@ -4073,9 +4073,10 @@ static void ext4_ext_determine_hole(struct inode *inode, >> } else if (in_range(map->m_lblk, es.es_lblk, es.es_len)) { >> /* >> * Straddle the beginning of the queried range, it's no >> - * longer a hole, adjust the length to the delayed extent's >> - * after map->m_lblk. >> + * longer a hole, mark it is a delalloc and adjust the >> + * length to the delayed extent's after map->m_lblk. >> */ >> + map->m_flags |= EXT4_MAP_DELAYED; > > I wouldn't set delalloc bit here. If there's delalloc extent containing > lblk now, it means the caller of ext4_map_blocks() is not holding i_rwsem > (otherwise we would have found already in ext4_map_blocks()) and thus > delalloc info is unreliable anyway. So I wouldn't bother. But it's worth a > comment here like: > > /* > * There's delalloc extent containing lblk. It must have > * been added after ext4_map_blocks() checked the extent > * status tree so we are not holding i_rwsem and delalloc > * info is only stabilized by i_data_sem we are going to > * release soon. Don't modify the extent status tree and > * report extent as a hole. > */ > Yeah, the delalloc info is still unreliable. Thanks for the advice, I will revise it in my next iteration along with your advice in patch 03. Thanks, Yi. > >> len = es.es_lblk + es.es_len - map->m_lblk; >> goto out; >> } else { >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c >> index 1b5e6409f958..c141bf6d8db2 100644 >> --- a/fs/ext4/inode.c >> +++ b/fs/ext4/inode.c >> @@ -515,6 +515,8 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode, >> map->m_len = retval; >> } else if (ext4_es_is_delayed(&es) || ext4_es_is_hole(&es)) { >> map->m_pblk = 0; >> + map->m_flags |= ext4_es_is_delayed(&es) ? >> + EXT4_MAP_DELAYED : 0; >> retval = es.es_len - (map->m_lblk - es.es_lblk); >> if (retval > map->m_len) >> retval = map->m_len; >> -- >> 2.39.2 >>