hi Sean,
in the case stated, the host was not rebooted during this test. what has
changed is LUNs exposure to the host (unmapping and re-mapping of LUNs,
deleting and re-creating of LUNs).
could these kind of operations trigger similar issues?
from what we saw, multipathd's state made it think that some paths, that
have different WWIDs, should be bound to the same multipath device
(which is incorrect).
a different question comes to mind:
if we avoid using the friendly names, and instead use the
/dev/mapper/<wwid> device paths - is this likely to avoid the problem in
the first place?
--guy
On 03/28/2015 02:26 AM, Stewart, Sean wrote:
Hi Ilan,
I believe this is solved by the following patch:
http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=5adec73edcdee912821ca8378439dc105e82c60f
Per the patch description:
When a system is booted to the SAN, a condition can occur where one
user friendly name is given to a disk during boot, but multipathd tries
to allocate a different one after boot. If the second alias is already
used by another device, multipathd can't rename it. Multipathd then has
incorrect information about the alias/wwid relationships, which can
result in paths being added to the wrong map.
On Thu, 2015-03-19 at 10:35 +0000, Ilan Steinberg wrote:
multipathd> show maps
name sysfs uuid
mpathiw dm-13 20024f400d5190010
This shows the current running configuration, that multipathd is
operating believing that mpathiw should have be 20024f400d5190010.
This might be useful info - in the bindings file I see:
...
mpathiv 20024f400d5190010
<---------------------------------------- this is the scsi_sn of sdag
mpathiw 20024f400d5190026
<---------------------------------------- this is the scsi_sn of sdz/w
...
So what must have happened was that the bindings file was out of sync on
the initramfs and the local fs (which you can check by unwrapping the
initramfs and comparing the wwids in each file), and it created the
device with one name, tried to rename it, couldn't, and multipathd then
starts adding into the wrong map. It's hard to explain clearly. :) If
we could see what both bindings files say, maybe I could explain it
better.
To work around it, remaking the initramfs to sync the bindings should
suffice, or you could define aliases via the multipath sections
multipath.conf.
Hope this helps.
Thanks,
Sean Stewart
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
