On 24/03/2026 15:48, Benjamin Marzinski wrote:
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.
DM_MULTIPATH doesn't force the device handlers to be built. You just
don't have their support if they aren't there. Granted, it does make
sure that if they are built, you can't build dm-multipath directly into
the kernel, if the device handlers are built as modules.
Note that dm-mpath does not even work without DH ALUA module:
device-mapper: table: 252:1: multipath: error attaching hardware
handler (-EINVAL)
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).
That isn't necessary. If there is an alua device handler, kernel will
auto-attach it to any device that supports alua (see scsi_dh_add_device
and scsi_dh_find_driver). DM-multipath's calling of scsi_dh_attach() is
mostly a historical relic.
We still need to know that DH is attached to know that whatever is in
sdev->access_state is valid for scsi multipath.
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.
Fair point. Depending on how the kernel is built, there could be system
configuration work that needs to happen if implicit alua support
wasn't in the generic scsi code. But as far as the kernel code goes, I
still see them as parallel efforts.
I see what you are saying, I'll defer to Martin/Hannes on this.
Thanks,
John
