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

[Hannes Reinecke <hare@suse.com>]

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
hare@suse.com                               +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