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

[Laurence Oberman <loberman@redhat.com>]

On Sun, 2026-11-15 at 18:59 +0000, John Garry wrote:
> On 11/9/26 20:19, Laurence Oberman wrote:
> > 2. ANO paths are ranked the same as AO paths
> > 
> > With the ALUA state corrected (by writing "activate" to dh_state,
> > or
> > with the fix above), I/O still went to active/non-optimized paths.
> > scsi_multipath_sdev_init() sets mpath_device->access_state to
> > MPATH_STATE_OPTIMIZED and nothing updates it, while
> > __mpath_find_path(), mpath_round_robin_path() and
> > mpath_queue_depth_path() rank paths by that field. Only
> > scsi_mpath_is_optimized()/is_disabled() read sdev->access_state.
> > 
> > With numa, the first path in dev_list wins for every node, and
> > dev_list order follows sd probe completion, so for about a third of
> > the LUNs the current path was an ANO path. Example, LUN sdn, reads
> > completed per path for a 2000 x 1M O_DIRECT dd (:0/:3 AO, :1/:2 ANO
> > at the time):
> > 
> >    sdn:0 0sdn:1 2000sdn:2 0sdn:3 0
> > 
> > Every read went through the non-owning controller. From the code,
> > for
> > these LUNs the numa recheck of is_optimized() fails on every I/O
> > and
> > __mpath_find_path() picks the same ANO path again.
> > 
> > With the change below (a template callback so the selectors use the
> > live state), plus the scsi_dh_alua fix, all 30 LUNs pick an AO
> > current path at boot, and on LUN sdl (:0/:2 AO, :1/:3 ANO):
> > 
> >    numa         2000     0     0     0
> >    round-robin  1000     0  1000     0
> >    queue-depth 18039     0 13961     0   (8 parallel dd, 64k)
> > 
> > No I/O reached the ANO paths under any policy. This is a test patch
> > to
> > show the problem, not a polished change - feel free to fold it in
> > or
> > do it differently.
> 
> 
> JFYI, the work which I did for ALUA support a while ago is here:
> #
> https://github.com/johnpgarry/linux/commits/scsi-multipath-v7.3-v7-alu
> a/
> 
> I don't think that I shared this previously.
> 
> I do notice that it would conflict with your work to do some 
> centralising of the ALUA RTPG support.
> 
> About the NUMA iopolicy - apart from issues in this series with not 
> checking optimised/access_state properly - it does seem less than 
> optimal to we only favour one device per NUMA node (when all in same 
> optimized + enabled state). NVMe multipath support does the same. I 
> suppose that this iopolicy relies on us having one device/path per
> NUMA 
> node.
> 
> Thanks,
> John
> 
Hi John,

Thanks for the pointer, I had a look. Keeping mpath_device.access_state
in sync from the RTPG result in scsi_mpath_update_access_state() is a
cleaner way to address the ranking problem I reported, so I'm fine to
go with your approach and drop my test patch.

> I do notice that it would conflict with your work to do some
> centralising of the ALUA RTPG support.

Understood. My scsi_dh_alua patch is only the handler_data ordering
fix in alua_bus_attach(), so I'm happy to rebase or rework it on top of
your core ALUA changes if that helps.

When you have the ALUA support rebased onto v9 or v10, I'm happy to
test it on the P2000 G3 setup (dual controller, 30 LUNs, 4 paths each)
and confirm the AO/ANO path selection.

> About the NUMA iopolicy - apart from issues in this series with not
> checking optimised/access_state properly - it does seem less than
> optimal to we only favour one device per NUMA node (when all in same
> optimized + enabled state). NVMe multipath support does the same. I
> suppose that this iopolicy relies on us having one device/path per
> NUMA node.

Agreed. On FC/iSCSI hosts it's common to have several AO paths per LUN
at the same NUMA distance (all paths here report numa_nodes=0-1), so
round-robin or queue-depth may be the better default for SCSI. Your
call.

Thanks,
Laurence