On Mon, Mar 23, 2026 at 09:57:15AM +0000, John Garry wrote: > 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.
I guess it depends on what you mean by using a 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. 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. -Ben > > 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
