On Thu, 2026-03-12 at 08:10 +0100, Hannes Reinecke wrote: > > > > 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. >
I wonder if we could avoid this problem by listening to SDEV_EVT_ALUA_STATE_CHANGE_REPORTED uevents in multipathd. Actually, multipathd could use TUR for checking unless we receive an event of this type. multipathd could listen to those events and then retrieve the new device state(s) from sysfs, without sending an RTPG command itself. We wouldn't switch to the alua checker by default anyway, so the vendors that prefer the sysfs prioritizer won't be hurt even if that doesn't work. > 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? When you say "generic code", I suppose you are talking about the SCSI midlayer. It isn't clear to me how multipathd would benefit from handling ALUA there, other than being able to read state from sysfs, as it already does. Regards Martin > 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
