[dm-devel] multipath-tools: race-condition with boot.multipath and boot.lvm

[Michael Steinmann]

> 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