Re: [PATCH 00/13] scsi: Core ALUA driver

[Benjamin Marzinski <bmarzins@redhat.com>]

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