dm-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: christophe.varoqui@opensvc.com,
	device-mapper development <dm-devel@redhat.com>
Cc: Christophe Varoqui <christophe.varoqui@gmail.com>
Subject: Re: [PATCH][RESEND] multipath: check if a device belongs to multipath
Date: Mon, 20 Aug 2012 14:15:21 +0200	[thread overview]
Message-ID: <50322A59.5080209@suse.de> (raw)
In-Reply-To: <1345234390.12286.9.camel@lapoo.opensvc.com>

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.

> Ben, does this approach supersedes/extends the "complicated blacklisting
> scheme" you proposed earlier ?
> 
I sincerely hope so ...

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)

  reply	other threads:[~2012-08-20 12:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-27 20:55 [PATCH][RESEND] multipath: check if a device belongs to multipath Benjamin Marzinski
2012-08-17 20:13 ` Christophe Varoqui
2012-08-20 12:15   ` Hannes Reinecke [this message]
2012-08-20 17:43     ` Benjamin Marzinski
2012-08-20 17:50       ` Christophe Varoqui
2012-08-20 21:57         ` Benjamin Marzinski
2012-08-21 17:40 ` Christophe Varoqui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50322A59.5080209@suse.de \
    --to=hare@suse.de \
    --cc=christophe.varoqui@gmail.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).