I think the difference from scsi-generic and controller nvme passthru is
that this is a mpath device node (or mpath chardev). This is why I think
that users would expect that it would have equivalent multipath
capabilities (i.e. failover).
How is that different from /dev/sg?
/dev/sg it is not a multipath device.
Maybe the solution is to just not expose a /dev/ng for the mpath device
node, but only for bottom namespaces. Then it would be completely
equivalent to scsi-generic devices.
It just creates an unexpected mix of semantics of best-effort
multipathing with just path selection, but no requeue/failover...
In general, I think that uring passthru as an alternative I/O interface
and as such needs to be able to failover. If this is not expected from
the interface, then why are we exposing a chardev for the mpath device
node? why not only the bottom namespaces?
The failover will happen when you retry, but we leave that retry to
userspace. There even is the uevent to tell userspace when a new
path is up.
If the user needs to do the retry, discover and understand namespace
paths, ANA states, controller states, etc. Why does the user need a
mpath chardev at all?
The user basically needs to understand everything including indirectly
path selection for the I/O. IMO it is cleaner for the user to just have
the bottom devices and do the path selection directly.
