From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13718C4345F for ; Wed, 1 May 2024 14:31:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98C0A6B008A; Wed, 1 May 2024 10:31:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93C206B008C; Wed, 1 May 2024 10:31:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8036D6B0092; Wed, 1 May 2024 10:31:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 60C5A6B008A for ; Wed, 1 May 2024 10:31:38 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EE15FA0BA6 for ; Wed, 1 May 2024 14:31:37 +0000 (UTC) X-FDA: 82070065434.23.624A587 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf02.hostedemail.com (Postfix) with ESMTP id 3CF5680024 for ; Wed, 1 May 2024 14:31:36 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eeQy/f1x"; spf=pass (imf02.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714573896; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to:references:dkim-signature; bh=zcjwcyL162mAw3vYWOhklGg/HCY1i6wwZ9HtuvhcCfU=; b=6s2wciFFRRBDlk2+KD/2tguphtvSUpzDuzRLAqiZ4olN3a4kaCxr3GBLHeP6MGiJlk0lAb pEge1C1+Lltmr6R9x3AOOB3deWFkHp0k/1OjZ1Lu1b+XpZ6FYt0z/Kl1nTt1glOzVyJSrm J0IAhWXpfMLkXRiHZHt0LuQJ+1N7IhY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="eeQy/f1x"; spf=pass (imf02.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714573896; a=rsa-sha256; cv=none; b=ALQmrqbyo4qSrN+0rwjAn655sA+/XOTRPEZuJRm4aHL04h6RX9reazZ+l3rJaV+PdhtsLv Pw3YQphgEYtUSVKXKydYhsqk6SLP09MlwmWUju1TNw+25Br0iwY82j3ZOU8DpSHwkKr1ql Sj8MpuHnB4iY9tN5uVR1+SoHdxXqfgA= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6f074520c8cso6515125b3a.0 for ; Wed, 01 May 2024 07:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714573895; x=1715178695; darn=kvack.org; h=in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=zcjwcyL162mAw3vYWOhklGg/HCY1i6wwZ9HtuvhcCfU=; b=eeQy/f1xDBMYiPGtQ/G/ZWnYZTAts1hokM42Sfw0Qu9asTHwTOgW7i8sQDnQRvwU6P 7hxsA74qlKmePhHql+20fSBlc8GUdxF/y+OEjmchnpbRmuDDRm/CxV6/mCFVi1MIYsKZ F7FhJg7uCDbS7FNm3+wx19/Nu1zePuIYl0g1VMyPEBfK8Nc52QWli3HPMHvNRfswtmpm tfjMd1ASS4K4ENd0X127KI5oI6wFGjXZp07P8EcMqSiaowAE+feBY/REMfTGxILYDqNh 46DCkMyn07Q5bPRjMSUXj1SqiVE6Ex4kV0pbOWNLoRlypQrcOsIYm9GdA9GNjv6OXWMK mQAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714573895; x=1715178695; h=in-reply-to:subject:cc:to:from:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zcjwcyL162mAw3vYWOhklGg/HCY1i6wwZ9HtuvhcCfU=; b=UIscq3uGl0KozFiupTczR9F+n1vshVe8rPVeoHw/KDbsiGIryVU3WFZuAfUKge1ewG bxD1dv/OH30Qd/nBdnCHSELlXg5JV94AfYdTabR2YhqBgczvDdMYD64pbNRYAo3PNLUb 6dzVnQsKFtTUBlr5Pwn3jX1iH06e2yHL9JjQimY0MlRdTxWTJLe2VSmGwJ2gEUeT4HCS yqAacuQOEqGiGWQkLG6hJf8ryvvUtFdkN7j6siWyJ619jDqprDAG1W1767uVFvBEHwT7 7umsHdiANYU7OwzkZ3c/plPcjCDH7rNMCtBcO/sXFmD4xOb9NUcsLeBJfs2e3KnrfuWE E52A== X-Forwarded-Encrypted: i=1; AJvYcCXsbiNTt05KVl7u+xTU2XpHKoTYUbUQyhK9NX/1uHUcSqYBWwCAkMZel3YrK4xPGUiqIWkZgLfZSSkyyjhb06brrLs= X-Gm-Message-State: AOJu0Yyy1V/q3+EofilWZ8Apq102UukF7TbESox9WWamURhinw17Xb0g silAeS1WZqPh9aHjc3NMPMe3vpu4qcQj1v/IMjcmt3vTsVvNt3m6 X-Google-Smtp-Source: AGHT+IGsJOaC+lS+/evg5Leq+hxeaR9zb7+g4k0bI/FQiC36XhEwuw9ttXGSR/TYaCH0fF4LcExP7Q== X-Received: by 2002:a05:6a20:8418:b0:1ad:31e2:56c with SMTP id c24-20020a056a20841800b001ad31e2056cmr3321219pzd.8.1714573894892; Wed, 01 May 2024 07:31:34 -0700 (PDT) Received: from dw-tp ([171.76.84.250]) by smtp.gmail.com with ESMTPSA id fh31-20020a056a00391f00b006f3ef025ed2sm7601061pfb.94.2024.05.01.07.31.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 May 2024 07:31:33 -0700 (PDT) Date: Wed, 01 May 2024 20:01:27 +0530 Message-Id: <87h6fh4n9c.fsf@gmail.com> From: Ritesh Harjani (IBM) To: Zhang Yi , linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, hch@infradead.org, djwong@kernel.org, david@fromorbit.com, willy@infradead.org, zokeefe@google.com, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com Subject: Re: [PATCH v4 03/34] ext4: trim delalloc extent In-Reply-To: <20240410142948.2817554-4-yi.zhang@huaweicloud.com> X-Rspam-User: X-Rspamd-Queue-Id: 3CF5680024 X-Rspamd-Server: rspam06 X-Stat-Signature: 4zx7hsk7a3t61dadnzqc5ww86upmng5h X-HE-Tag: 1714573896-972331 X-HE-Meta: U2FsdGVkX18yLH7QpwObx1huUeM5HRjkQVwrFpAVK/Qu3jmB+nAf9UYnEWLDsZh0OcEQjbAP0Vw7siyYFuLbgnzbuR/YJulf5TW3uWZ/ecd5MLeYni65TNMUvTa8q4QEzyPPmlMs2JrpgN5396Dyww2YGkekMspV2wU35cbBP1TZcPA5e/90lOTqvHtRa6mhGcoKpvDmOxyWnrpLFA9Np4ecA6n5y9PzzmB4h6PSGvww8YkhNrGagU7YiFafOn2xjBJ7Xq9CUmC8GiWgIbGvBMDCA2KZjekTM68I2tLMcY+5xHRfbOtiev+av4D3a0fdKOE/XrrxzMiGN0KN+5zNPkkj0PitTsRBXO65nimbhkq/INZqIdYalR4ehkByd1gy6Of+ypydrcsYTA4NQ9FFGcxsh9pW/Mb8D/ucsA6IzbBFyLZSQ/WgaHoqOtxgj+/ZaqmwXf0Cv8VfGVE0C35udUPUIxPWhXTqSIxt8onMuHUfLLwShUY7A5UAgZ42VhrlpU0W9+P7fN8vpiXu8h1o5EaANcepyvT+JpR4Fh0M8uQQAdfgMY0W/0ExgjU47dSztzmAwqpKIDqWKSR9jxK+xtrlnzETl7DoHCScBTmpn5+mu6TDbWeFAVhlUy8zDctKweoHVVYldUAgzOPsrx2GALtHhEFhrJAUfbRIvb+g1HYQszlkREZA5MR2FUbMCLW8F1lTPd3NDSUP2QrGI+v+wqyUF4iN/3TP9fTJykOCIPR9lBJBB7V3fxzDvbICoRRADfw+kEVO1ePRM8+943p09BR4isKTmRP+0woFRauqMvHfK3zzrSQUJgBfLFRhfazrvkaVypeemrPoHsuNqJkZ9oogzsG16xUUXF5o65ttw4KLZ6v3ZaQQ0isafvuDk49pz+fS1TSeGHFvl05ZcIULVV++JKfgU8LsDFmFRmpERbgBgBs4jwa6t3dzrpWzgEpFeqC9gSqXg/JuVXZWG+9 bsTKLFed cBWb9SZ2U2Z/2p+1pltJkP27w81rkRWJgmux+d8hXBobZu+Mw/E7o4KJGw2uSsCr/7ZTQxwOc4dkw+pFSPfhkau9Trj6UzoLAyk7ojLRT9+3O1/7Q3letaLNWWhbyvyqlpVat8DlT8DkTtgMLWj/o81dzzVFdilxS0vibqQPEyCAUEDYLKB5HDmF64Vs4u7CR3bdkpZ+w99dxL2ntgHnUwlLPQ+WpZTMvK5mAmgJZV8xLYTG37E93lIONcM4NeE4R86wIB7PT5cnvjU1z2m6xM8vup07BoHN/Kt4o7vMfsjUQBQAiqukiwtXqr6jGG+urCZmEhwghFKZ6wY6A8ZqphFsttwJdb7+gtHJxsyAkzGe3BBQFfBxiUfZ3cich9a9wjFH4O23znQRUOMTqHA0UVNCV/1VfGrZPXK5FT6jLdLflkTWlW287n4I3m2FTHf+crk8QZucqFVQvxJHUkKrmSuLGW6ZSWGe4FZeAcnds63T9rDiyhlXERgjjkvSRzEknXd65QSUedboIXbo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.007950, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Zhang Yi writes: > From: Zhang Yi > > The cached delalloc or hole extent should be trimed to the map->map_len > if we map delalloc blocks in ext4_da_map_blocks(). Why do you say the cached delalloc extent should also be trimemd to m_len? Because we are only inserting delalloc blocks of min(hole_len, m_len), right? If we find delalloc blocks, we don't need to insert anything in ES cache. So we just return 0 in such case in this function. > But it doesn't > trigger any issue now because the map->m_len is always set to one and we > always insert one delayed block once a time. Fix this by trim the extent > once we get one from the cached extent tree, prearing for mapping a > extent with multiple delalloc blocks. > Yes, it wasn't clear until I looked at the discussion in the other thread. It would be helpful if you could use that example in the commit msg here for clarity. """ Yeah, now we only trim map len if we found an unwritten extent or written extent in the cache, this isn't okay if we found a hole and ext4_insert_delayed_block() and ext4_da_map_blocks() support inserting map->len blocks. If we found a hole which es->es_len is shorter than the length we want to write, we could delay more blocks than we expected. Please assume we write data [A, C) to a file that contains a hole extent [A, B) and a written extent [B, D) in cache. A B C D before da write: ...hhhhhh|wwwwww.... Then we will get extent [A, B), we should trim map->m_len to B-A before inserting new delalloc blocks, if not, the range [B, C) is duplicated. """ Minor nit: ext4_da_map_blocks() function comments have become stale now. It's not clear of it's return value, the lock it uses etc. etc. If we are at it, we might as well fix the function description. -ritesh