On Wed, Oct 21, 2020 at 7:24 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > Hey Dan, > > On Fri, Oct 16, 2020 at 6:38 PM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > On Fri, Oct 16, 2020 at 2:59 PM Nabeel Meeramohideen Mohamed > > (nmeeramohide) <nmeeramohide@xxxxxxxxxx> wrote: > > > > > (5) Representing an mpool as a /dev/mpool/<mpool-name> device file provides a > > > convenient mechanism for controlling access to and managing the multiple storage > > > 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?
