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.

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?

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

Reply via email to