On 23/03/2026 19:45, Benjamin Marzinski wrote:
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.
But the multipath code won't call that directly. Right now, the scsi
device handler will, at least for every scsi device except ones using
the Native Multipath code. My point is that this would just work, except
that the Native Multipath code goes out of its way to break it, by
disabling device handlers, and I don't really see the point of disabling
something that every other scsi device, multipathed or not, has enabled.
It's not like leaving it enabled makes it any harder to move the
implicit ALUA support from the device handler to the generic scsi code,
if that's the goal, since the Native Multipath code doesn't care who is
issuing those rtpgs and updating the state.
I guess this is more of a question for Hannes. Is the goal to turn off
automatic device handler attachment in general, and go back to making
dm-multipath attach device handlers to the scsi devices it is using?
I'm not answering for Hannes, but I don't think that is the goal.
If
not, then I don't see any reason to have the Native Multipath code
disable it.
It was just disabled it as we now had another method in the scsi core
code to get ALUA info.
My plan would be - based on this series - to not attach DH just when
using native SCSI multipath for a device.
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.
But now I am getting bogged down in this ALUA support because of that,
which I feared would happen.
Thanks,
John
