On Tue, Apr 12, 2016 at 11:29:40AM -0700, Christoph Hellwig wrote: > On Mon, Apr 11, 2016 at 04:17:40PM +1000, Dave Chinner wrote: > > 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.... > > Providing iomap_ops for the xattr flag look feasily, but currently > there is no real testing for it. Only fsstress will call into it > at all and doesn't even verify the output. I'll send the iomap > implementation and XFS support as RFC, and then you can decide what > to do with it. Sure. FWIW, the xfs_io fiemap command is able to query the attribute fork rather than the data fork. I suspect it's not actually used in any regression tests in xfstests, though. 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
