Re: [PATCH v3 02/13] dax: require 'struct page' for filesystem dax

[Christoph Hellwig <hch@lst.de>]

On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote:
> > For example, I think it's entirely sensible to support ->direct_access
> > for RAID-0.  Dell are looking at various different options for having
> > one pmemX device per DIMM and using RAID to lash them together.
> > ->direct_access makes no sense for RAID-5 or RAID-1, but RAID-0 makes
> > sense to me.
> >
> > Last time we tried to take sleeping out, there were grumblings from people
> > with network block devices who thought they'd want to bring pages in
> > across the network.  I'm a bit less sympathetic to this because I don't
> > know anyone actively working on it, but the RAID-0 case is something I
> > think we should care about.
> 
> True, good point. In fact we already support device-mapper striping
> with ->direct_access(). I'd still like to go ahead with the sleeping
> removal. When those folks come back and add network direct_access they
> can do the hard work of figuring out cases where we need to call
> direct_access in atomic contexts.

It would be great to move DAX striping out of DM so that we don't need
to keep fake block devices around just for that.  In fact if Dell is so
interested in it it would be great if they get a strip/concact table
into ACPI so that the bios and OS can agree on it in a standardized way,
and we can just implement it in the nvdimm layer.

I agree that there is no reason at all to support sleeping in
->direct_access - it makes life painful for no gain at all.  If you
network access remote memory you will need local memory to support
mmap, so we might as well use the page cache instead of reinventing
it. (saying that with my remote pmem over NFS hat on).
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm