From: Christoph Hellwig Subject: Re: iomap preparations for GFS2 v2 Date: Tue, 19 Jun 2018 16:35:50 +0200 Message-ID: <20180619143550.GA15162@lst.de> References: <20180614120457.28285-1-hch@lst.de> <20180615080326.GB19525@lst.de> <5a1e303b-e96e-7faf-1bcd-36d63a237514@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-xfs@vger.kernel.org, Christoph Hellwig , cluster-devel , linux-fsdevel , Dan Williams , linux-ext4 To: Andreas Gruenbacher Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cluster-devel-bounces@redhat.com Errors-To: cluster-devel-bounces@redhat.com List-Id: linux-ext4.vger.kernel.org On Tue, Jun 19, 2018 at 01:08:12PM +0200, Andreas Gruenbacher wrote: > What I'm seeing in the readpage address space operation is pages which > are not PageUptodate(), with a page-size buffer head that is > buffer_uptodate(). The filesystem doesn't bother keeping the page > flags in sync with the buffer head flags, nothing unusual. It is in fact highly unusual, as all the generic routines do set the page uptodate once all buffers are uptodate. > When > iomap_readpage is called on such a page, it will replace the current > contents with what's on disk, losing the changes in memory. So we > cannot just call iomap_readpages, we need to check the buffer head > flags as well. Or, since the old code is still needed for page size != > block size anyway, we can fall back to that for pages that have > buffers for now. I'd like to understand where that buffer_head comes from, something seems fishy here.