Re: [PATCH 00/13] scsi: Core ALUA driver

[John Garry <john.g.garry@oracle.com>]

On 26/03/2026 10:19, Hannes Reinecke wrote:
>> @@ -80,6 +80,7 @@ config SCSI_MULTIPATH
>>          bool "SCSI multipath support"
>>          depends on SCSI_MOD
>>          select LIBMULTIPATH
>> +       select SCSI_DH_ALUA
>>          help
>>            This option enables support for native SCSI multipath 
>> support for
>>            SCSI host.
>>
>> And that is even enough, as Kconfigs should only specify build 
>> requirements.
>>
>> We really should be also calling something like scsi_dh_attach() for 
>> scsi multipath to ensure that DH is attached (and running to update 
>> sdev->access_state).
>>
>> And I am not sure how the dh alua module is even autoloaded. I think 
>> that on my ubuntu machine the multipath-tools.service does it - 
>> something like this would not be nice for native SCSI multipath support.
>>
> Gnaa. But then we don't need this patchset at all.
> Main point was that we _do not_ need to hook into scsi dh for implicit
> ALUA.

But again I don't think that this is good enough. Native SCSI 
multipathing will read sdev->access_state to know ALUA state. We can't 
just rely on dh alua module running and doing what we need to know that 
this value is valid. AFAICS, dm mpath relies on dh alua module to even 
work at all:

device-mapper: table: 252:1: multipath: error attaching hardware
handler (-EINVAL)

At this point I am more inclined to just have a small SCSI core ALUA 
support for implicit ALUA, and allow scsi_dh_alua.c reuse functions from 
that but not use sdev->alua structure, like in this series - trying that 
is turning into a mess, I am finding.

Thanks,
John