[dm-devel] [PATCH][RESEND] multipath: check if a device belongs to multipath

[Christophe Varoqui]

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.

cvaroqui,
OpenSVC