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 20C8CC47DD9 for ; Wed, 28 Feb 2024 22:13:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8347B6B009D; Wed, 28 Feb 2024 17:13:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E4506B009E; Wed, 28 Feb 2024 17:13:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AB916B009F; Wed, 28 Feb 2024 17:13:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5C95A6B009D for ; Wed, 28 Feb 2024 17:13:39 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EF5C41211ED for ; Wed, 28 Feb 2024 22:13:38 +0000 (UTC) X-FDA: 81842615316.21.4EF709F Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf03.hostedemail.com (Postfix) with ESMTP id C1E0A2001A for ; Wed, 28 Feb 2024 22:13:32 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="GI/raViF"; dmarc=none; spf=none (imf03.hostedemail.com: domain of BATV+80e602b954c1195f2bb5+7493+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+80e602b954c1195f2bb5+7493+infradead.org+hch@bombadil.srs.infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709158413; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LLkbzykmttVYzbp2D3VuqEYjbZw4cd1Nkxs+BldTop8=; b=cIKskeuD2jTEouN+W3JHap4u29lw1uvQaOmn6mGfg1KWKe0Vg31+xyt//fDOMT/2gHtFXL aP/Iw+BplomZeUFhn6co9f9z8qW/RSkLGNjtY+E7VOHXwXJPZUWAkDSFE/ImSIBUnpcw00 X7qm5ZisKK5eankrIMmTDhWtGLbHg5g= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="GI/raViF"; dmarc=none; spf=none (imf03.hostedemail.com: domain of BATV+80e602b954c1195f2bb5+7493+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+80e602b954c1195f2bb5+7493+infradead.org+hch@bombadil.srs.infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709158413; a=rsa-sha256; cv=none; b=YaCx1DJh0qTu3bQIJgxhGnqkbuN3XbIs/m5DO5S6+OS7hDhyncJrz33FQXMnG6isKNl6tN ZUiJJ38diK/krABiJf8xfdINAZDPwfEl2zo1RfIKCzSIqUoaeKqphfq8PkfcQ1c1fkC7bk RFeWa37rc1erZY5jdZwX47+y9U3X54A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=LLkbzykmttVYzbp2D3VuqEYjbZw4cd1Nkxs+BldTop8=; b=GI/raViFDOZ9NZv3JyZyrTn6Cy ev1a9QtJ4WRg/ZTm2LMH/yw8pdW8rxyv+NB+wAz5WukIRkjjKPON+YyiDLngrKpOEX0KNVavlv3Qe uDW0GBTxbCB9Z3nDz+qwPhoXQtwnCTbkwhcm+C29pMuW42wklpOvQADJXj3G9Q13jgmZKw9W8GkMd 5vueTw9Jhvo9cQ94i1kq4Uss7N2tv76sbrGLHQOYM7hrAZlCEqa/UXRU0UGEHdAlSNhnb5ikVPRXb gHSeMz5MI7aRO+j83dXn7Lv4k+htMkHVPZ+5hLp9EDrjQgk/itsU5Kc3uS4Nkqjvtb9HNlsdKNuAT I9XXPgbA==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfSAx-0000000B6TL-0oZz; Wed, 28 Feb 2024 22:13:19 +0000 Date: Wed, 28 Feb 2024 14:13:19 -0800 From: Christoph Hellwig To: Zhang Yi Cc: Christoph Hellwig , djwong@kernel.org, Dave Chinner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ritesh.list@gmail.com, willy@infradead.org, zokeefe@google.com, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com Subject: Re: [RFC PATCH v3 07/26] iomap: don't increase i_size if it's not a write operation Message-ID: References: <20240127015825.1608160-1-yi.zhang@huaweicloud.com> <20240127015825.1608160-8-yi.zhang@huaweicloud.com> <9b0040ef-3d9d-6246-4bdd-82b9a8f55fa2@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b0040ef-3d9d-6246-4bdd-82b9a8f55fa2@huaweicloud.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Queue-Id: C1E0A2001A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qxh6efjgpkdq5fyuyry6fr9km4ks7iec X-HE-Tag: 1709158412-136284 X-HE-Meta: U2FsdGVkX18nH6UCWnYvaxqqea+BfXfnPzcq/24UMVKKZrY7V74JKgLve/NoNkkddanbL+mBxRdrf9/0djKWzjzthm9/GiR/EHg7Iwtufh9D11lmRv6XgwPtW/SYi7NTnuGuddaBIzANAJOofLc++nCZPSAWADVnfMLkY8OBs7KIWrU7CKwh27yD1stpiQC4iu1kyLfOBC1eD1/BU4+bZQrE4GJQfIWIdrr2jj6/PBAMA7xrw29TpkdspQ4IdTo+hTJ2fzHAoberoy4PNYzfK9ibOMK3km4UcGvI9vp1Vw1gzUDsZo7ZmYjuhEZinJ1LmrdpUTRwy+aLj+7w4xQQ1vYH/dBnx6SKC1LWikm9HL7xE4DFpEXVf3ngL+Se0Olp61gK1shPtlWiEWNB6fROZBu3K7YaExfVdhR7brcE5c2M/bjGD5EA9w0DEYsGA0AqL7Cpf0/EoCJpTB/gGTHNGnJrn+3nhXm1JlK/KTn22VKdsvyjh7UE9IMwhQf1bbJ0vtKswmQRL/76kaHWW80uOtLzA06DxKnwu++audyVa75wQDuf+ruBiGgR43aRCwFBK4wWE3HP/ArZrhTBqrKZIjxwizvWel5o2GZ+7TjsNh4r/KLTLk2adcD7lGpA7jyrOkKmdtpUvDc0eiTRGxgDmHH2yX4+2GWa5zln2WK3UZRzSfcY9XqvnaTq+bgBov9l7C22XIyvpOyhDLWYO+Xg53BO2K8lW6xPCVtIWPrRSiFBz9tKtgakew0sn1W707NHgqWnjm99RvuPAHKzBxLJ433d+f8hkQrey2XVTA80F54+ZC+9N0rmjv0em77CE0s5oN7G3TC7YaxfCNN8aFIpxZVfrybGgqfBoFh93opXnbUVzgaYMy9hHSApkA8k8P9ZALRNcPSPn/4oo6CyxLSGgtL+OIICqi+mRSMAVOb4qGK1hV02N5Xfvd1O9POsaBtG6201wIFlBhYtiZ3Y6bg WlwwNVYC iRAcok5l/OSH1YHKaLDjEniD1BVPLbA4Z7OlHA1oDkqayR5nHrestM4DJqwKgIbdHU5JKiwL/4WdeSGIUNboN0QO69ZPCKC0Y67fRaOImrVLgF/Jq4hQL0Cpp+632Fo0G6tiMr2kX3oDlIGcuQxtlNWkALcK/hb5YzvI1q/ABFZ2mj8ecauBFjx+r8asr7M8mTlduYUxX1BHUmRDZz88Jkz2MNzbR5RImTuyUBHikJBDjdBY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 28, 2024 at 04:53:32PM +0800, Zhang Yi wrote: > So, we have to handle above case for xfs. I suppose we could keep > increasing i_size if the zeroed folio is entirely outside of i_size, > make sure we could write back and allocate blocks for the > zeroed & delayed extent, something like below, any suggestions ? Sorry for being dumb, but what was the problem solved by not updating the size for ext4 again? (for unshare I can't see any reason to ever update the inode size)