Bug#586182: multipath-tools: sometimes fails to create /dev/mapper/mpathN devices

[Ritesh Raj Sarraf]

The maintainer for multipath-tools should be able to give you more information 
but in my experience, the friendly_names feature of multipath-tools have 
turned out to be more of a problem.

I believe there is a bug that talks about a locking issue with friendly_names 
upstream.

In face, I have been recommending against friendly_names (of of the bindings 
file). The plain LUN serial number based access is pretty good and reliable and 
persistent.


Ritesh

On Thursday 17 Jun 2010 12:49:00 Vincent McIntyre wrote:
> Package: multipath-tools
> Version: 0.4.8-14+lenny2
> Severity: normal
> 
> *** Please type your report below this line ***
> 
> Sometimes, multipath-tools does not create all the /dev/mapper/mpathN
> devices one is expecting it to create. This seems to occur if there
> more than two multipathed devices.
> 
> I have a system with a Promise E-Class 610f storage unit and two
> J-Class expansion units, attached in a SAS daisy-chain.
> The E-class is attached to a Dell 2950 server via a Cisco FC switch.
> There are four FC links, two from each controller on the E-Class.
> The FC card is a 4-port LSI/Symbios FC949ES,
> pciid is 1000:0646 with subsystem id 1000:1260.
> 
> Each storage unit is configured as one logical disk, containing 16
> physical disks in a RAID-6 raid set.
> These are presented to the Dell 2950 as 3 distinct LUNs,
> one for each logical disk.
> 
> We started with just the E-Class attached (mpath0).
> Then, with the Dell 2950 shut down we added the J-classes.
> Neither J-class had a partition label or filesystem on them.
> 
> On boot, all three storage units were detected correctly
> (a total of 12 sdX devices because of the multiple paths).
> 
> However only two /dev/mapper/mpathN devices were created:
> # ls -l /dev/mapper
> total 0
> crw-rw---- 1 root root  10, 59 2010-06-17 11:51 control
> brw-rw---- 1 root disk 254, 14 2010-06-17 11:51 install_vg0-data
> brw-rw---- 1 root disk 254, 13 2010-06-17 11:51 install_vg0-local
> brw-rw---- 1 root disk 254, 10 2010-06-17 11:51 install_vg0-opt
> brw-rw---- 1 root disk 254, 12 2010-06-17 11:51 install_vg0-srv
> brw-rw---- 1 root disk 254, 11 2010-06-17 11:51 install_vg0-tmp
> brw-rw---- 1 root disk 254,  8 2010-06-17 11:51 install_vg0-usr
> brw-rw---- 1 root disk 254,  9 2010-06-17 11:51 install_vg0-usr+local
> brw-rw---- 1 root disk 254,  6 2010-06-17 11:51 install_vg0-var
> brw-rw---- 1 root disk 254,  7 2010-06-17 11:51 install_vg0-var+log
> brw-rw---- 1 root disk 254,  5 2010-06-17 11:51 install_vg1-srv+backup
> brw-rw---- 1 root disk 254,  4 2010-06-17 11:51 install_vg1-srv+mysql
> brw-rw---- 1 root disk 254,  0 2010-06-17 11:51 mpath0
> brw-rw---- 1 root disk 254,  2 2010-06-17 11:51 mpath0-part1
> brw-rw---- 1 root disk 254,  1 2010-06-17 11:51 mpath1
> 
> Yet /var/lib/multipath/bindings showed the right WWNs for all three units:
> 
> # cat /var/lib/multipath/bindings
> # Multipath bindings, Version : 1.0
> # NOTE: this file is automatically maintained by the multipath program.
> # You should not need to edit this file in normal circumstances.
> #
> # Format:
> # alias wwid
> #
> mpath0 222810001550c3cb3
> mpath1 2220e0001558b5168
> mpath2 222de000155468f10
> 

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
"Necessity is the mother of invention."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20100617/0835c5eb/attachment.pgp>