![dm-multipath 是否调度 I/O?](https://linux22.com/image/46950/dm-multipath%20%E6%98%AF%E5%90%A6%E8%B0%83%E5%BA%A6%20I%2FO%EF%BC%9F.png)
我有一个我感兴趣的多路径设备:
[root@xxx dm-7]# multipath -ll mpathf
mpathf (3600601609f013300227e5b5b3790e411) dm-7 DGC,VRAID
size=3.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=130 status=active
| |- 7:0:1:5 sdl 8:176 active ready running
| `- 8:0:1:5 sdx 65:112 active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
|- 7:0:0:5 sdf 8:80 active ready running
`- 8:0:0:5 sdr 65:16 active ready running
所以看起来支持这条路径的块设备是sdf
、sdr
、sdl
和sdx
。举sdf
个例子,我将其 I/O 调度程序设置为noop
:
[root@xxx dm-7]# cat /sys/block/sdf/queue/scheduler
[noop] anticipatory deadline cfq
该mpathf
设备映射到/dev/dm-7
实际的块设备。我刚刚注意到它还有一个 I/O 调度程序:
[root@xxx dm-7]# cat /sys/block/dm-7/queue/scheduler
noop anticipatory deadline [cfq]
问题:哪一个优先?多路径设备上的调度程序还是最终通过其中继 I/O 的设备上的调度程序?
当然,我假设 IOP 不会被调度两次(一次用于 mpath 设备,另一次用于 I/O 重定向到的单个块设备)。
答案1
简短回答:
内核版本中的设备映射器31年6月2日之后(2009 年 9 月 9 日发布)包括对“基于请求”的 dm 目标的支持。到目前为止,唯一基于请求的 dm 目标是dm-multipath
.
对于仍然是 BIO 的目标(即一切除了多路径)调度程序选择仍然存在,但无关紧要,因为 DM 目标在此之前交出了 IOP。
对于基于请求的目标,调度程序选择将取代单个块设备上的设置,因为multipathd
将请求直接传送到底层 SCSI 设备(/dev/sg4
、/dev/sg5
等)。
附加信息:
用户应用程序 I/O 称为 BIO(块 I/O)。 BIO 被发送到调度器/电梯进行请求合并/排序,然后作为“请求”发送到较低级别的设备。
从历史上看,dm-multipath
仅在生物水平上。这产生了一个问题,来自单独 BIO 的流量将被块设备( 、 等)合并,sdb
导致sdf
某些请求队列比其他可能的路径更短/更少使用。 BIOdm-multipath
也无法了解重试事件等事件,因为它被块设备(/dev/sda
、/dev/sdb
等)隐藏。
更改之前的多路径块设备的 sysfs 对象 (RHEL 5):
[root@xxxsat01 dm-1]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.10 (Tikanga)
[root@xxxsat01 ~]# uname -r
2.6.18-371.8.1.el5
[root@xxxsat01 dm-1]# cat dev
253:1
[root@xxxsat01 dm-1]# ll
total 0
-r--r--r-- 1 root root 4096 Jan 29 13:54 dev
drwxr-xr-x 2 root root 0 Apr 29 2014 holders
-r--r--r-- 1 root root 4096 Jan 29 13:54 range
-r--r--r-- 1 root root 4096 Jan 29 13:54 removable
-r--r--r-- 1 root root 4096 Jan 29 13:54 size
drwxr-xr-x 2 root root 0 Jan 25 06:25 slaves
-r--r--r-- 1 root root 4096 Jan 29 13:54 stat
lrwxrwxrwx 1 root root 0 Jan 29 13:54 subsystem -> ../../block
--w------- 1 root root 4096 Jan 29 13:54 uevent
更改后 (RHEL 6):
[root@xxxlin01 dm-1]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
[root@xxxlin01 ~]# uname -r
2.6.32-431.3.1.el6.x86_64
[root@xxxlin01 dm-1]# cat dev
253:1
[root@xxxlin01 dm-1]# ll
total 0
-r--r--r-- 1 root root 4096 Jan 29 13:58 alignment_offset
lrwxrwxrwx 1 root root 0 Jan 29 13:58 bdi -> ../../bdi/253:1
-r--r--r-- 1 root root 4096 Jan 29 13:58 capability
-r--r--r-- 1 root root 4096 Jan 29 13:58 dev
-r--r--r-- 1 root root 4096 Jan 29 13:58 discard_alignment
drwxr-xr-x 2 root root 0 Jan 29 13:58 dm
-r--r--r-- 1 root root 4096 Jan 29 13:58 ext_range
drwxr-xr-x 2 root root 0 Jan 29 13:58 holders
-r--r--r-- 1 root root 4096 Jan 29 13:58 inflight
drwxr-xr-x 2 root root 0 Jan 29 13:58 power
drwxr-xr-x 2 root root 0 Jan 29 13:58 queue
-r--r--r-- 1 root root 4096 Jan 29 13:58 range
-r--r--r-- 1 root root 4096 Jan 29 13:58 removable
-r--r--r-- 1 root root 4096 Jan 29 13:58 ro
-r--r--r-- 1 root root 4096 Jan 29 13:58 size
drwxr-xr-x 2 root root 0 Jan 29 13:58 slaves
-r--r--r-- 1 root root 4096 Jan 29 13:58 stat
lrwxrwxrwx 1 root root 0 Jan 29 13:58 subsystem -> ../../../../class/block
drwxr-xr-x 2 root root 0 Jan 29 13:58 trace
-rw-r--r-- 1 root root 4096 Jan 29 13:58 uevent
由于内核不知道各个目标执行什么操作,因此无论设备映射器设备是什么类型,它都会呈现相同的 sysfs 属性。由于请求随后被转发到块级设备,因此设备映射器的调度程序永远不会被调用,因此此设置本质上是与其他 dm 目标的 noop。
进一步阅读: