Show Table of Contents
4.3. 配置文件默认设置
/etc/multipath.conf 配置文件包括 defaults 部分，在该部分中将 user_friendly_names 参数设为 yes，如下。
defaults {
user_friendly_names yes
}
这可覆盖
user_friendly_names 参数的默认值。
该配置文件包括配置默认模板。这部分要被注释出来，如下。
#defaults {
# polling_interval 10
# path_selector "round-robin 0"
# path_grouping_policy multibus
# uid_attribute ID_SERIAL
# prio alua
# path_checker readsector0
# rr_min_io 100
# max_fds 8192
# rr_weight priorities
# failback immediate
# no_path_retry fail
# user_friendly_names yes
#}
要覆盖任意配置参数的默认值，您可将这个模板中相关的行复制到
defaults 部分并取消其注释。例如：要覆盖 path_grouping_policy 参数以便用 multibus 覆盖默认的 failover，请将模板中正确的行复制到配置文件的 defaults 部分并取消对它的注释，如下。
defaults {
user_friendly_names yes
path_grouping_policy multibus
}
表 4.1 “多路径配置默认设置” 描述了
multipath.conf 配置文件的 defaults 部分中设置的属性。DM Multipath 会使用这些值，除非该属性被 multipath.conf 文件的 devices 和 multipaths 部分所指定的属性覆盖。
表 4.1. 多路径配置默认设置
| 属性 | 描述 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
polling_interval | 以秒为单位指定两次路径检查之间的间隔。对正常工作的路径，两次检查间的间隔会逐渐增加到 polling_interval 的四倍。默认值为 5。 | |||||||||
multipath_dir | 保存动态共享对象的目录。默认值依系统而定，通常为 /lib/multipath。 | |||||||||
find_multipaths |
| |||||||||
reassign_maps | 启用 device-mapper 映射的创新分配。使用这个选项后，multipathd 守护进程将重新映射现有 device-mapper 映射，使其永远指向多路径设备，而不是基础块设备。可能的值包括 yes 和 no。默认值为 yes。 | |||||||||
verbosity | 默认详情。数值越高则详细程度越高。有效等级在 0 - 6 之间。默认值为 2。 | |||||||||
path_selector |
| |||||||||
path_grouping_policy |
| |||||||||
prio |
| |||||||||
features |
| |||||||||
path_checker |
| |||||||||
failback |
| |||||||||
rr_min_io | 指定切换到当前路径组的下一个路径前路由到该路径的 I/O 请求数。这个设置值用于运行内核为 2.6.31 之前的系统。使用新版本的系统应使用 rr_min_io_rq。默认值为 1000。 | |||||||||
rr_min_io_rq | 使用 request-based device-mapper-multipath 指定切换到当前路径组的下一个路径前路由到该路径的 I/O 请求数。这个设置值用于运行当前内核的系统。在使用内核 2.6.31 版本之前的系统应使用 rr_min_io。默认值为 1。 | |||||||||
rr_weight | 如果将其设为 priorities，就不会在调用 selector 选择下一个路径前向路径发送 rr_min_io 请求，而是由 rr_min_io 乘以路径优先权决定发送的请求数，即由 prio 功能决定。如果将其设定为 uniform，则所有路径都有相同的加权。默认值为 uniform。 | |||||||||
no_path_retry |
| |||||||||
user_friendly_names | 如果将其设为 yes，即指定该系统应该使用文件 /etc/multipath/bindings 为该多路径分配一个持久且唯一的别名，格式为 mpathn。如果设定为 no，即指定该系统应使用 WWID 作为该多路径的别名。在这两种情况下，您在这里指定的数值将被您在配置文件 multipaths 部分指定的具体设备别名覆盖。默认值为 no。 | |||||||||
queue_without_daemon | 如果将其设为 no，则 multipathd 守护程序将会在其关闭时禁用所有设备队列。默认值为 no。 | |||||||||
flush_on_last_del | 如果将其设为 yes，那么 multipathd 守护程序将会在设备的最后一条路径被删除时禁用队列。默认值为 no。 | |||||||||
max_fds | 设定 multipath 可以打开的文件提示符以及 multipathd 守护进程的最大值。这与 ulimit -n 命令效果一致。从 Red Hat Enterprise Linux 6.3 开始，默认值为 max，该值将该系统限制到 /proc/sys/fs/nr_open。对其较早的版本，如果没有设定这个值，则使用调用进程作为打开文件提示符的最大值，通常为 1024。安全起见，如果该数值大于 1024，应将其设定为路径最大值+32。 | |||||||||
checker_timeout | 路径检查器和排序器执行带显式超时的 SCSI 命令的超时时间，以秒为单位。默认值为 sys/block/sdx/device/timeout 中指定的值。 | |||||||||
fast_io_fail_tmo | 在 FC 远程端口发现问题后，无法在那个远程端口设备中执行 I/O 前 SCSI 层要等待的时间。默认值应小于 dev_loss_tmo 值。将其设定为 off 则会禁用超时。默认值由该操作系统决定。 | |||||||||
dev_loss_tmo | 在 FC 远程端口发现问题后，到从该系统中删除它之前 SCSI 层要等待的时间。将其设定为无限，则会将其设定为 2147483647 秒，或者 68 年。默认值由该操作系统决定。 | |||||||||
hw_string_match |
| |||||||||
retain_attached_hw_handler | 如果此参数被设为 yes，并且 SCSI 层已经为路径设备附加了硬件处理程序，那么 multipath 将不会强制设备使用 multipath.conf 文件指定的 hardware_handler。如果 SCSI 层未附加硬件处理程序，multipath 将会继续使用其配置的硬件处理程序。默认值为 no。 | |||||||||
detect_prio | 如果将此参数设定为 yes，multipath 将会首先检查该设备是否支持 ALUA。如果支持，则自动为该设备分配 alua 排序器；如果不支持，则按惯例确定排序器。默认值为 no。 | |||||||||
uid_attribute | 提供唯一路径标识符。默认值为 ID_SERIAL。 | |||||||||
force_sync | （从 Red Hat Enterprise Linux 7.1 开始）如果将其设定为“yes”，则会阻止路径检查程序在异步（async）模式下运行。这意味着每次只能运行一个检查程序。这对同时运行很多 multipathd 检查程序而造成明显 CPU 负担过重时会有帮助。默认值为 no。 | |||||||||
delay_watch_checks | （从 Red Hat Enterprise Linux Release 7.2 开始）如果将其设定为大于 0 的值，multipathd 守护进程将监视最近有效的路径，并执行指定数量的检查。如果在监视期间这些路径再次变为无法使用，则不会在这些路径下一次可用时就使用它们，直到连续检查使用 delay_wait_checks 指定的次数后它们都可用为止。 这样可防止将那些可能不太可靠的路径在上线后立即投入使用。默认值为 no。 | |||||||||
delay_wait_checks | （从 Red Hat Enterprise Linux 7.2 开始）如果将其设定为大于 0 的值，则最近重新上线的设备在由 delay_watch_checks 指定的检查次数内再次无法使用后，那么它下一次上线后就不会被标记并延迟，并在经过使用 delay_watch_checks 指定的检查次数后方可使用。默认值为 no。 | |||||||||
ignore_new_boot_devs | （从 Red Hat Enterprise Linux 7.2 开始）如果设定为 yes，在引导初期该节点仍处于 initramfs 文件系统中时，multipath 不会创建任何 WWID 属于 /etc/multipath/wwids 的 initramfs copy 中的设备。当 multipath 另外尝试在手册出现时未使用 udev 规则声明的设备中进行设置时，这个功能可用于在安装过程中引导。可将这个参数设定为 yes 或者 no。如果未设置，则默认将其设定为 no。 | |||||||||
retrigger_tries, retrigger_delay | （从 Red Hat Enterprise Linux 7.2 开始）如果 udev 无法完成原始命令让多路径无法使用该设备，则联合使用 retrigger_tries 和 retrigger_delay 参数，以便 multipathd 命令可以重新激发 uevent。retrigger_tries 参数为没有完全设置的设备设定多路径尝试重新触发 uevent 的次数。retrigger_delay 参数设定两次重试之间的秒数。这两个选项均接受大于或等于 0 的数字。将 retrigger_delay 设定为 0 就是禁用重试。将 retrigger_delay 参数设定为 0 可导致在路径检查器的下一次检查中重新启动 uevent。如果没有设定 retrigger_tries 参数，则会使用默认值 3。如果没有设定 retrigger_delay 参数，则会使用默认值 10。 | |||||||||
new_bindings_in_boot | （从 Red Hat Enterprise Linux Release 7.2 开始）使用 new_bindings_in_boot 参数在 initramfs 文件系统中保持已被常规文件系统中绑定文件耗尽的 user_friendly_name。这样会造成问题，因为只有重建 initramfs 文件系统时才会将 initramfs 文件系统中的 user_friendly_names 绑定与常规文件系统中的绑定同步。当将此参数设定为 no 后，多路经不会在 initramfs 文件系统中创建任何新绑定。如果某个设备中原来没有在 /etc/multipath/bindings 的 initramfs 副本中有任何绑定，多路经会使用其 WWID 作为别名，而不是为其分配 user_friendly_name。之后在引导后，该节点会挂载至常规文件系统，多路径会为该设备分配 user_friendly_name。可将该参数设定为 yes 或者 no。如果未设定，则默认使用 no。 | |||||||||
config_dir | （从 Red Hat Enterprise Linux Release 7.2 开始）如果设定为 "" 以外的内容，多路径会按字母顺序搜索这些路径，查找以 ".conf" 结尾的文件，并从中读取配置信息，就如同该信息位于 /etc/multipath.conf 文件中一样。这样您就会在具体机器的配置文件以外有一个主配置文件。config_dir 参数必须为 "" 或者完全限定目录名。只能在主 /etc/multipath.conf 文件中设定这个参数，不能在由 config_dir 文件自己指定的某个文件中设定这个参数。默认值为 /etc/multipath/conf.d。 | |||||||||
deferred_remove | 如果设定为 yes，则在删除最后一个路径设备时，multipathd 将会执行延期删除，而不是常规删除。这样就会保证如果执行常规删除且操作失败时某个多路径设备正在使用中，该设备会在最后一个用户关闭该设备时自动被删除。 | |||||||||
log_checker_err | 如果设定为 once，multipathd 会采用详细等级 2 记录第一个路径检查器错误。之后的所有错误都要在该设备恢复后采用详细等级 3 记录。如果设定为 always，multipathd 会一直使用详细等级 2 记录路径检查器错误。默认值为 always。 | |||||||||
skip_kpartx | 如果设定为 yes，kpartx 不会在该设备中自动创建分区。这样即使该设备有分区表，也可以允许用户在不创建分区的情况下创建多路径设备。这个选项的默认值为 no。 |
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.