Re: [Cluster-devel] RFC: use the iomap writepage path in gfs2
On Mon, 8 Jul 2019 at 18:04, Christoph Hellwig wrote: > On Thu, Jul 04, 2019 at 12:35:41AM +0200, Andreas Gruenbacher wrote: > > Patch "gfs2: implement gfs2_block_zero_range using iomap_zero_range" > > isn't quite ready: the gfs2 iomap operations don't handle IOMAP_ZERO > > correctly so far, and that needs to be fixed first. > > What is the issue with IOMAP_ZERO on gfs2? Zeroing never does block > allocations except when on COW extents, which gfs2 doesn't support, > so there shouldn't really be any need for additional handling. We still want to set iomap->page_ops for journalled data files on gfs2. Also, if we go through the existing gfs2_iomap_begin_write / __gfs2_iomap_begin logic for iomap_zero_range, it will work for stuffed files as well, and so we can replace stuffed_zero_range with iomap_zero_range. > > Some of the tests assume that the filesystem supports unwritten > > extents, trusted xattrs, the usrquota / grpquota / prjquota mount > > options. There shouldn't be a huge number of failing tests beyond > > that, but I know things aren't perfect. > > In general xfstests is supposed to have tests for that and not run > the tests if not supported. In most cases this is automatic, but > in case a feature can't be autodetect we have a few manual overrides. Yes, that needs a bit of work. Let's see. Thanks, Andreas
Re: [Cluster-devel] RFC: use the iomap writepage path in gfs2
On Mon, Jul 08, 2019 at 10:01:03AM +1000, Dave Chinner wrote: > Ok, this doesn't look too bad from the iomap perspective, though it > does raise more questions. :) > > gfs2 now has two iopaths, right? One that uses bufferheads for > journalled data, and the other that uses iomap? That seems like it's > only a partial conversion - what needs to be done to iomap and gfs2 > to support the journalled data path so there's a single data IO > path? gfs2 always had to very different writeback I/O paths, including a copy and pasted versiom of write_cache_pages for journaled data, they just diverge a little bit more now. In the longer run I'd also like to add journaled data support to iomap for use with XFS, and then also switch gfs2 to it.
Re: [Cluster-devel] RFC: use the iomap writepage path in gfs2
On Thu, Jul 04, 2019 at 12:35:41AM +0200, Andreas Gruenbacher wrote: > Patch "gfs2: implement gfs2_block_zero_range using iomap_zero_range" > isn't quite ready: the gfs2 iomap operations don't handle IOMAP_ZERO > correctly so far, and that needs to be fixed first. What is the issue with IOMAP_ZERO on gfs2? Zeroing never does block allocations except when on COW extents, which gfs2 doesn't support, so there shouldn't really be any need for additional handling. > Some of the tests assume that the filesystem supports unwritten > extents, trusted xattrs, the usrquota / grpquota / prjquota mount > options. There shouldn't be a huge number of failing tests beyond > that, but I know things aren't perfect. In general xfstests is supposed to have tests for that and not run the tests if not supported. In most cases this is automatic, but in case a feature can't be autodetect we have a few manual overrides.
Re: [Cluster-devel] RFC: use the iomap writepage path in gfs2
On Mon, Jul 01, 2019 at 11:54:24PM +0200, Christoph Hellwig wrote: > Hi all, > > in this straight from the jetplane edition I present the series to > convert gfs2 to full iomap usage for the ordered and writeback mode, > that is we use iomap_page everywhere and entirely get rid of > buffer_heads in the data path. This has only seen basic testing > which ensured neither 4k or 1k blocksize in ordered mode regressed > vs the xfstests baseline, although that baseline tends to look > pretty bleak. > > The series is to be applied on top of my "lift the xfs writepage code > into iomap v2" series. Ok, this doesn't look too bad from the iomap perspective, though it does raise more questions. :) gfs2 now has two iopaths, right? One that uses bufferheads for journalled data, and the other that uses iomap? That seems like it's only a partial conversion - what needs to be done to iomap and gfs2 to support the journalled data path so there's a single data IO path? Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [Cluster-devel] RFC: use the iomap writepage path in gfs2
Hi Christoph, On Mon, 1 Jul 2019 at 23:54, Christoph Hellwig wrote: > Hi all, > > in this straight from the jetplane edition I present the series to > convert gfs2 to full iomap usage for the ordered and writeback mode, > that is we use iomap_page everywhere and entirely get rid of > buffer_heads in the data path. thank you very much, this is looking very good. I've done some testing with your cleanups applied so that those can go in in this merge window. The result can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/log/?h=for-next.cleanups Patch "gfs2: implement gfs2_block_zero_range using iomap_zero_range" isn't quite ready: the gfs2 iomap operations don't handle IOMAP_ZERO correctly so far, and that needs to be fixed first. The actual buffer head removal will obviously have to wait a little longer because of the required infrastructure changes, but also because that still needs a lot more review and testing work. > This has only seen basic testing which ensured neither 4k or 1k blocksize > in ordered mode regressed vs the xfstests baseline, although that baseline > tends to look pretty bleak. Some of the tests assume that the filesystem supports unwritten extents, trusted xattrs, the usrquota / grpquota / prjquota mount options. There shouldn't be a huge number of failing tests beyond that, but I know things aren't perfect. > The series is to be applied on top of my "lift the xfs writepage code > into iomap v2" series. Again, thanks a lot for the patches! Andreas
