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

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

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-alua/

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