On Fri, Aug 26, 2016 at 03:29:34PM -0600, Ross Zwisler wrote: > On Thu, Aug 25, 2016 at 12:57:28AM -0700, Christoph Hellwig wrote: > > Hi Ross, > > > > can you take at my (fully working, but not fully cleaned up) version > > of the iomap based DAX code here: > > > > http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/iomap-dax > > > > By using iomap we don't even have the size hole problem and totally > > get out of the reverse-engineer what buffer_heads are trying to tell > > us business. It also gets rid of the other warts of the DAX path > > due to pretending to be like direct I/O, so this might be a better > > way forward also for ext2/4. > > In general I agree that the usage of struct iomap seems more straightforward > than the old way of using struct buffer_head + get_block_t. I really don't > think we want to have two competing DAX I/O and fault paths, though, which I > assume everyone else agrees with as well. We'll be moving XFS this way, regardless of whether the generic DAX code goes that way or not. iomap is a much cleaner, more efficient interface than get_blocks via bufferheads. We are slowly removing bufferheads from XFS so anything that uses them or depends on them that Xfs requires is going to have an iomap-based variant written for it. Christoph is doing the hard yards to make iomap a VFS level interface because that's a) the most efficient way to implement it, and b) it's the right place for IO path extent mapping abstractions. So there will be a iomap path for DAX, just like there will be a iomap path for direct IO, regardless of what other filesystems implement. i.e. other filesystems can move to the more efficient iomap infrastructure if they want, but we can't force them to do so. As such, the generic DAX path can either remain as it is, or we can move to iomap and use wrappers for converting get_block() + bufferehead to iomaps on non-iomap filesystems. (i.e. similar to the existing iomap_to_bh() for allowing iomap lookups to be used to replace bufferheads returned by get_block().) I'd much prefer we move DAX to iomaps before there is wider uptake of it in other filesystems - I've been saying we should use iomaps for DAX right from the start. Now we have the iomap infrastructure in place we should jump straight to it. If we have to drag ext4 kicking and screaming into the 1990s to get there then so be it - it won't be the first time... > These changes don't remove the things in XFS needed by the old I/O and fault > paths (e.g. xfs_get_blocks_direct() is still there an unchanged). Is the Yes, they'll remain until their functionality has been replaced by iomap functions. e.g. xfs_get_blocks_direct() can't be removed until the direct IO path has an iomap interface. .... > 6) Regarding the "we don't even have the size hole problem" comment in your > mail, the current PMD logic requires us to know the size of the hole. This .... > The current XFS code in the v4.8 tree tells me the size of the hole, and I > think we need to keep this functionality. IOMAP_HOLE extents. It's a requirement of the iomap infrastructure that the filesystem reports hole extents in full for the range being mapped. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
