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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
