On Wed, Oct 21, 2020 at 7:24 AM Mike Snitzer <snitzer(a)redhat.com> wrote:
On Fri, Oct 16, 2020 at 6:38 PM Dan Williams <dan.j.williams(a)intel.com> wrote:
> On Fri, Oct 16, 2020 at 2:59 PM Nabeel Meeramohideen Mohamed
> (nmeeramohide) <nmeeramohide(a)micron.com> wrote:
> > (5) Representing an mpool as a /dev/mpool/<mpool-name> device file
> > convenient mechanism for controlling access to and managing the multiple
> > volumes, and in the future pmem devices, that may comprise an logical mpool.
> Christoph and I have talked about replacing the pmem driver's
> dependence on device-mapper for pooling.
Was this discussion done publicly or private? If public please share
a pointer to the thread.
I'd really like to understand the problem statement that is leading to
pursuing a pmem native alternative to existing DM.
IIRC it was during the hallway track at a conference. Some of the
concern is the flexibility to carve physical address space but not
attach a block-device in front of it, and allow pmem/dax-capable
filesystems to mount on something other than a block-device.
DM does fit the bill for block-device concatenation and striping, but
there's some pressure to have a level of provisioning beneath that.
The device-dax facility has already started to grow some physical
address space partitioning capabilities this cycle, see 60e93dc097f7
device-dax: add dis-contiguous resource support, and the question
becomes when / if that support needs to extend across regions is DM
the right tool for that?