On Thu, Mar 12, 2026 at 12:10 AM Hannes Reinecke <[email protected]> wrote: > > On 3/12/26 01:16, Brian Bunker wrote: > > For ALUA-capable storage arrays, multipath-tools currently uses TUR > > (Test Unit Ready) as the default path checker while a separate > > prioritizer determines ALUA state. When sysfs provides ALUA state > > (the common case), no RTPG command is needed for priority. However, > > if sysfs is unavailable or detect_prio is off, the prioritizer issues > > RTPG, resulting in two SCSI commands per path check cycle: TUR + RTPG. > > > > This patch introduces an 'alua' path checker that uses RTPG as the path > > check command, providing two benefits: > > > > 1. For configurations where RTPG is needed for priority, this eliminates > > duplicate I/O by combining path checking and ALUA state retrieval > > into a single RTPG command. > > > > 2. RTPG provides richer path state information than TUR: > > * TRANSITIONING state detected and mapped to PATH_PENDING, > > preventing false all paths down during controller failover > > * STANDBY state detected and mapped to PATH_GHOST > > * UNAVAILABLE/OFFLINE states properly distinguished > > > > The richer state information is valuable even when sysfs is available, > > as TUR cannot distinguish between these ALUA-specific conditions. > > > > This design intentionally couples the checker and prioritizer: the > > alua_cached prioritizer consumes state cached by the alua checker. > > While this blurs the traditional separation between these components, > > for ALUA the path state and priority fundamentally derive from the > > same underlying data, making the coupling a natural fit. > > > > This patch sets the alua checker as the auto-detected default for ALUA > > devices to demonstrate its benefits. We recognize that adopting a new > > default checker requires careful consideration; the auto-detection can > > be adjusted or removed based on review feedback. > > > > Brian Bunker (1): > > checkers: add alua path checker > > > > libmultipath/Makefile | 5 + > > libmultipath/checkers.c | 1 + > > libmultipath/checkers.h | 1 + > > libmultipath/checkers/Makefile | 3 +- > > libmultipath/checkers/alua.c | 426 ++++++++++++++++++++++++ > > libmultipath/checkers/alua.h | 15 + > > libmultipath/prio.c | 1 + > > libmultipath/prio.h | 1 + > > libmultipath/prioritizers/Makefile | 1 + > > libmultipath/prioritizers/alua_cached.c | 225 +++++++++++++ > > libmultipath/prioritizers/alua_rtpg.c | 12 +- > > libmultipath/prioritizers/alua_rtpg.h | 1 + > > libmultipath/prioritizers/sysfs.c | 7 +- > > libmultipath/propsel.c | 25 +- > > libmultipath/structs.c | 2 + > > libmultipath/structs.h | 3 + > > 16 files changed, 721 insertions(+), 8 deletions(-) > > create mode 100644 libmultipath/checkers/alua.c > > create mode 100644 libmultipath/checkers/alua.h > > create mode 100644 libmultipath/prioritizers/alua_cached.c > > > > Hmm. Some array vendor have been less than happy when I > tried a similar thing during development of the ALUA > device handler. > Problem is that RTPG requires a cluster callout on the > array side, as it needs to contain information about > the _entire_ target system. Which, for distributed systems, > is a costly operation. So using this as a path > checker is not making certain array vendors happy. >From working on one of these arrays, many of the path state decisions often require the same set of information to respond correctly to test unit ready. Other OS's including both Windows and ESX, once they determine that the array supports ALUA, use RTPG rather than TUR as the periodic path checker. > > However: as you might have followed the discussion > about scsi multipathing, maybe we can turn this around > to profit both sides: > Can't we move ALUA state handling into the generic > code, leaving the device handler only to deal with > explicit ALUA? > That way we can intercept sense codes and send RTPG > only when required, such that the ALUA state of > the scsi device is correct. > And the the ALUA path checker just has to evaluate > the information in sysfs. > _And_ scsi multipathing can use that information, too. > > Hmm? I think that there are likely ways to re-imagine the checker and prioritizer separation that would have benefit. This patch wasn't really about going in "as is" but to start that sort of thought.
In general multipath-tools is "good enough" to support the ALUA story from my perspective as a target vendor. There are some improvements that would likely simplify things. The Linux kernel, in my view, should take these two changes to complete its ALUA story: https://marc.info/?l=linux-scsi&m=177189801604075&w=2 https://marc.info/?l=linux-scsi&m=176530648031820&w=2 It would be great if someone could review those two changes. > > 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 Thanks, Brian -- Brian Bunker PURE Storage, Inc. [email protected]
