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

[Benjamin Marzinski]

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. 

-Ben

> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		      zSeries & Storage
> hare at suse.de			      +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
>