Дисковод горячей замены получил новое имя. Если я добавлю его обратно в массив `md` и он будет переименован при перезагрузке, будет ли массив работать?


10

Один из жестких дисков в конфигурации RAID моего сервера вышел из строя, поэтому я вынул его из массива и попросил центр обработки данных выполнить горячую замену. Они сделали это, но теперь новый диск, /dev/sdcа не /dev/sda. Я подозреваю, что если я перезагружу сервер, он будет /dev/sdaснова, поэтому я не решаюсь добавить его обратно в массив, /dev/sdcпотому что я не хочу ставить ловушку для себя, чтобы попасть в следующую перезагрузку. Я просто не стал бы перезагружать сервер, если мне это не нужно (если мне это нужно, ну, для меня это тоже плохо).

Если я добавлю это как /dev/sdc, будет ли проблема при перезагрузке? Или есть какой - то способ , чтобы изменить имя устройства , /dev/sdcчтобы /dev/sdaбез перезагрузки?

Это на Ubuntu 10.04 LTS. Это mdмассив («программный RAID-массив Linux»), где одно из устройств (их несколько) в настоящее время выглядит так («деградировало», потому что я удалил старое /dev/sdaиз него):

# mdadm --detail / dev / md0
/ DEV / md0:
        Версия: 00.90.03
  Время создания: вс 11 октября 21:07:54 2009
     Уровень рейда: raid1
     Размер массива: 97536 (95,27 МБ, 99,88 МБ)
  Используемый размер Dev: 97536 (95,27 МБ 99,88 МБ)
   Рейдовые устройства: 2
  Всего устройств: 1
Предпочитаемый Minor: 0
    Постоянство: Суперблок является постоянным

    Время обновления: четверг, 30 июня 09:31:16 2011
          Состояние: чистое, ухудшенное
 Активные устройства: 1
Рабочие устройства: 1
 Неисправные устройства: 0
  Запасные устройства: 0

           UUID: 496be7a5: ab9177ed: 7792c71e: 7dc17aa4
         События: 0.112

    Номер майор минор
       0 8 17 0 активная синхронизация / dev / sdb1
       1 0 0 1 удалено

1
Какой массив? Если он сканирует UID, то не имеет значения, sda или sdc
Jure1873

Это mdмассив («Linux Software RAID»). Все добавление / удаление устройства и тому подобное относится к именам устройств, но я не знаю, что это означает, что это действительно зависит от них или ... Я добавил вывод mdadm --detailоб этом в вопрос.
TJ Crowder

для массивов md mdadm сканирует все диски (как определено в /etc/mdadm.conf), поэтому не имеет значения, где они находятся, потому что он записывает идентификатор в заголовок диска, чтобы можно было повторно собрать массивы.
Jure1873

Да, спасибо, проверьте обновление по вопросу, я описал, что поведение и перепроверил, это работало.
TJ Crowder

1
@TJCrowder вместо (или в дополнение) обновления вашего вопроса вы можете добавить свои результаты в качестве ответа (и принять его), так как этот вопрос в основном решен.
Деннис Нольте

Ответы:


1

Это нормально, чтобы пойти дальше и добавить его как /dev/sdc. Читая документацию ядраmd , если имя меняется при перезагрузке, это не имеет значения. (Хороший дизайн.) Вот почему:

Автозагрузка RAID-массивов во время загрузки

Когда md компилируется в ядро ​​(не как модуль), разделы типа 0xfd сканируются и автоматически собираются в RAID-массивы. Это автоопределение может быть подавлено параметром ядра "raid = noautodetect". Начиная с ядра 2.6.9, только диски с суперблоком типа 0 могут быть автоматически обнаружены и запущены во время загрузки.

Параметр ядра «raid = partitionable» (или «raid = part») означает, что все автоматически обнаруженные массивы собираются как разделимые.

Хотя я не mdскомпилировал в ядро, моя установка делает то же самое, что и выше, потому что она автоматически загружается mdadmи mdadm.confнастроена на сканирование всех разделов на наличие суперблока так же, как ядро:

# по умолчанию сканировать все разделы (/ proc / partitions) на наличие суперблоков MD.
# в качестве альтернативы, укажите устройства для сканирования, используя подстановочные знаки при желании.
DEVICE перегородки

Так что это нормально, чтобы перестроить массив с /dev/sdc; имя, вероятно, изменится /dev/sdaпри перезагрузке, но это не вызовет никаких проблем, если mdнастроено, как указано выше.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.