On Wed, Jan 13, 2016 at 10:10:43AM +0100, Hannes Reinecke wrote: > Hi all, > > I'd like to attend LSF/MM and would like to present my ideas for a multipath > redesign. > > The overall idea is to break up the centralized multipath handling in > device-mapper (and multipath-tools) and delegate to the appropriate > sub-systems. > > Individually the plan is: > a) use the 'wwid' sysfs attribute to detect multipath devices; > this removes the need of the current 'path_id' functionality > in multipath-tools If all the devices that we support advertise their WWID through sysfs, I'm all for this. Not needing to worry about callouts or udev sounds great. > b) leverage topology information from scsi_dh_alua (which we will > have once my ALUA handler update is in) to detect the multipath > topology. This removes the need of a 'prio' infrastructure > in multipath-tools What about devices that don't use alua? Or users who want to be able to pick a specific path to prefer? While I definitely prefer simple, we can't drop real funtionality to get there. Have you posted your scsi_dh_alua update somewhere? I've recently had requests from users to 1. make a path with the TPGS pref bit set be in its own path group with the highest priority 2. make the weighted prioritizer use persistent information to make its choice, so its actually useful. This is to deal with the need to prefer a specific path in a non-alua setup. Some of the complexity with priorities is there out of necessity. > c) implement block or scsi events whenever a remote port becomes > unavailable. This removes the need of the 'path_checker' > functionality in multipath-tools. I'm not convinced that we will be able to find out when paths come back online in all cases without some sort of actual polling. Again, I'd love this to be simpler, but asking all the types of storage we plan to support to notify us when they are up and down may not be realistic. > d) leverage these events to handle path-up/path-down events > in-kernel If polling is necessary, I'd rather it be done in userspace. Personally, I think the checker code is probably the least obectionable part of the multipath-tools (It's getting all the device information to set up the devices in the first place and coordinating with uevents that's really ugly, IMHO). -Ben -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
