On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote: > On Thu, Feb 16 2017 at 9:26am -0500, > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > just a little new code in the block layer, and a move of the path > > selectors from dm to the block layer. I would not call this > > fragmentation. > > I'm fine with the path selectors getting moved out; maybe it'll > encourage new path selectors to be developed. > > But there will need to be some userspace interface stood up to support > your native NVMe multipathing (you may not think it needed but think in > time there will be a need to configure _something_). That is the > fragmentation I'm referring to. I'm not sure what Christoph's proposal looks like, but I have to agree that multipath support directly in the kernel without requiring user space to setup the mpath block device is easier for everyone. The only NVMe specific part, though, just needs to be how it reports unique identifiers to the multipath layer. Maybe I'm not seeing the bigger picture. Is there some part to multipath that the kernel is not in a better position to handle?
