From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f67.google.com ([209.85.214.67]:36390 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755244AbeFNNEj (ORCPT ); Thu, 14 Jun 2018 09:04:39 -0400 Received: by mail-it0-f67.google.com with SMTP id j135-v6so8562634itj.1 for ; Thu, 14 Jun 2018 06:04:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180614120457.28285-1-hch@lst.de> References: <20180614120457.28285-1-hch@lst.de> From: Andreas Gruenbacher Date: Thu, 14 Jun 2018 15:04:38 +0200 Message-ID: Subject: Re: iomap preparations for GFS2 v2 To: Christoph Hellwig Cc: linux-xfs@vger.kernel.org, Dan Williams , linux-fsdevel , cluster-devel , linux-ext4 Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 14 June 2018 at 14:04, Christoph Hellwig wrote: > Hi all, > > this is a slight rework of the patches from Andreas to prepare for gfs2 > using the iomap code. > > Note: I'd like to start with an immutable branch for iomap patches in either > the XFS tree or a tree of mine at the beginning of the merge window so that > we have a common base for the GFS2 and XFS iomap work. > > Changes since v1: > - move code to a different spot in iomap.c to prefer for readpages > inline data support > - add a forward declaration for struct page to iomap.h > - fix a typo in the dax_dev/bdev unioning > - fix a comment typo 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. 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. Thanks, Andreas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Subject: Re: iomap preparations for GFS2 v2 Date: Thu, 14 Jun 2018 15:04:38 +0200 Message-ID: References: <20180614120457.28285-1-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: linux-xfs@vger.kernel.org, linux-fsdevel , Dan Williams , cluster-devel , linux-ext4 To: Christoph Hellwig Return-path: In-Reply-To: <20180614120457.28285-1-hch@lst.de> 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 14 June 2018 at 14:04, Christoph Hellwig wrote: > Hi all, > > this is a slight rework of the patches from Andreas to prepare for gfs2 > using the iomap code. > > Note: I'd like to start with an immutable branch for iomap patches in either > the XFS tree or a tree of mine at the beginning of the merge window so that > we have a common base for the GFS2 and XFS iomap work. > > Changes since v1: > - move code to a different spot in iomap.c to prefer for readpages > inline data support > - add a forward declaration for struct page to iomap.h > - fix a typo in the dax_dev/bdev unioning > - fix a comment typo 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. 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. Thanks, Andreas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Date: Thu, 14 Jun 2018 15:04:38 +0200 Subject: [Cluster-devel] iomap preparations for GFS2 v2 In-Reply-To: <20180614120457.28285-1-hch@lst.de> References: <20180614120457.28285-1-hch@lst.de> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 14 June 2018 at 14:04, Christoph Hellwig wrote: > Hi all, > > this is a slight rework of the patches from Andreas to prepare for gfs2 > using the iomap code. > > Note: I'd like to start with an immutable branch for iomap patches in either > the XFS tree or a tree of mine at the beginning of the merge window so that > we have a common base for the GFS2 and XFS iomap work. > > Changes since v1: > - move code to a different spot in iomap.c to prefer for readpages > inline data support > - add a forward declaration for struct page to iomap.h > - fix a typo in the dax_dev/bdev unioning > - fix a comment typo 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. 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. Thanks, Andreas