2.6. device-mapper-multipath

Note that under certain circumstances, the multipathd daemon can terminate unexpectedly during shutdown.

It is possible to overwrite the default hardware table. However, regular expression matches are not allowed; the vendor and product strings need to be matched exactly. These strings can be found by running the following command:

~]# multipathd -k"show config"

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 multipathd service to start after the iscsi 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

(BZ#500998)

Running the multipath command with the -ll option can cause the command to hang if one of the paths is on a blocking device. Note that the driver does not fail a request after some time if the device does not respond.

This is caused by the cleanup code, which waits until the path checker request either completes or fails. To display the current multipath state without hanging the command, use multipath -l instead. (BZ#214838)