dm-多径调度I/O吗？

Question

我有一个我感兴趣的多径设备：

[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被重定向到)。

Answer 1

简短回答：

2.6.31之后内核版本中的设备映射器(2009年9月9日发布)包括对“基于请求”的dm目标的支持。到目前为止，只有基于请求的dm目标是dm-multipath。

对于剩余的目标(即，除了多路径之外的一切)，调度器选择仍然存在，但与DM目标在此之前放弃IOP无关。

对于基于请求的目标，调度器选择将取代在单个块设备上设置的内容，因为multipathd将直接将请求传递到底层SCSI设备(/dev/sg4、/dev/sg5等)。

附加信息：

用户应用程序I/O称为BIO (块I/O)。BIO被发送到调度器/电梯进行请求合并/排序，然后作为“请求”发送到较低级别的设备。

从历史上看，dm-multipath仅仅停留在生物层面。这造成了一个问题，即来自不同BIO的通信将被块设备(sdb、sdf等)合并，从而导致某些请求队列比其他可能的路径更短/更少使用。BIO dm-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。

继续阅读：

• 为什么我的Linux系统上存在/sys/block/dm-0/系统上存在/调度程序？
• 渥太华Linux研讨会2007关于基于请求的设备Mapper的介绍