[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190730011705.GO1561054@magnolia>
Date: Mon, 29 Jul 2019 18:17:05 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: Damien Le Moal <Damien.LeMoal@....com>,
Andreas Gruenbacher <agruenba@...hat.com>,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: lift the xfs writepage code into iomap v3
On Mon, Jul 22, 2019 at 11:50:12AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series cleans up the xfs writepage code and then lifts it to
> fs/iomap.c so that it could be use by other file system. I've been
> wanting to this for a while so that I could eventually convert gfs2
> over to it, but I never got to it. Now Damien has a new zonefs
> file system for semi-raw access to zoned block devices that would
> like to use the iomap code instead of reinventing it, so I finally
> had to do the work.
I've posted a branch against -rc2 for us all to work from:
https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/log/?h=iomap-writeback
and will be emailing the patches shortly to the list for completeness.
--D
>
>
> Changes since v2:
> - rebased to v5.3-rc1
> - folded in a few changes from the gfs2 enablement series
>
> Changes since v1:
> - rebased to the latest xfs for-next tree
> - keep the preallocated transactions for size updates
> - rename list_pop to list_pop_entry and related cleanups
> - better document the nofs context handling
> - document that the iomap tracepoints are not a stable API
Powered by blists - more mailing lists