From: Christophe Varoqui <christophe.varoqui@gmail.com>
To: jozef janec <jozefjanec@gmail.com>
Cc: dm-devel@redhat.com
Subject: Re: multipathd daemon and some bad behavior
Date: Sun, 27 Jun 2010 11:17:51 +0200 [thread overview]
Message-ID: <1277630271.20849.787.camel@localhost> (raw)
In-Reply-To: <AANLkTikn_lqBPASgffO0fJUmvdJubbuOLQ9ZCzT_0wBQ@mail.gmail.com>
On sam., 2010-06-26 at 12:13 +0200, jozef janec wrote:
> Hello All,
>
> I'm using device mapper multipath for long time, on SAN storage and I
> have detected a few very critical issues. The main is:
>
> example:
>
> configure 2 multipath devices (and have friednly names enabled)
>
> on those two devices create vg and lvol and ctivate it. Than edit the
> bindigs file and swap the ids for mpath devices.
>
> mpatha id1
> mpathb id2
>
> to
>
> mpatha id2
> mpathb id1
>
> and restart multipathd
>
> when you check output from multipath -ll you will see that multipath
> swapped the devices behinde the used mpath targets. The result is that
> the io operation are directed to wrong lun and the fs is corupted. We
> have found workeround and to define aliases for the luns in
> multipath.conf. Than the bindigs file is ignored .
>
>
> but this is not fix the best solution is if there will be added some
> check if the line in bindings file is correct, or if the mpath target
> is used or not, and if it is used don\t allow change it. IS possible
> create a patch for this?
>
> This issue can be happneded for example when you remove bindings file
> and you restart the multipath.
>
> the problem is that you can add lun to the server, it will get mpatha
> device name, than second but with scsi id lower as the first one but
> because mpatha is already assaigned it will get mpathb. Now when you
> remove the bindigs file and restart multipath, multipath will create
> new bindigs file not by currect situation which is in dm-multipath but
> by scsi ids, and it will swap the luns maps, and activate them .
> result corupted fs.
>
> I think the bext way will be that multipathd should try get the
> information from dm-multipath modul, and if they aren't there than by
> scsi information. This will avoind create wrong bindings file which
> can makes troubles.
>
> I already restored 3 servers because I lost oracle on alot of
> servers.
>
The bindings file is a database, not a config file. That's why it would
best reside in /var than /etc, but the mount ordering problems forced us
to move it to /etc. As a database, you wouldn't ever think sane to
mangle it freely like you do.
user_friendly_names is for people who don't want to name their multipath
devices *at all*. If you want user-defined names, you must use aliasing
in /etc/multipath.conf. If you have a cluster setup, you must user
aliasing to force a consistent device naming across the cluster.
> Please could you check if there is possible cerate some patches for
> multipathd which will avoid this behavior?
>
A documentation patch at least.
> Thanks
>
> best regards
>
> Jozef
--
Christophe Varoqui <christophe.varoqui@opensvc.com>
OpenSVC
parent reply other threads:[~2010-06-27 9:17 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <AANLkTikn_lqBPASgffO0fJUmvdJubbuOLQ9ZCzT_0wBQ@mail.gmail.com>]
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=1277630271.20849.787.camel@localhost \
--to=christophe.varoqui@gmail.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@redhat.com \
--cc=jozefjanec@gmail.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.