On Mon, Aug 20, 2012 at 07:50:31PM +0200, Christophe Varoqui wrote: > On lun., 2012-08-20 at 12:43 -0500, Benjamin Marzinski wrote: > > On Mon, Aug 20, 2012 at 02:15:21PM +0200, Hannes Reinecke wrote: > > > On 08/17/2012 10:13 PM, Christophe Varoqui wrote: > > > > On ven., 2012-07-27 at 15:55 -0500, Benjamin Marzinski wrote: > > > >> This patch adds a new multipath option "-c", which checks if a device > > > >> belongs to multipath. This can be done during the add uevent for the > > > >> device, before the multipath device has even been created. This allows > > > >> udev to be able to handle multipath path devices differently. To do > > > >> this multipath now keeps track of the wwids of all previously created > > > >> multipath devices in /etc/multipath/wwids. The file creating and > > > >> editting code from alias.[ch] has been split out into file.[ch]. When a > > > >> device is checked to see if it's a multipath path, it's wwid is > > > >> compared against the ones in the wwids file. Also, since the > > > >> uid_attribute may not have been added to the udev database entry for > > > >> the device if this is called in a udev rule, when using the "-c" option, > > > >> get_uid will now also check the process' envirionment variables for the > > > >> uid_attribute. > > > >> > > > > I'd like other distribution maintainers' comments on this one, as it > > > > impacts the multipath-tools intregration with udev. > > > > > > > > Hannes ? Did you face the same issue with SuSE ? Did you solve it > > > > differently ? > > > > > > > No; currently I didn't solve it at all, what with me being tied up > > > with customer issues :-( > > > > > > But this is basically the approach I've discussed with Harald Hoyer > > > and Kay Sievers on how we should facilitate proper systemd integration. > > > > > > The idea here is to have a udev rule calling 'multipath -c' via > > > PROGRAM, so that udev can detect if a device should've been handled > > > via multipath. > > > Which would allow any rules following that one to evaluate this > > > status and possibly skip the device. > > > > > > So from that perspective the patch should be okay. > > > > > > However, the one thing to note is this patch _again_ is using > > > hard-coded filenames under /etc, which really shouldn't happen. > > > We should be introducing a configuration file variable to set it. > > > > I'll post a patch that adds a configuration parameter soon. > > > > > > > > > Ben, does this approach supersedes/extends the "complicated blacklisting > > > > scheme" you proposed earlier ? > > > > > > > I sincerely hope so ... > > > > actually, this is patch is what I though were the non-objectional parts > > to that patch. I still think it's useful to be able to setup multipath > > so that instead of defaulting to use all the non-blacklisted LUNs, it > > just defaults to using the LUNs which actually have multiple paths. That > > patch didn't effect how the blacklisting code worked. Nor did it keep you > > from setting up multipath on single pathed LUNs. It just didn't default > > to setting up multipath devices on single pathed LUNs, if you had never > > set up a multipath device on that LUN before. > > > Ok fine. Do you prefer I merge the already submitted patch so that you > can submit an incremental patch for the cache file location or I wait > for your submitting a feature-complete patch ? > > Thanks for the clarification. The existing patch could have stood to be broken up in the interest of easy reading. I don't want to make it any larger. I'll just send a second patch that adds the multipath.conf option. Thanks. -Ben > > cvaroqui, > OpenSVC -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
