From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:53612 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752466AbcDKGTR (ORCPT ); Mon, 11 Apr 2016 02:19:17 -0400 Date: Mon, 11 Apr 2016 16:17:40 +1000 From: Dave Chinner To: Christoph Hellwig Cc: Bob Peterson , linux-fsdevel@vger.kernel.org, Jan Kara , Al Viro Subject: Re: [vfs PATCH v3 1/4] VFS: move iomap from exportfs.h to iomap.h Message-ID: <20160411061740.GH567@dastard> References: <1457122300-28514-1-git-send-email-rpeterso@redhat.com> <1457122300-28514-2-git-send-email-rpeterso@redhat.com> <20160315072912.GE11669@infradead.org> <690524895.44280573.1459194784327.JavaMail.zimbra@redhat.com> <20160329074026.GD8568@infradead.org> <20160329222036.GD30721@dastard> <20160410171528.GA9118@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160410171528.GA9118@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Apr 10, 2016 at 10:15:28AM -0700, Christoph Hellwig wrote: > On Wed, Mar 30, 2016 at 09:20:36AM +1100, Dave Chinner wrote: > > QA over the past couple of days has indicatedno regressions, so I'm > > going to seriously consider the multipage write code for the next > > XFS merge. I'd be happy to also take fiemap code based on the same > > iomap interfaces, especially if we can make it a generic, fully > > functional fiemap implementation and use it in XFS, too. > > Now that's I've spent some more time with it: it depend on your > idea of fully functional. For the actual file data the fiemap > implementation is simple and beautiful. But XFS also supports the > odd FIEMAP_FLAG_XATTR flags, which makes no sense at all for an > fiemap based implementation. In this case, I'd let xfs_vn_fiemap handle that. i.e. if the FIEMAP_FLAG_XATTR is set, run the old code, otherwise call straight into the new generic iomap based code. I'm not sure if how your new code is structured, but n this version __generic_iomap_fiemap() is passed an iomap_get_t callback function. We could simply have XFS pass a different callback function that looks up the attribute fork extent list rather than the data fork extent list to support FIEMAP_FLAG_XATTR appropriately because other than the different initial extent list root it seems to me like the implementation should be identical.... Cheers, Dave. -- Dave Chinner david@fromorbit.com