On 23/03/2026 16:25, Benjamin Marzinski wrote:
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.
I guess it depends on what you mean by using a device handler.
My meaning is anything in drivers/scsi/device_handler
I don't
think the Native SCSI multipath code would need to actively interface
with the device handler code to support IMPLICIT ALUA. IIUC, looking at
sdev->access_state should be enough to pick the correct path.
We also have the functionality from alua_check_sense() to consider.
If that's
right, then it doesn't really matter to the multipath code whether this
is getting updated in scsi_dh_alua.c or scsi_alua.c.
> So refactoring the> scsi ALUA handling code seems orthogonal to the
adding IMPLICIT ALUA
support to the Native scsi multipathing code.
DH support is considered legacy. As I understand, DH was originally
added for early explicit ALUA support and other DH-related standards,
and explicit ALUA is considered flawed. So that is why Martin/Hannes
doesn't want to see more users (for DH). This is my understanding.
Now I a need to try to separate out the ALUA parts we need from
scsi_dh_alua.c into SCSI core code. I'll talk to Martin about this
approach again.
Thanks,
John
