Планируется ли ввод / вывод dm-multipath?

У меня есть многопутевое устройство, которое меня интересует:

[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 в качестве примера, я установил его планировщик ввода-вывода как noop :

 [root@xxx dm-7]# cat /sys/block/sdf/queue/scheduler [noop] anticipatory deadline cfq 

Устройство mpathf сопоставляется с /dev/dm-7 для фактического блочного устройства. Я только что заметил, что у этого есть планировщик ввода-вывода:

 [root@xxx dm-7]# cat /sys/block/dm-7/queue/scheduler noop anticipatory deadline [cfq] 

Вопрос: какой из них имеет приоритет? Планировщик на многолучевом устройстве или на устройстве заканчивает передачу через I / O через?

Я, конечно, предполагаю, что IOPs не запланированы дважды (один раз для устройства mpath, а другой для отдельного блочного устройства перенаправлен I / O).

One Solution collect form web for “Планируется ли ввод / вывод dm-multipath?”

Короткий ответ:

Device Mapper в версиях ядра после версии 2.6.31 (выпущен 9 сентября 2009 г.) включает поддержку «целей, основанных на запросах». Пока единственная цель dm-multipath основе запроса – dm-multipath .

Для целевых объектов, которые остаются BIO (т.е. все, кроме многолучевого), выбор планировщика по-прежнему присутствует, но не имеет значения, поскольку цель DM отделяет IOP до этой точки.

Для целей на основе запроса выбор планировщика заменяет то, что установлено на отдельном блочном устройстве, поскольку multipathd будет передавать запросы непосредственно на основное устройство SCSI ( /dev/sg4 , /dev/sg5 и т. Д.).

Дополнительная информация:

Ввод / вывод прикладных программ называется BIO (блок ввода-вывода). BIO отправляется в планировщик / лифт для запроса слияния / заказа, а затем отправляется как «запрос» на устройства нижнего уровня.

Исторически, dm-multipath был исключительно на уровне BIO. Это создало проблему, когда трафик из отдельных 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, независимо от того, какой тип устройства он-лайн. Поскольку запрос затем ретранслируется на устройства уровня блока, планировщик планировщика устройства никогда не вызывается, и поэтому этот параметр по существу является noop с другими целями dm.

Дальнейшее чтение:

  • Почему в моей системе Linux существует / sys / block / dm-0 / queue / scheduler?

  • Ottawa Linux Symposium 2007 Презентация на основе данных, основанных на запросах

  • связать MAC с IP-адресом?
  • Маршрут блокирует входящий трафик
  • Как память RES, сообщенная для процесса Java, будет выше, чем память VIRT?
  • Почему теоретический предел RAM для RHEL 6 128 TB и как это определяется?
  • Отправлять журналы на несколько серверов syslog
  • yum groupremove «Средства разработки»: хранить пакеты, требуемые другими пакетами
  • Как я могу открыть сетевой интерфейс non-boot (ONBOOT = no) с помощью iproute2?
  • Установка PCRE 32bit на RHEL 5 - разрешение зависимости для установки apache 2.4
  • С какими файловыми системами можно читать RHEL 5 и писать?
  • egrep не работает должным образом в системе SunOS
  • Как проверить, распространяется ли дистрибутив на Fedora?
  • Linux и Unix - лучшая ОС в мире.