How to set dev_loss_tmo and fast_io_fail_tmo persistently, using a udev rule

最新推荐文章于 2025-05-26 09:56:22 发布

msdnchina

最新推荐文章于 2025-05-26 09:56:22 发布

阅读量1.2k

点赞数

文章标签： dev_loss_tmo fast_io_fail_tmo udev

RHEL7 同时被 2 个专栏收录

432 篇文章

订阅专栏

RHEL6

117 篇文章

订阅专栏

博客围绕Red Hat Enterprise Linux 6和7系统展开，指出需设置特定超时参数且重启后仍生效。介绍了这些参数是传输层超时，与远程端口结构相关。通过选取相关rport获取udev信息，构建udev规则来设置参数，还给出不同示例及应用规则的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

SOLUTION UNVERIFIED - 已更新 2018年五月10日22:39 -

English

环境

Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7

问题

Need to set fast_io_fail_tmo and dev_loss_tmo
Setting must persist across reboot

决议

Both the fast_io_fail_tmo and dev_loss_tmo are transport layer timeouts, meaning that they are defined as working with the remote port structure of the fabric, associated with class fc_remote_ports. Since they work in regards to the state of the remote port, to pull the needed udev database information, we must target a rport.
Taking a look at one of our devices, we see it is a dm-multipath device named /dev/mapper/test_lun. There are 8 paths presented through hosts 2, 3, 4, and 5. Duplicate backend ports are provided through target port 0 and 1 ending at lun 0.

Raw

test_lun (wwid_omitted) dm-4 NETAPP,LUN
size=30G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='queue-length 0' prio=50 status=active
| |- 2:0:0:0  sde  8:64   active ready running
| |- 3:0:1:0  sdn  8:208  active ready running
| |- 4:0:0:0  sdq  65:0   active ready running
| `- 5:0:0:0  sdw  65:96  active ready running
`-+- policy='queue-length 0' prio=10 status=enabled
  |- 2:0:1:0  sdh  8:112  active ready running
  |- 3:0:0:0  sdm  8:192  active ready running
  |- 4:0:1:0  sdt  65:48  active ready running
  `- 5:0:1:0  sdad 65:208 active ready running

To start, pick one or more of the relevant rports and pull the udev information using the udevadm info command. We've chosen two from host2, rport-2:0-0 and rport-2:0-1.

Raw

[root@host ~]# ls /sys/class/fc_remote_ports/
rport-2:0-0  rport-2:0-2  rport-3:0-1  rport-4:0-0  rport-4:0-2  rport-4:0-5  rport-5:0-1  rport-5:0-3
rport-2:0-1  rport-3:0-0  rport-3:0-2  rport-4:0-1  rport-4:0-3  rport-5:0-0  rport-5:0-2  rport-5:0-4

[root@host ~]# udevadm info --attribute-walk --path=/sys/class/fc_remote_ports/rport-2\:0-0/

  looking at device '/devices/pci0000:00/0000:00:09.0/0000:04:00.0/host2/rport-2:0-0/fc_remote_ports/rport-2:0-0':
    KERNEL=="rport-2:0-0"
    SUBSYSTEM=="fc_remote_ports"
    DRIVER==""
    ATTR{supported_classes}=="Class 3"
    ATTR{dev_loss_tmo}=="30"
    ATTR{node_name}=="0x500a09808607eec3"
    ATTR{port_name}=="0x500a09819607eec3"
    ATTR{port_id}=="0x610400"
    ATTR{roles}=="FCP Target"
    ATTR{port_state}=="Online"
    ATTR{scsi_target_id}=="0"
    ATTR{fast_io_fail_tmo}=="5"

  looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:04:00.0/host2/rport-2:0-0':
    KERNELS=="rport-2:0-0"
    SUBSYSTEMS==""
    DRIVERS==""
[ ... snip ... ]

[root@host ~]# udevadm info --attribute-walk --path=/sys/class/fc_remote_ports/rport-2\:0-1/

  looking at device '/devices/pci0000:00/0000:00:09.0/0000:04:00.0/host2/rport-2:0-1/fc_remote_ports/rport-2:0-1':
    KERNEL=="rport-2:0-1"
    SUBSYSTEM=="fc_remote_ports"
    DRIVER==""
    ATTR{supported_classes}=="Class 3"
    ATTR{dev_loss_tmo}=="2147483647"
    ATTR{node_name}=="0x500a09808607eec3"
    ATTR{port_name}=="0x500a09828607eec3"
    ATTR{port_id}=="0x610500"
    ATTR{roles}=="FCP Target"
    ATTR{port_state}=="Online"
    ATTR{scsi_target_id}=="1"
    ATTR{fast_io_fail_tmo}=="5"

  looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:04:00.0/host2/rport-2:0-0':
    KERNELS=="rport-2:0-1"
    SUBSYSTEMS==""
    DRIVERS==""
[ ... snip ... ]

From this information we can build a udev rule to set both dev_loss_tmo and fast_io_fail_tmo. In this example, we'll target all of our hosts, and every viable rport behind the hosts, and set each to a dev_loss_tmo of 10 and a fast_io_fail_tmo of 5. We match all viable rports by matching the role "FCP Target". Create /etc/udev/rules.d/99-tmo.rules and include the below contents.

Raw

ACTION!="add|change", GOTO="tmo_end"
KERNELS=="rport-?*", SUBSYSTEM=="fc_remote_ports",  ATTR{roles}=="FCP Target", ATTR{dev_loss_tmo}="10", ATTR{fast_io_fail_tmo}="5"
LABEL="tmo_end"

In the second example, we'll target individual rports, using the "node_name" and the "port_name" of the rport.

Raw

ACTION!="add|change", GOTO="tmo_end"
KERNELS=="rport-?*", SUBSYSTEM=="fc_remote_ports", ATTR{node_name}=="0x500a09808607eec3", ATTR{port_name}=="0x500a09819607eec3", ATTR{dev_loss_tmo}="10", ATTR{fast_io_fail_tmo}="5"
KERNELS=="rport-?*", SUBSYSTEM=="fc_remote_ports", ATTR{node_name}=="0x500a09808607eec3", ATTR{port_name}=="0x500a09828607eec3", ATTR{dev_loss_tmo}="10", ATTR{fast_io_fail_tmo}="5"
LABEL="tmo_end"

To apply, reload the rules and database:

Raw

#RHEL6
[root@host]# udevadm control --reload-rules
#RHEL7
[root@host]# udevadm control --reload

Then trigger against the appropriate subsystem:

Raw

[root@host ~]# udevadm trigger --subsystem-match=fc_remote_ports

Note: When setting eh_deadline and eh_timeout How to set eh_deadline and eh_timeout persistently, using a udev rule can be used, and if setting dev_loss_tmo on a Cisco UCS system using the fnic driver, Does the fnic driver have a "dev_loss_tmo" setting? can be used.