From: Malahal Naineni <malahal@us.ibm.com>
To: dm-devel@redhat.com
Subject: [BUG] multipath-tools: uuid has become meaningless
Date: Mon, 19 Jul 2010 15:45:28 -0700 [thread overview]
Message-ID: <20100719224528.GA23414@us.ibm.com> (raw)
Hi All,
I have noticed that uuid reported my 'multipath -l' doesn't
really correspond to the paths it loaded. In fact, the machine has two
different storage subsystems, say EMC and IBM, and the 'multipath -l'
output looks like it reported EMC instead of IBM as vendor and vice
versa. Further debugging showed that the system is configured with
'user_friendly_names' in initrd. Initrd actually configures all the
paths correctly using 'user_friendly_names' as intended, but the real
root's multipathd init script's invocation tried to match the names in
/var/lib/multipath/bindings file (this file has grown since the last
mkinitrd!). Instead of just renaming, it actually re-loads with
different paths!
One easy way to reproduce the problem is to run multipath once, edit the
bindings file to swap couple entries (mpatha to mpathb and vice versa)
and then run multipath. The later run of multipath reloads mpatha with
mpathb's paths and vice versa, instead of just renaming. I know renaming
is hard here as they have to be unique when you rename!
Here is the code where the things happen:
libmultipath/configure.c: select_action(): This may reload if it finds
cmpp "by alias" as well as "by wwid".
Technically, this is not wrong! No I/O should be happening in the
original reported case when the device mapper tables are reloaded. It is
just that the uuid's loaded have become meaningless for user!
'multipath -l' has no point in reporting the uuid if it becomes useless!
My thoughts on fixing this:
1. Technically nothing wrong. Live with it and make sure that device
mapper's uuid are meaningless for user and fix 'multipath -l' to
not print uuid's.
2. Don't support user_friendly_names in initrd. Could be just documented
or an option to multipath is added to ignore that feature and that
option is used in initrd calls!
3. We could rename the devices instead of reload -- really fixing this!
Any comments on which way we should go and other possibilities?
Thanks, Malahal.
next reply other threads:[~2010-07-19 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 22:45 Malahal Naineni [this message]
2010-07-20 5:35 ` [BUG] multipath-tools: uuid has become meaningless Christophe Varoqui
2010-07-20 6:54 ` Malahal Naineni
2010-07-20 7:17 ` Hannes Reinecke
2010-07-20 22:06 ` Malahal Naineni
2010-07-21 3:04 ` [BUG] please PLEASE UnSubscribe!!! W S
2010-07-21 10:44 ` [BUG] multipath-tools: uuid has become meaningless Hannes Reinecke
2010-08-16 22:56 ` Malahal Naineni
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=20100719224528.GA23414@us.ibm.com \
--to=malahal@us.ibm.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 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.