[LSF/MM/BPF TOPIC] Native SCSI multipath support

[Mike Snitzer]

On Mon, Feb 16, 2026 at 05:32:04PM +0100, Hannes Reinecke wrote:
> On 2/14/26 10:42, John Garry wrote:
> > On 13/02/2026 17:21, Hannes Reinecke 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
> > > > c. add native SCSI multipath support based on this common library
> > > > 
> > > Go for it, John!
> > > 
> > > I'd be very interested in that.
> > 
> > cheers, in the meantime, I have some comments:
> > 
> > - I need to test PRs for both NVMe and SCSI, any advice on that would be
> > good. I don't think that blktests covers it. I did see Christoph mention
> > a testsuite at: https://lore.kernel.org/linux-nvme/1438672271-11309-1-
> > git-send-email-hch at lst.de/ - I can check that.
> > 
> Well, you might have seen the discussion on the device-mapper list, where
> stefanha is implementing generic PRs for dm-multipathing.
> Or rather, trying to. We might need to revisit that and see what we
> could be doing on the SCSI side.
> Maybe we should be having a session about PRs at LSF?
> 
> > - I am still not sure on whether we require a multipath version of sg.
> > We can still have per-path sg. NVMe does have a multipath nvme-generic
> > dev, but that just handles IOCTLs/uring cmd, and nothing like sg read/
> > write fops
> > 
> 'sg' is primarily for testing 'raw' SCSI commands. (And dastardly complex to
> boot). I really would keep it in it's current form, and not
> try to mimick something with SCSI multipathing.
> 
> > - I have not tried to detangle ALUA support from SCSI DH, so no ALUA
> > support yet
> > 
> Ouch. But that is the key point of the implementation; ALUA provides
> _all_ the information required for multipathing, so how can you _not_
> have support for it?

Exactly: no ALUA support makes, whatever this is, completely useless.