On Mon, 2025-12-01 at 15:59 -0800, Brian Bunker wrote: > Martin, I have added a couple of changes to the patch. Here is the > diff > from the v2 that I posted. I have made the scsi_remove_device a non- > blocking > call. I also release the lock before removing the device decreasing > the > potential for lock contention since what is done under the lock is > minimal.
Let's rather not start with patches to patches ;-) I've looked at your v3; Ben has already provided feedback and I've just added a quick remark. > > I definitely would prefer multipath-tools to be the mechanism for the > purging. > Any other option would be in competetion with multipath-tools in > obtaining > the path state and acting on it. A single point of control seems > advantagous. OK. But as noted in my reply to the v3 patch, I'd like to keep the access to multipathd's internal data structures to a minimum, preferrably zero. I think it's doable. > > There are two issues where multipath-tools is a victim. The first one > is > addressed in the recheck_wwid function. The second one however also > leads > to an unexpected I/O error when running I/O to the multipath device. > There > are issues in volume mobility between two arrays where the inquiry > data changes > and the resurrection of the path with its original inquiry data with > the now > incorrect inquiry data also leads to an I/O error. In this case > multipath-tools > is the victim of the kernel not being able to update inquiry data > with either > inquiry data changed unit attentions or rescans. If you needd more > details > please letme know. > > There may be other reasons to have a purge of disconnected (orphaned > sd > devices) that we have not encountered. Having a way to purge them > seems like > a nice step forward. I am not questioning that. I appreciate your efforts. Regards, Martin
