From: Benjamin Marzinski <bmarzins@redhat.com>
To: christophe.varoqui@opensvc.com,
device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH v2] multipath: add find_multipaths feature.
Date: Thu, 1 Sep 2011 09:21:06 -0500 [thread overview]
Message-ID: <20110901142106.GG11793@ether.msp.redhat.com> (raw)
In-Reply-To: <20110901125720.GF11793@ether.msp.redhat.com>
On Thu, Sep 01, 2011 at 07:57:20AM -0500, Benjamin Marzinski wrote:
> On Thu, Sep 01, 2011 at 09:14:23AM +0200, Christophe Varoqui wrote:
> > On mer., 2011-08-31 at 21:55 -0500, Benjamin Marzinski wrote:
> > > This adds a new default feature, find_multipaths. When this is set to yes,
> > > multipath will no longer try to create a multipath device for every
> > > non-blacklisted device. Instead, it will only create a device when one of
> > > three conditions are met.
> > >
> > > 1. Three are at least two non-blacklisted paths with the same wwid
> > > 2. The user manually forces the creation, by specifying a device with the
> > > multipath command.
> > > 3. A path has the same wwid as a multipath device that was previously crreated
> > > (even if that multipath device doesn't currently exist).
> > >
> > Hannes,
> >
> > this patch implements complex semantics and mis-use /etc to store
> > variable data (/run was suggested as a replacement). Though I realize
> > the benefits, I'm not at ease merging it.
>
> This will add wwids to the wwids file at the same times that new bindings
> get added to the bindings file. We decided to move the bindings file to
> /etc/multipath/bindings because it caused problems during bootup, if
> /var/run was not mounted. This will have the same problems where you
> will be writing to a file that eventually gets mounted over. So I am
> against using /var/run
although it looks like the systemd folks have made /run a tmpfs
filesystem, and /var/run a pointer to it (at least in Fedora), so I
guess I'm not opposed to moving things back to /var/run anymore.
-Ben
>
> -Ben
>
> >
> > Mike Snitzer pushed for its inclusion, but I don't remember your
> > commenting. Would your care to ?
> >
> > Regards,
> >
> > --
> > Christophe Varoqui
> > OpenSVC - Tools to scale
> > http://www.opensvc.com/
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2011-09-01 14:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-25 18:57 [PATCH] multipath: add find_multipaths feature Benjamin Marzinski
2011-09-01 2:55 ` [PATCH v2] " Benjamin Marzinski
2011-09-01 7:14 ` Christophe Varoqui
2011-09-01 12:57 ` Benjamin Marzinski
2011-09-01 14:21 ` Benjamin Marzinski [this message]
2011-09-01 20:43 ` Benjamin Marzinski
2011-09-01 14:35 ` Hannes Reinecke
2011-09-01 18:54 ` Benjamin Marzinski
-- strict thread matches above, loose matches on Subject: below --
2011-09-01 14:16 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=20110901142106.GG11793@ether.msp.redhat.com \
--to=bmarzins@redhat.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).