On Fri, Aug 31, 2018 at 11:42:55AM +0200, Jan Kara wrote: > On Fri 31-08-18 09:38:09, Dave Chinner wrote: > > On Thu, Aug 30, 2018 at 03:47:32PM -0400, Mikulas Patocka wrote: > > > You can't support dax on snapshot - if someone maps a block and the block > > > needs to be moved, then what? > > > > This is only a problem for access via mmap and page faults. .... > > It's a whole different ballgame for a dm-snapshot device - block > > devices are completely unaware of page faults to DAX file mappings. > > Actually, block devices are not completely unaware of DAX page faults - > they will get ->direct_access callback for the fault range. It does not > currently convey enough information - we also need to inform the block > device whether it is read or write. But that's about all that's needed to > add AFAICT. And by comparing returned PFN with the one we have stored in > the radix tree (which we have if that file offset is mapped by anybody), > the filesystem / DAX code can tell whether remapping happened and do the > unmapping. I forgot about the direct access call. But it seems like a hack to redefine the simple, fast sector-to-pfn translation into a slow and potentially resource hungry interface for physical storage reallocation. Doing storage layer COW operations inside direct_access takes us straight back to the bad ways of get_block() interfaces. We moved all the filesystem allocation to iomap so that the storage management is separated from the mm/physical address translation side of DAX - doing block device storage management operations inside ->direct_access effectively reverts that separation and so just seems like a hack to me. Oh, right, DAX. Silly me. :/ Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
