On Mon, Mar 23, 2026 at 06:04:54PM +0000, John Garry wrote: > 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.
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? If not, then I don't see any reason to have the Native Multipath code disable it. 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? -Ben > > > 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
