By default, the
multipathd service starts up before the
iscsi service. This provides multipathing support early in the bootup process and is necessary for multipathed iSCSI SAN boot setups. However, once started, the
multipathd service adds paths as informed about them by udev. As soon as the
multipathd service detects a path that belongs to a multipath device, it creates the device. If the first path that multipathd notices is a passive path, it attempts to make that path active. If it later adds a more optimal path,
multipathd activates the more optimal path. In some cases, this can cause a significant overhead during a startup.
If you are experiencing such performance problems, define the
service to start after the
service. This does not apply to systems where the root device is a multipathed iSCSI device, since it the system would become unbootable. To move the service start time run the following commands:
# mv /etc/rc5.d/S06multipathd /etc/rc5.d/S14multipathd
# mv /etc/rc3.d/S06multipathd /etc/rc3.d/S14multipathd
To restore the original start time, run the following command:
# chkconfig multipathd resetpriorities
features "1 queue_if_no_path" is specified in
/etc/multipath.conf then any process that issues I/O will hang until one or more paths are restored.
To avoid this, set
no_path_retry [N] in
[N] is the number of times the system should retry a path). When you do, remove the
features "1 queue_if_no_path" option from
/etc/multipath.conf as well.
If you need to use
"1 queue_if_no_path" and experience the issue noted here, use
dmsetup to edit the policy at runtime for a particular LUN (i.e. for which all the paths are unavailable).
To illustrate: run
dmsetup message [device] 0 "fail_if_no_path"
is the multipath device name (e.g.
; do not specify the path) for which you want to change the policy from
When a LUN is deleted on a configured storage system, the change is not reflected on the host. In such cases,
lvm commands will hang indefinitely when
dm-multipath is used, as the LUN has now become stale.
To work around this, delete all device and
mpath link entries in
/etc/lvm/.cache specific to the stale LUN.
To find out what these entries are, run the following command:
ls -l /dev/mpath | grep [stale LUN]
For example, if
[stale LUN] is 3600d0230003414f30000203a7bc41a00, the following results may appear:
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
This means that 3600d0230003414f30000203a7bc41a00 is mapped to two
As such, the following lines should be deleted from