On Fri, Jan 15, 2021 at 02:57:45PM +0100, Klaus Jensen wrote: > > As you already mentioned, the problem I see with this approach is that > we have separate namespaces attached to separate controllers. So we are > faking it to the max and if I/O starts going through the other > controller we end up on a namespace that is unrelated (different data). > Havoc ensues. > > My approach looks a lot like yours, but I hacked around this by adding > extra 'ctrl-0', 'ctrl-1', ..., link-parameters to the namespace device, > replacing the bus. This works well because the namespace then just > registers with multiple controllers. But adding more parameters like > that just isnt nice, so I've been trying to figure out how to allow a > parameter to be specified multiple times, so we could just do more > 'ctrl'-parameters. > > Alas, since I started thinking about namespace sharing I have been > regretting that I didn't reverse the bus-mechanic for namespace > attachment. It would align better with the theory of operation if it was > the controllers that attached to namespaces, and not the other way > around. So what I would actually really prefer, is that we had multiple > 'ns' link parameters on the controller device.
Would this work better if we introduce a new device in the nvme hierarchy: the nvme-subsystem? You could attach multi-path namespaces and controllers to that, and namespaces you don't want shared can attach directly to controllers like they do today. You could also auto-assign cntlid, and you wouldn't need to duplicate serial numbers in your parameters.