On 3/24/26 16:12, John Garry wrote:
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.
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.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
