How can I prevent my multipath-ed filesystems to enter read-only mode after storage errors?

https://access.redhat.com/solutions/460183

 SOLUTION UNVERIFIED - 已更新 2016年二月18日01:34 - 

English 

环境

• Red Hat Enterprise Linux
• device-mapper-multipath

问题

• I am experiencing storage-side errors which are causing my multipath-ed filesystems to become read-only due to path failure.
• This causes that the filesystem must be unmounted and mounted again in order to recover it's read-write status, once the paths are recovered.
• While fixing these errors, I need to prevent the filesystems from entering read-only mode.

决议

There are three options that can be configured/modified in order to prevent a filesystem from going into read-only mode. These are described in detail in Red Hat's documentation on Multipath's configuration file parameters as follows:

1. features "1 queue_if_no_path"
   If features "1 queue_if_no_path" is specified in the /etc/multipath.conf file, then any process that issues I/O will hang until one or more paths are restored.

   This option must be configured per device type, in the relevant section:

   Raw

   devices {
                   device {
                       [...]
                       features                "1 queue_if_no_path"
                       [...]
           }
   }
   

2. fast_io_fail_tmo
   The number of seconds the SCSI layer will wait after a problem has been detected on an FC remote port before failing I/O to devices on that remote port. This value should be smaller than the value of dev_loss_tmo. Setting this to off will disable the timeout. The default value is determined by the OS.

3. dev_loss_tmo
   The number of seconds the SCSI layer will wait after a problem has been detected on an FC remote port before removing it from the system. Setting this to infinity will set this to 2147483647 seconds, or 68 years. The default value is determined by the OS.

Always remember to restart multipath after performing these changes.

Raw

    [root@host ~]# service multipathd restart

Please be very careful when modifying these parameters. For 1 queue_if_no_path, keep in mind that if the problems with the failing paths persist for more than a couple of minutes, this can cause hung task soft panics and increase your system load. Regarding fast_io_fail_tmo and dev_loss_tmo, these parameters are set by the OS and should not be changed lightly. Modifying these parameters under these situations can lead to filesystem corruption.

Above all, prioritize fixing your storage issues and only resort to these measures if there is no other alternative. If in doubt, do not hesitate to open a support case.

根源

device-mapper-multipath will, as a safety measure, put your filesystems in read-only mode when there is a serious path failure (e.g. all paths to a device down). By design, the filesystem cannot then be remounted with:

Raw

[root@host ~] mount -o rw,remount /filesystem

This is because there might be some corruption present in the filesystem, and generally an fsck is needed after these situations.