On 21/02/2026 17:41, Mike Snitzer wrote:
On Fri, Feb 13, 2026 at 02:19:11PM +0000, John Garry wrote:
At ALPSS 25 I presented a proposal for Native SCSI multipath support. Let's
discuss this topic at LSFMM.
The idea for this is that SCSI could natively support multipath, like how
NVMe host driver does today. It is intended as an alternative to
dm-multipath support.
I have been working on the implementation and I plan to post patches in the
next cycle. I am looking at a 3-stage approach:
a. create a driver-agnostic multipath library, very heavily based on NVMe
host multipath support.
The library would support features such as path management, path
selection/iopolicy, failover recovery, PR, delayed removal, gendisk
management etc.
b. switch NVMe over to use this library
I can appreciate that the kernel to userspace interface of DM
multipath is clearly unwanted (hence NVMe multipath and now SCSI
multipath).
But you should really be switching DM-multipath over to using it too;
or at least detailing_why_ the core of DM multipath
(drivers/md/dm-mpath.c) cannot be updated to use this common backend
library.
This line of work makes little sense to me if it just ignores
dm-multipath.
What I am proposing is refactoring the NVMe multipath code so that it
can be used for SCSI as well.
I am not sure where to begin on saying that this library would be
unsuitable dm-mpath. For a start, the bio flow is totally different.
Then path selection is totally different.
Anyway, I'll post the code this week and you can check it.
John
