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...
Which is exactly the same semanics as SG_IO on the dm-mpath nodes.
I view uring passthru somewhat as a different thing than sending SG_IO
ioctls to dm-mpath. But it can be argued otherwise.
BTW, the only consumer of it that I'm aware of commented that he
expects dm-mpath to retry SG_IO when dm-mpath retry for SG_IO submission
was attempted (https://www.spinics.net/lists/dm-devel/msg46924.html).
From Paolo:
"The problem is that userspace does not have a way to direct the command
to a different path in the resubmission. It may not even have permission
to issue DM_TABLE_STATUS, or to access the /dev nodes for the underlying
paths, so without Martin's patches SG_IO on dm-mpath is basically
unreliable by design."
I didn't manage to track down any followup after that email though...
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 needs to do that for all kinds of other resons anyway,
as we don't do any retries for passthrough at all.
I still think that there is a problem with the existing semantics for
passthru requests over mpath device nodes.
Again, I think it will actually be cleaner not to expose passthru
devices for mpath at all if we are not going to support retry/failover.
