From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:49752 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755757AbeFOHzA (ORCPT ); Fri, 15 Jun 2018 03:55:00 -0400 Date: Fri, 15 Jun 2018 10:03:27 +0200 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Christoph Hellwig , linux-xfs@vger.kernel.org, Dan Williams , linux-fsdevel , cluster-devel , linux-ext4 Subject: Re: iomap preparations for GFS2 v2 Message-ID: <20180615080326.GB19525@lst.de> References: <20180614120457.28285-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jun 14, 2018 at 03:04:38PM +0200, Andreas Gruenbacher wrote: > I saw that you've pushed this onto the gfs2-iomap branch in your xfs > repository. I've rebased the gfs2 iomap-write branch onto that; > there's a trivial patch for adding a private pointer to struct iomap > at the head of that branch that would sense to move to the shared > branch as well now. Please send that patch out ASAP. > The next step would probably be to start using iomap_readpage / > iomap_readpages in gfs2 for block size == page size. This requires > adding inline data support to iomap_readpage which is trivial, but > because of gfs2's reliance on buffer heads, that alone isn't enough. Is it? At least for block size == page size we will only call readpage on a pristine, newly allocated page. So buffer heads won't be in the game at that point, and the iomap buffered write code will just allocate them for you once we start a write operation, or take a page fault that makes the page writable. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: iomap preparations for GFS2 v2 Date: Fri, 15 Jun 2018 10:03:27 +0200 Message-ID: <20180615080326.GB19525@lst.de> References: <20180614120457.28285-1-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: cluster-devel , linux-xfs@vger.kernel.org, linux-fsdevel , Dan Williams , linux-ext4 , Christoph Hellwig 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 Thu, Jun 14, 2018 at 03:04:38PM +0200, Andreas Gruenbacher wrote: > I saw that you've pushed this onto the gfs2-iomap branch in your xfs > repository. I've rebased the gfs2 iomap-write branch onto that; > there's a trivial patch for adding a private pointer to struct iomap > at the head of that branch that would sense to move to the shared > branch as well now. Please send that patch out ASAP. > The next step would probably be to start using iomap_readpage / > iomap_readpages in gfs2 for block size == page size. This requires > adding inline data support to iomap_readpage which is trivial, but > because of gfs2's reliance on buffer heads, that alone isn't enough. Is it? At least for block size == page size we will only call readpage on a pristine, newly allocated page. So buffer heads won't be in the game at that point, and the iomap buffered write code will just allocate them for you once we start a write operation, or take a page fault that makes the page writable. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Fri, 15 Jun 2018 10:03:27 +0200 Subject: [Cluster-devel] iomap preparations for GFS2 v2 In-Reply-To: References: <20180614120457.28285-1-hch@lst.de> Message-ID: <20180615080326.GB19525@lst.de> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Jun 14, 2018 at 03:04:38PM +0200, Andreas Gruenbacher wrote: > I saw that you've pushed this onto the gfs2-iomap branch in your xfs > repository. I've rebased the gfs2 iomap-write branch onto that; > there's a trivial patch for adding a private pointer to struct iomap > at the head of that branch that would sense to move to the shared > branch as well now. Please send that patch out ASAP. > The next step would probably be to start using iomap_readpage / > iomap_readpages in gfs2 for block size == page size. This requires > adding inline data support to iomap_readpage which is trivial, but > because of gfs2's reliance on buffer heads, that alone isn't enough. Is it? At least for block size == page size we will only call readpage on a pristine, newly allocated page. So buffer heads won't be in the game at that point, and the iomap buffered write code will just allocate them for you once we start a write operation, or take a page fault that makes the page writable.