On Mon, May 10, 2010 at 06:08:56PM +0200, Guido Günther wrote: > Hi Apollon, > On Mon, May 10, 2010 at 12:57:07PM +0300, Apollon Oikonomopoulos wrote: > > 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. > This is also necessary for the initramfs since we don't run multipathd > there. Testing if multipathd is runnning looks like a good option > though. It'd be even nicer if we could only run that rule if the former > one fails.
Ping? From experience, this is quite a serious issue on large multipath setups, the problem being in a Debian-specific modification that can easily be fixed. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
