FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 08-20-2012, 05:43 PM
Benjamin Marzinski
 
Default multipath: check if a device belongs to multipath

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@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)
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-20-2012, 09:57 PM
Benjamin Marzinski
 
Default multipath: check if a device belongs to multipath

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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 10:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org