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
[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
