On Tue, Mar 24, 2026 at 10:57:20AM +0000, John Garry wrote: > On 23/03/2026 19:45, Benjamin Marzinski wrote: > > > > I don't > > > > think the Native SCSI multipath code would need to actively interface > > > > with the device handler code to support IMPLICIT ALUA. IIUC, looking at > > > > sdev->access_state should be enough to pick the correct path. > > > We also have the functionality from alua_check_sense() to consider. > > But the multipath code won't call that directly. Right now, the scsi > > device handler will, at least for every scsi device except ones using > > the Native Multipath code. My point is that this would just work, except > > that the Native Multipath code goes out of its way to break it, by > > disabling device handlers, and I don't really see the point of disabling > > something that every other scsi device, multipathed or not, has enabled. > > It's not like leaving it enabled makes it any harder to move the > > implicit ALUA support from the device handler to the generic scsi code, > > if that's the goal, since the Native Multipath code doesn't care who is > > issuing those rtpgs and updating the state. > > > > I guess this is more of a question for Hannes. Is the goal to turn off > > automatic device handler attachment in general, and go back to making > > dm-multipath attach device handlers to the scsi devices it is using? > > I'm not answering for Hannes, but I don't think that is the goal. > > > If > > not, then I don't see any reason to have the Native Multipath code > > disable it. > > It was just disabled it as we now had another method in the scsi core code > to get ALUA info. > > My plan would be - based on this series - to not attach DH just when using > native SCSI multipath for a device. > > > If it allowed device handlers to get attached, these two > > developement efforts (native scsi multipath and refactoring the alua > > support) could go on in parallel. > > > > Or am I missing something here? > > It just seems to be about this DH stuff is that there is bad history there > and no more users are wanted.
Just to be clear, if the idea was that the Native Multipath code shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But I don't see why it can't make use of the results of the existing implicit ALUA support, since IIUC it doesn't need the scsi_dh interface to do that. That shouldn't interfere with any refactoring that people want to do of how the scsi layer actually handles ALUA support. Again, this is more for Hannes than you, John. -Ben > > But now I am getting bogged down in this ALUA support because of that, which > I feared would happen. > > Thanks, > John
