On Sat, Feb 21, 2026 at 12:41:28PM -0500, 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. > > Mike
Thinking about this work from a DM multipath perspective, I'm more interested in how much it plans to handle the more annoying niche cases of dealing with SCSI devices, like paths that confidently report that they are able to accept IO, only to fail all IO sent to them. Also, I wonder how/if this is planning on handling Persistent Reservations. The arrays, I assume, are still going to see this as a collection of I_T Nexuses (some of which may be down and unable to accept commands at any given time, and to which new ones my be added) instead of a single one. I also think this would be useful to talk about at LSF. -Ben > > > c. add native SCSI multipath support based on this common library > > > > Thanks, > > John > > > > > >
