dm-multipath 是否調度 I/O？
我有一個我感興趣的多路徑設備：
[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、、、和。僅舉個例子，我將它的 I/O 調度程序設置為：sdr``sdl``sdx``sdf``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 重定向到的單個塊設備）。
簡短的回答：
2.6.31（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 級別。這產生了一個問題，即來自不同 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。
延伸閱讀：