On 22/03/2026 17:37, Benjamin Marzinski wrote:
I think that this work is a real regression possibility for
dm-multipath, so we need to be careful.
At the risk of showing just how limited my SCSI knowledge is, I need to
ask, Is any of this actually necessary to get native scsi multipath
working with Implicit ALUA?
If the goal is to limit this to IMPLICT ALUA only, I was expecting that
you could just leave the scsi_dh_alua code completely alone. If native
scsi multipathing didn't disable the device handler, it seemed that this
would basically just work. With the device handler attached,
We only get the scsi_dh_activate() -> alua_activate() call from
dm-mpath.c, and that callchain could not happen for native SCSI
multipath. But, yes, we do the alua_rtpg_queue() call from a rescan, but
we should be checking if the path is available first (and not rely on a
rescan).
when the
array updates the ALUA state, that should, at least I believe, trigger a
unit attention that will fire off a RTPG command. That should update the
sdev->access_state, which the multipath code could use to pick the
correct path. Right? What am I missing here?
Is this just a parallel
exercise to overhaul the ALUA code?
The SCSI community would rather not see more usage for device handlers.
How we then get ALUA support for native SCSI multipath is the question.
My original series just really duplicated the scsi_dh_alua.c RTPG
support for native SCSI multipath into a limited "core" driver. Hannes
thinks that a core ALUA driver to also support DH would be better
(IIUC), which I am attempting in this series. I will re-iterate that I
would rather not touch scsi_dh_alua.c, unless the changes are simple and
obvious(ly correct).
Thanks,
John
