On Sat, Mar 10, 2018 at 11:58:50AM +1100, Dave Chinner wrote: > > Probably the best idea, but see fs/iomap.c since we're basically leasing > > a chunk of file space to the kernel. Leasing space to a user that wants > > direct access is becoming rather common (rdma, map_sync, etc.) > > thing is, we don't want in-kernel users of fiemap. We've got other > block mapping interfaces that can be used, such as iomap... Agreed. fiemap is in many ways just as bad as bmap - it is an information at a given point in time interface. It is more detailed than bmap and allows better error reporting, but it still is fundamentally the wrong thing to use for any sort of the I/O path. > > > > 3. Add an XFS-specific implementation of swapfile_activate. > > > > Ugh no. > > What we want is an iomap-based re-implementation of > generic_swap_activate(). One of the ways to plumb that in is to > use ->swapfile_activate() like so: Hmm. Fundamentally swap is the same problem as the pNFS block layout or get_user_pages on DAX mappings - we want to get a 'lease' on the current block mapping, and make sure it stays that way as the external user (the swap code in this case) uses it. The twist for the swap code is mostly that it never wants to break the least but instead disallow any external operation, but that's not really such a big difference. So maybe we want a layout based swap code instead of reinventing it, with the slight twist to the layout break code to never try a lease break and just return an error for the IS_SWAPFILE case. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
