Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp424841rdh; Thu, 23 Nov 2023 07:35:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IEaMWDd+jrXd1HSDfpQCT/BSX3Cy/rGuaMkAlhpQI/4NrephWef4V57UzyeLp65i1CeZ54x X-Received: by 2002:a05:6a00:3a1d:b0:6cb:bb92:1ce6 with SMTP id fj29-20020a056a003a1d00b006cbbb921ce6mr6689830pfb.18.1700753746594; Thu, 23 Nov 2023 07:35:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700753746; cv=none; d=google.com; s=arc-20160816; b=Uo5DuXckAiAf7C8U4DcnzwiYN2/lJIeM2Ad5PLIP8FF+IoJN6n+GDeNPWmFJ1b1WD9 5lKksl8YwCrXa2+53oaxcOAIl9QMhADQkkeCUEfoVbbgvH1KpgBPgrkmz2uZZvamQz91 Wn9WZrBJ3OYFEaIsKUEObiEr4eX+ARKVTAYUR3RJc6P0CQ0M6uhHN3eXJZ1uki3uiSBZ NFWxk0gnzXxIMwrT16LBYSc6akyiQuPvg7cEuVgt6wbnm43to0EGQAhIkkaynTmpe0xR JDSi9ZHH+GveQEw8niNYAgNH7ZngyoEUErk/f9vVYCY3/hz32vITfKmdGOeLUExbh9Mk b9dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=wk5beXennXPU1SdLfS4CekuNuzZhsJLb/G4f8HExOZI=; fh=qFAqQTgpIRUgXkg+LY5q9yRBUwq4h2GKY5u6/1brSxg=; b=CwKoFU6FcfWKOTlXiNUHbAuiAZTdbdfFavtjcLyd6VhseXNdat31rpGDzld+xoU5Wr ynbPLyggobbXOT9AJmZuMdrACFyX0mjx+mo0mxD1RJmcDm00AcE3r4u/QyS021I55xIA 54//fttlrJjSwZDEepQPrnUQaSzyOuvkh/klMZbGN860peG/QebBXpwwDtsxEggmAE6g AyxhbYu1QVqtK/1v2flisHwj3ZeDXQmsLfk1mnDcPpKHXUZ1+NLvuRDQa3SltqXDe+e2 FwnRVYdNZSUkUbTj5Gsq4k8KgE+vttzxDOWlY0i7J4LmZ0jFfrN2R8FGGNFB5ZBhfkAw +WmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=eh3KgSzc; spf=pass (google.com: domain of linux-ext4+bounces-125-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-ext4+bounces-125-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id o16-20020a056a0015d000b006cb83204cffsi1473937pfu.256.2023.11.23.07.35.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 07:35:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4+bounces-125-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=eh3KgSzc; spf=pass (google.com: domain of linux-ext4+bounces-125-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-ext4+bounces-125-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id E2E49B211B6 for ; Thu, 23 Nov 2023 15:35:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9E5603D3BC; Thu, 23 Nov 2023 15:35:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="eh3KgSzc" X-Original-To: linux-ext4@vger.kernel.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29EB1D5E; Thu, 23 Nov 2023 07:34:48 -0800 (PST) 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=wk5beXennXPU1SdLfS4CekuNuzZhsJLb/G4f8HExOZI=; b=eh3KgSzcXHHolOUfODGVniOzlM xWvgTv6KbdnOfsqJ9d7UYC+7ZtNGImHkOgjDIcHy9sfGjUroJifQrzIbmP724hZSzC9lNZdzgOl14 F3DxX9pEmiVQdnmOM90BTxj8KkFUyOwuYYQUNV4/AsTtGcuj173RqQHSI0a2DVXcW/A1Tf5NPqHKc X/j0M3yJqLEo40vplXSVgc0MStWXqjx0CMBxT/3wB/W8NPsSFdjof84RRTfo959pOiS3jxKgoIo7L OYfUWr5DelZqryH8LQeXAh7QYkNU90TcIOL/wYENwMWrSrnmgooIiM8DbYDPpr3VCR8JuvHwFzYbs eRMuuQ9Q==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1r6Bj4-005BPU-0v; Thu, 23 Nov 2023 15:34:46 +0000 Date: Thu, 23 Nov 2023 07:34:46 -0800 From: Christoph Hellwig To: Zhang Yi Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: Re: [RFC PATCH 12/18] iomap: don't increase i_size if it's not a write operation Message-ID: References: <20231123125121.4064694-1-yi.zhang@huaweicloud.com> <20231123125121.4064694-13-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231123125121.4064694-13-yi.zhang@huaweicloud.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Thu, Nov 23, 2023 at 08:51:14PM +0800, Zhang Yi wrote: > index fd4d43bafd1b..3b9ba390dd1b 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -852,13 +852,13 @@ static size_t iomap_write_end(struct iomap_iter *iter, loff_t pos, size_t len, > * cache. It's up to the file system to write the updated size to disk, > * preferably after I/O completion so that no stale data is exposed. > */ > - if (pos + ret > old_size) { > + if ((iter->flags & IOMAP_WRITE) && pos + ret > old_size) { > i_size_write(iter->inode, pos + ret); > iter->iomap.flags |= IOMAP_F_SIZE_CHANGED; > } > __iomap_put_folio(iter, pos, ret, folio); > > - if (old_size < pos) > + if ((iter->flags & IOMAP_WRITE) && old_size < pos) > pagecache_isize_extended(iter->inode, old_size, pos); > if (ret < len) > iomap_write_failed(iter->inode, pos + ret, len - ret); I agree with your rationale, but I hate how this code ends up looking. In many ways iomap_write_end seems like the wrong place to update the inode size anyway. I've not done a deep analysis, but I think there shouldn't really be any major blocker to only setting IOMAP_F_SIZE_CHANGED in iomap_write_end, and then move updating i_size and calling pagecache_isize_extended to iomap_write_iter.