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. -- 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
