Есть ли способ надежно определить, какой физический диск в RAID-массиве соответствует программному имени устройства, присвоенному ему ОС?
У меня есть RAID5-массив USB-дисков потребительского класса (и один запасной) на концентраторе, подключенном к ПК. Это служит дешевым NAS.
Каждое устройство идентифицируется /proc/mdstatпо своему имени (например sdb, sdc).
Насколько я могу судить, имена устройств Linux зависят от порядка, в котором оборудование считывается при загрузке. Так что мне не следует, например, наклеивать наклейку на каждый диск с этими именами устройств, потому что sdcсегодня может быть sdbв будущем.
В случае сбоя я мог бы проверить текущее сопоставление имен устройств, остановив RAID, а затем посмотреть, dmesg -Wкак я удаляю каждое устройство по одному, пока не удалю неисправное устройство методом исключения. Но есть ли лучший способ?
Я вижу, что я не могу помечать элементы RAID по отдельности — они все должны иметь одно и то же имя массива:https://wiki.archlinux.org/title/название_персистентного_блочного_устройства#по-метке
Я рассмотрел, ledctlно это не работает с потребительскими дисками:https://linux.die.net/man/8/ledctl
решение1
Используйте lsblk -Sдля сопоставления каждого устройства серийному номеру диска (или WWN, если вы добавляете -o +wwn).
Пути USB-концентратора, отображаемые lsusb.py -ciили udevadm info /dev/sdd | grep ID_PATH=должны иметь фиксированное сопоставление с физическими портами USB, например, на моем сервере "1-1.1" и "1-1.2" подключены к портам передней панели. Порядок портов на внешнем концентраторе не всегда очевиден, но он все равно должен оставаться статическим, как только вы с ним разберетесь.
Альтернатива светодиодам: Скрипты scsi_start/ scsi_stopиз sg3_utils могут заставить HDD вращаться быстрее или медленнее по требованию (без их фактического отключения). Если массив простаивает, остановите все диски и вращайте их по одному, пока не сопоставите все корпуса с серийными номерами HDD.
решение2
Я написал ответ, но с тех пор обнаружил, что использование UUID_SUBзначения lsblk НЕ является решением. Недавнее событие сбоя диска показало мне, что, UUID_SUBпохоже, не присоединено к суперблоку раздела диска, как я сначала думал.
Поэтому я удаляю свой первоначальный ответ и предоставляю другим возможность проголосовать за его удаление.
На сегодняшний день единственным проверенным ответом на этот вопрос является использование голых дисков, серийные номера которых видны на самом корпусе привода, а не на внешнем корпусе, который может отличаться. Затем используйте их, lsbk -Sчтобы выяснить, с каким физическим диском следует иметь дело в случае отказа.