On 03/03/2026 08:01, Hannes Reinecke wrote:
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.
I want to mention the problems of trying to not use device handler-based
code from scsi_dh_alua.c . I would like to have core ALUA code for both
scsi_dh_alua.c and native scsi multipath, but it's easier said than done
to achieve.
I can easily extract the protocol-specific helper code, like alua_tur(),
alua_check_tpgs(), and submit_rtpg().
But what about the port group management code, like in alua_rtpg() and
alua_rtpg_work()? As far as I am concerned, we need that for native SCSI
multipath support. All the port group management is intertwined with the
DH stuff. Even stuff alua_port_group has DH stuff, like dh_list and
rtpg_list members. And we also can't easily take code only relevant to
implicit ALUA, either. Any suggestions?
