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

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

On 24/03/2026 13:58, Benjamin Marzinski wrote:
>>> If it allowed device handlers to get attached, these two
>>> developement efforts (native scsi multipath and refactoring the alua
>>> support) could go on in parallel.
>>>
>>> Or am I missing something here?
>> It just seems to be about this DH stuff is that there is bad history there
>> and no more users are wanted.
> Just to be clear, if the idea was that the Native Multipath code
> shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
> I don't see why it can't make use of the results of the existing
> implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
> to do that.

We would need something like the following to ensure that DH ALUA is 
present to update sdev access_state:

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

  That shouldn't interfere with any refactoring that people
> want to do of how the scsi layer actually handles ALUA support. Again,
> this is more for Hannes than you, John.

Thanks,
John