On 3/24/26 14:58, Benjamin Marzinski wrote:
On Tue, Mar 24, 2026 at 10:57:20AM +0000, John Garry wrote:
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.
Just to be clear, if the idea was that the Native Multipath code
shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But
I don't see why it can't make use of the results of the existing
implicit ALUA support, since IIUC it doesn't need the scsi_dh interface
to do that. That shouldn't interfere with any refactoring that people
want to do of how the scsi layer actually handles ALUA support. Again,
this is more for Hannes than you, John.
Oh, it's not that it technically cannot use it.
It's just a design thingie: my idea for the native SCSI multipathing
is that it should be _simple_. There really is not point (and, in fact,
was one of the main motivators of this idea) to re-implement every nook
and crannie from dm-multipathing.
SCSI multipathing should only handle implicit ALUA, and leave every
other functionality to dm-multipathing.
And on the other side, I always found it completely irritating that
one had to enable multipathing in order to get ALUA support (ie
being able to figure out the ALUA state). The ALUA state is a property
of the LUN, and the system has to react on that one. It really doesn't
matter whether the system has multipathing enabled; if the LUN is in
ALUA Standby state we cannot send I/O, full stop.
And that's what we're trying to achieve here; move implicit alua support
from SCSI DH into the SCSI core, and leave SCSI DH to handle explicit
ALUA support.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
