Package: multipath-tools Version: 0.4.8-14+lenny2 Severity: normal Hi,
/etc/udev/rules.d/z60_multipath.rules, as shipped with all debian packages up to sid's version, contains the following rules: RUN+="socket:/org/kernel/dm/multipath_event" ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/$name" Multipathd itself has uevent support, which is what the first rule is used for. However, the second rule is redundant and useful only in the case of block devices showing up during boot, between /etc/init.d/multipath-tools-boot and /etc/init.d/multipath-tools. Furthermore, it causes major system load whenever a bulk of new LUNs are added to a running system. In our case, adding 10 LUNs with 8 paths each causes the system load to rocket to 70-80 for 25s, while 80 multipath processes are racing to coallesce the multipaths. Disabling the second rule causes the whole process to finish in less than 2 seconds while multipathd itself handles the uevents generated by the kernel. It should be noted that upstream do not include the second rule in their sample rulefile[1]. Thus, the second rule should be removed or at least check whether multipathd is running before executing /sbin/multipath. One final note: multipathd uevent handling is broken with kernel 2.6.32, fixed in a backwards compatible way upstream with commit 7fa7affc3d23dd9dc906804d22a61144bca9f9b9 (already present in squeeze/sid). I know this is more of a wishlist item, but please backport the fix if possible to make lenny's multipathd usable with newer kernels. Thank you -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (80, 'testing'), (70, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org