Re: [PATCH v9 00/29] Native SCSI Multipath support

[John Garry <john.garry@linux.dev>]

On 11/14/26 13:03, Xose Vazquez Perez wrote:
> On 11/10/26 10:05 AM, John Garry wrote:
> 
>> On 11/9/26 20:19, Laurence Oberman wrote:
>>> 3. Smaller points
>>>
>>> - numa with equal NUMA distance uses one path per LUN, so with two AO
>>>    paths through two HBAs, half the optimized bandwidth is idle (sdl:2
>>>    above under numa). That matches NVMe, but users coming from
>>>    dm-multipath service-time will notice. Would round-robin or
>>>    queue-depth be a better default for SCSI?
>>
>> Maybe, but round-robin may not be always ideal considering only a bio 
>> mode of operation is supported and no merging like dm-mpath RQ mode.
> 
> iopolicy can easily be customized per array/device via udev rules.
> Just like it's done for NVMe:
> https://github.com/linux-nvme/nvme-cli/blob/master/nvmf-autoconnect/ 
> udev-rules/71-nvmf-hpe.rules.in

Sure

> 
> Additionally, "service-time" and "latency" I/O policies are currently under
> development:
> https://lore.kernel.org/linux-nvme/20261026111019.3724465-1- 
> kanie@linux.alibaba.com/T/
> https://lore.kernel.org/linux-nvme/20260815173502.1185929-1- 
> nilay@linux.ibm.com/T/

I already did an experimental port of the latency iopolicy to 
libmultipath. Porting iopolicy schemes to libmultipath is not too 
challenging, really.

> 
>>> - There is no userspace tool yet to show heads, paths and ALUA state
>>>    (the equivalent of multipath -ll or nvme list-subsys). I used a
>>>    small sysfs script for this testing. Ben, is native SCSI multipath
>>>    support in multipath-tools planned?
>>
>> Well, the whole point is that we don't need userspace tools. However, 
>> I appreciate that there is no general SCSI tooling which could help 
>> here. I know that Himanshu M did work on a SCSI version of nvme-cli 
>> tool previously. Martin may know the status of that.
> 
> Agreed that userspace tools are not strictly needed for configuration, but
> observability is key.
> A standard utility to visualize the device topology, path health and ALUA
> states at a glance, similar to what multipath-tools provides, would save a
> lot of friction for sysadmins migrating away from dm-multipath.
> Relying solely on ad-hoc scripts or manual sysfs parsing can become quite
> tedious in production environments.

Right, and any info required here should be available in sysfs.

Thanks,
John