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

[John Garry]

On 16/02/2026 16:32, Hannes Reinecke wrote:
>> 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://urldefense.com/v3/__https:// 
>> lore.kernel.org/linux-nvme/1438672271-11309-1-__;!!ACWV5N9M2RV99hQ! 
>> NyU_EGj3duLYY2LeAfcU8f3WP67loAPsnqoz8qYMoV6CwqUgqWuoSE_VERaSDshSIbcmLG7zUhd4FfU$ 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?

maybe...

> 
>> - 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 can get to scsi_ioctl() from the multipath sd device ioctl - 
sd_ioctl() - maybe that is enough.

> 
>> - 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?

So far every path is just "optimised" and scsi_vpd_lun_id() is used to 
match scsi_devices ... ALUA support will be added, but if I were to do 
it now, it would just delay posting anything even further...