[PATCH 02/24] scsi-multipath: introduce basic SCSI device support

[Hannes Reinecke]

On 3/3/26 06:39, Benjamin Marzinski wrote:
> On Mon, Mar 02, 2026 at 11:39:28AM +0000, John Garry wrote:
>> On 02/03/2026 02:22, Benjamin Marzinski wrote:
>>>> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>>>> index 19d0884479a24..cfab7ad1e3c2c 100644
>>>> --- a/drivers/scsi/Kconfig
>>>> +++ b/drivers/scsi/Kconfig
>>>> @@ -76,6 +76,16 @@ config SCSI_LIB_KUNIT_TEST
>>>>    	  If unsure say N.
>>>> +config SCSI_MULTIPATH
>>>> +	bool "SCSI multipath support"
>>> At least until this supports ALUA, it should probably be marked
>>> EXPERIMENTAL, just so people trying it out aren't surprised if it
>>> doesn't multipath their device in the way they expect.
>>
>> I think that ALUA support will be mainline acceptance criteria, and I am
>> looking to add it now.
>>
>> BTW, Hannes suggested to not use the DH ALUA support, so that means to
>> separate out the core ALUA support from the DH stuff. So you have any
>> opinion on that approach?
> 
> I would (perhaps naively) have thought that the device handlers would be
> a useful abstraction for dealing with ALUA devices. But, Hannes knows
> this code much better than me. like I said before, I'm no scsi expert.
> 
The main point of the device handlers was to inject a 'start' command
whenever paths needed to be switched (Like you need to do for some
active/passive arrays).
But that really caused quite some issues with complexity, as you easily
can get into array path ping-pong on path failure with no I/O being 
transmitted.

So for this implementation I would stick with implicit ALUA
(most modern implementations have done so already anyway), and
then there's no need using the device handlers.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +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