> We're currently experiencing problems at boot and got aware of a > race-condition related to LVM over multipath. > > We're on SuSE SLES9 SP3 x86_64, multipath-tools-0.4.5-0.11 > > The SuSE initscript contains 'sleep 1' after running /sbin/multipath in > /etc/init.d/boot.multipath. Our SAN is currently so slow that we had to > increase the sleep to 15 seconds to boot reliably. If the vgscan in > /etc/init.d/boot.lvm starts too quick it would not see the VGs on the > multipath devices. > > Is there a way to wait until all multipath devices are up and ready? > > > The relevant part of SLES9 SP3 /etc/init.d/boot.multipath: > > case "$1" in > start) > echo -n "Creating multipath targets" > # Check whether we should rescan for devices > if grep -q multipath /proc/cmdline && test -d > /sys/class/scsi_host; then > pushd /sys/class/scsi_host 2> /dev/null > for host in *; do > if [ -d $host ]; then > echo "- - -" > $host/scan > fi > done > fi > # Load prerequisite module > modprobe dm-multipath > > # Clear /dev/disk/by-name/ prior to start-up; multipath will > # recreate them. > rm -f /dev/disk/by-name/* 2>&1 >/dev/null > > # Start the program directly as checkproc doesn't work here > $PROGRAM -v 0 > > # Remember status and be verbose > rc_status -v > - sleep 1 > + sleep 15 > ;; The problem with devices not being discovered by vgscan at boot seems to be related to subfs. When subfs is disabled (/etc/sysconfig/hotplug:HOTPLUG_USE_SUBFS=no) the devices get available faster and are seen by the vgscan in boot.lvm. The 1 second delay in the standard SUSE boot.multipath is enough and all volume groups are discovered at boot. -- mike -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
