В
продолжение предыдущей статьи. Что
происходит, когда
произошла авария (или
просто накосячили)
и все пути для multipath устройства находятся
в состоянии
failed? Пример
ниже:
#
multipath -ll
mpathb
(
360a98000646e6c512f4a6f714f46324f
)
dm-6 NETAPP ,LUN
size=110G
features='4 queue_if_no_path pg_init_retries 50
retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+-
policy='service-time 0' prio=0 status=enabled
|
|- 0:0:0:42 sdc 8:32 failed faulty running
|
`- 1:0:2:42 sdad 65:208 failed faulty running
`-+-
policy='service-time 0' prio=0 status=enabled
|-
0:0:2:42 sdl 8:176 failed faulty running
`-
1:0:1:42 sdw 65:96 failed faulty running
Удаление
multipath
устройства
может закончиться
ошибкой:
#
multipath -f
mpathb
Jan
29 13:42:58 |
mpathb
:
map in use
Jan
29 13:42:58 | failed to remove multipath map
mpathb
При
этом утилиты просмотра дисков, такие
как pvs, начинают зависать, в системе
начинают появляться неубиваемые процессы
в состоянии D - uninterruptible sleep. Все это,
конечно же, очень печалит
и
ставит в тупик. Но, как говорится, даже
если вас съели — то у вас все равно есть
два пути. Этой беде тоже можно помочь.
Обратите внимание на опцию в конфигурации
multipath диска - "queue_if_no_path" —
дословно
держать
очередь, если нет активных путей.
Опцию
нужно убрать из конфигурации и затем
нужно перечитать конфигурационный
файл. После чего уйдут процессы в
состоянии
uninterruptible
sleep,
которые
держат диск.
Эта опция может отсутствовать в явном виде в конфигурационном файле, она часто встречается в дефолтной
настройке даемона multipathd для различных
схд. Убрать опцию
queue_if_no_path
на multipath диске можно следующим
образом:
#
dmsetup
message mpathb 0 fail_if_no_path
После
чего диск можно удалить:
#
multipath -f
mpathb