On Mon, Feb 1, 2016 at 1:47 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Mon, Feb 01, 2016 at 03:51:47PM +0100, Jan Kara wrote: >> On Sat 30-01-16 00:28:33, Matthew Wilcox wrote: >> > On Fri, Jan 29, 2016 at 11:28:15AM -0700, Ross Zwisler wrote: >> > > I guess I need to go off and understand if we can have DAX mappings on such a >> > > device. If we can, we may have a problem - we can get the block_device from >> > > get_block() in I/O path and the various fault paths, but we don't have access >> > > to get_block() when flushing via dax_writeback_mapping_range(). We avoid >> > > needing it the normal case by storing the sector results from get_block() in >> > > the radix tree. >> > >> > I think we're doing it wrong by storing the sector in the radix tree; we'd >> > really need to store both the sector and the bdev which is too much data. >> > >> > If we store the PFN of the underlying page instead, we don't have this >> > problem. Instead, we have a different problem; of the device going >> > away under us. I'm trying to find the code which tears down PTEs when >> > the device goes away, and I'm not seeing it. What do we do about user >> > mappings of the device? >> >> So I don't have a strong opinion whether storing PFN or sector is better. >> Maybe PFN is somewhat more generic but OTOH turning DAX off for special >> cases like inodes on XFS RT devices would be IMHO fine. > > We need to support alternate devices. Embedded devices trying to use NOR Flash to free up RAM was historically one of the more prevalent real world uses of the old filemap_xip.c code although the users never made it to mainline. So I spent some time last week trying to figure out how to make a subset of DAX not depend on CONFIG_BLOCK. It was a very frustrating and unfruitful experience. I discarded my main conclusion as impractical, but now that I see the difficultly DAX faces in dealing with "alternate devices" especially some of the crazy stuff btrfs can do, I wonder if it's not so crazy after all. Lets stop calling bdev_direct_access() directly from DAX. Let the filesystems do it. Sure we could enable generic_dax_direct_access() helper for the filesystems that only support single devices to make it easy. But XFS and btrfs for example, have to do the work of figuring out what bdev is required and then calling bdev_direct_access(). My reasoning is that the filesystem knows how to map inodes and offsets to devices and sectors, no matter how complex that is. It would even enable a filesystem to intelligently use a mix of direct_access and regular block devices down the road. Of course it would also make the block-less solution doable. Good idea? Stupid idea? -- 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
