multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
multipath-tools (Ubuntu) |
New
|
High
|
Unassigned |
Bug Description
My device section of /etc/multipath.conf contains the following (I'll attach the complete file in a bit):
fast_io_fail_tmo 3
dev_loss_tmo 2147483647
This is also visible in the output from multipathd -k"show config", so it's being correctly parsed. However, the settings appears to be completely ignored by multipathd, as the corresponding sysfs settings doesn't get updated:
$ grep . /sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
These are the kernel's defaults. I can easily set them manually:
$ echo 3 | tee /sys/class/
3
$ echo 2147483647 | tee /sys/class/
2147483647
$ grep . /sys/class/
/sys/class/
/sys/class/
/sys/class/
/sys/class/
However, this won't survive a reboot, and since SAN paths may appear at any time, adding the above to /etc/rc.local is also not a good way to fix it.
I've also attempted to move the settings to the defaults section and the individual path sections. No change in behaviour.
This bug prevents dm-multipath from quickly moving I/O away from a recently failed SAN path, instead stalling all I/O for 30 seconds. This defeats the purpose of using multipathing in the first place, which is to have highly available I/O access so that production can continue uninterrupted even if parts of the SAN fabric fails.
The setting works on RHEL6, btw.
Thanks for reporting this bug.
You say that multipathd -k"show config" shows the changes you want, could you please show the full output of it? In addition to the output of 'multipath -v4' ?