From: Martin Wilck <mwilck@suse.com>
To: Julian Andres Klode <julian.klode@canonical.com>
Cc: Guan Junxiong <guanjunxiong@huawei.com>,
development mailing list <dm-devel@redhat.com>,
Device-mapper
Subject: Re: multipath-tools 0.7.4 failure to remove device
Date: Mon, 15 Jan 2018 17:46:24 +0100 [thread overview]
Message-ID: <1516034784.5699.44.camel@suse.com> (raw)
In-Reply-To: <20180115162658.wlccxhlaq56byykg@jak-x230>
On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> > >
> > > It was your commit that made it imply -n that caused the test
> > > failure
> > > :)
> > > I understand your position on that, but reverted it for Ubuntu,
> > > because,
> > > while it might be somewhat broken, it's at least the same level
> > > of
> > > broken
> > > as before.
> >
> > I'd like to understand that better. Why would this break boot?
>
> Ah sorry for the confusion. It did not break boot. Having finding
> disabled would have "broken" boot. The problem I was talking about
> was that with finding enabled, no dm devices were generated, which
> it turned out, was not entirely true - you had to run multipath
> manually (due to your find implies -n commit).
>
> It seems to me that this would cause more issues in practice than
> just keeping the slightly race-y combination enabled. It's something
> to revisit after the ubuntu lts when then people have some time to
> adjust to that change.
I wouldn't call it "slightly race-y". With find_multipaths "on" and
"ignore_wwids" "off", "multipath -u" classifies every device as a
multipath device. So SYSTEMD_READY=0 will be set on each device. But
multipathd, which is responsible for actually setting up the map, will
honor "find_multipaths", and will not set up a map for a device it
finds only a single path for. So the device never appears in a state in
which systemd would be able to use it. Unless you've put in some other
magic, this is almost guaranteed to make your system unbootable in the
quite common case where people using multipath are running off a non-
multipathed local root disk.
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2018-01-15 16:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 8:38 multipath-tools 0.7.4 failure to remove device Julian Andres Klode
2018-01-12 20:35 ` Martin Wilck
2018-01-12 21:47 ` Julian Andres Klode
2018-01-12 22:18 ` Martin Wilck
2018-01-12 22:26 ` Julian Andres Klode
2018-01-15 15:44 ` Julian Andres Klode
2018-01-15 16:12 ` Martin Wilck
2018-01-15 16:26 ` Julian Andres Klode
2018-01-15 16:46 ` Martin Wilck [this message]
2018-01-16 20:30 ` Benjamin Marzinski
2018-01-16 22:05 ` Xose Vazquez Perez
2018-01-17 0:43 ` Martin Wilck
2018-01-17 18:38 ` Benjamin Marzinski
2018-01-18 3:50 ` Benjamin Marzinski
2018-01-18 8:11 ` Martin Wilck
2018-01-18 15:22 ` Benjamin Marzinski
2018-01-18 16:32 ` Martin Wilck
2018-01-17 9:38 ` Julian Andres Klode
2018-01-17 18:45 ` Benjamin Marzinski
2018-01-17 16:27 ` Multipath path classification revisited Martin Wilck
2018-01-18 22:35 ` Benjamin Marzinski
2018-01-13 19:46 ` multipath-tools 0.7.4 failure to remove device Martin Wilck
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=1516034784.5699.44.camel@suse.com \
--to=mwilck@suse.com \
--cc=dm-devel@redhat.com \
--cc=guanjunxiong@huawei.com \
--cc=julian.klode@canonical.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.