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

[Hannes Reinecke]

On 2/16/26 17:55, John Garry wrote:
> On 16/02/2026 16:32, Hannes Reinecke wrote:
>>> cheers, in the meantime, I have some comments:
>>>
[ .. ]>>> - 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.
> 
Yeah, it should. In the end, the read/write path is less interesting
for 'raw' SCSI commands; I would think sg is more interesting for the
more obscure commands. And most of these would be path-specific anyway.

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

Fair enough. Eagerly awaiting the patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich