Re: Snapshot target and DAX-capable devices

From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
	Jeff Moyer <jmoyer@redhat.com>, Mike Snitzer <snitzer@redhat.com>,
	"Kani, Toshi" <toshi.kani@hpe.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>
Subject: Re: Snapshot target and DAX-capable devices
Date: Wed, 5 Sep 2018 11:25:57 +1000	[thread overview]
Message-ID: <20180905012557.GE27618@dastard> (raw)
In-Reply-To: <20180831094255.GB11622@quack2.suse.cz>

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@fromorbit.com