[lkml]   [2019]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: lift the xfs writepage code into iomap v3
Hi Christoph,

On Mon, 22 Jul 2019 at 11:50, Christoph Hellwig <> wrote:
> 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.
> Changes since v2:
> - rebased to v5.3-rc1
> - folded in a few changes from the gfs2 enablement series

thanks for the much appreciated update.

I've added that and the remaining gfs2 iomap patches to this branch:

git:// iomap

Your final patch on this branch, "gfs2: use iomap for buffered I/O in
ordered and writeback mode", still causes the following four xfstest

generic/311 generic/322 generic/393 generic/418

The bug in generic/393 is that in the nobh case, when unstuffing an
inode, we fail to dirty the unstuffed page and so the page is never
written. This should be easy to fix. The other failures have other
causes (still investigating).

> 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


 \ /
  Last update: 2019-07-22 22:12    [W:0.139 / U:3.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site