Как заставить неактивное устройство RAID работать снова?

Question

После загрузки мое устройство RAID1 (/dev/md_d0 *) иногда переходит в какое-то смешное состояние, и я не могу его смонтировать.

^{* Первоначально я создал /dev/md0 но он каким-то образом превратился в /dev/md_d0 .}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Устройство RAID кажется неактивным как-то:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

Вопрос в том, как снова сделать устройство активным (я полагаю, используя mdmadm )?

(В других случаях все нормально (активно) после загрузки, и я могу смонтировать его вручную без проблем. Но он все равно не будет монтироваться автоматически, даже если он находится в /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Итак, дополнительный вопрос: что я должен сделать, чтобы устройство RAID автоматически монтировалось в /opt во время загрузки?)

Это рабочая станция Ubuntu 9.10. Справочная информация о моей настройке RAID в этом вопросе.

Изменить: Мой /etc/mdadm/mdadm.conf выглядит следующим образом. Я никогда не трогал этот файл, по крайней мере, от руки.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

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

Решение: как предложил Джимми Хедман, я взял вывод mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

и добавил его в /etc/mdadm/mdadm.conf , что, похоже, решило основную проблему. После изменения /etc/fstab на использование /dev/md0 снова (вместо /dev/md_d0) устройство RAID также автоматически монтируется!

Answer 1

На ваш бонусный вопрос:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Answer 2

Я обнаружил, что мне нужно добавить массив вручную в /etc/mdadm/mdadm.conf , чтобы Linux смонтировал его при перезагрузке. В противном случае я получаю именно то, что у вас есть - md_d1 - неактивные устройства и т.д.

Conf-файл должен выглядеть следующим образом - то есть одна ARRAY для каждого md-устройства. В моем случае новые массивы отсутствовали в этом файле, но если они есть в списке, это, вероятно, не решит вашу проблему.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Добавьте один массив для каждого md-устройства и добавьте их после комментария, включенного выше, или, если такого комментария не существует, в конце файла. Вы получаете UUID, выполнив sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Как вы можете видеть, вы можете просто скопировать вывод результата сканирования в файл.

Я запускаю Ubuntu Desktop 10.04 LTS, и, насколько я помню, это поведение отличается от серверной версии Ubuntu, однако это было так давно, что я создал свои md-устройства на сервере, я могу ошибаться. Также может быть, что я просто пропустил какой-то вариант.

В любом случае, добавление массива в conf-файл, похоже, помогает. Я управлял вышеупомянутым рейдом 1 и рейдом 5 в течение многих лет без проблем.

Answer 3

Предупреждение: Прежде всего позвольте мне сказать, что приведенное ниже (из-за использования «--force») мне кажется рискованным, и если у вас есть невосстановимые данные, я бы порекомендовал сделать копии соответствующих разделов до того, как вы попробуете вещи ниже. Однако это сработало для меня.

У меня была та же проблема, с массивом, отображаемым как неактивный, и ничто из того, что я делал, включая «mdadm --examine --scan>/etc/mdadm.conf», как предлагали другие здесь, не помогло вообще.

В моем случае, когда он пытался запустить массив RAID-5 после замены диска, он говорил, что он грязный (через dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Вызывает его показ неактивным в /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Я обнаружил, что на всех устройствах были одинаковые события, кроме диска, который я заменил (/dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Тем не менее, данные массива показали, что он имел 4 из 5 доступных устройств:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(Вышеприведенное относится к памяти в столбце "Состояние", я не могу найти его в буфере с прокруткой назад).

Я смог решить эту проблему, остановив массив, а затем заново собрав его:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

В этот момент массив был запущен с 4 из 5 устройств, и я смог добавить заменяющее устройство, и оно восстанавливается. Я могу получить доступ к файловой системе без каких-либо проблем.

Answer 4

У меня были проблемы с Ubuntu 10.04, где ошибка в FStab препятствовала загрузке сервера.

Я выполнил эту команду, как указано в приведенных выше решениях:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Это добавит результаты из "mdadm --examine --scan" в "/etc/mdadm/mdadm.conf"

В моем случае это было:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Это ложный страх 0. Моя команда в /etc/fstab для автоматического монтирования:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Здесь важно то, что у вас есть "nobootwait" и "nofail". Nobootwait пропустит все системные сообщения, которые мешают вам загрузиться. В моем случае это было на удаленном сервере, поэтому это было необходимо.

Надеюсь, что это поможет некоторым людям.

Answer 5

Когда вы притворяетесь, что что-то делаете с /dev/md[012346789} он переходит к /dev/md{126,127...} . /dev/md0 продолжает монтироваться в /dev/md126 или /dev/md127 вам необходимо:

umount /dev/md127 или umount /dev/md126 .

Это временно, чтобы позволить вам выполнять команды и некоторые приложения без остановки вашей системы.

Answer 6

Вы можете активировать ваше устройство MD с

mdadm -A /dev/md_d0

Я полагаю, что некоторые сценарии запуска запускаются слишком рано, до того, как был обнаружен один из участников RAID или возникла подобная проблема. В качестве быстрого и грязного обходного пути, вы должны иметь возможность добавить эту строку в /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Изменить: очевидно, ваш /etc/mdadm/mdadm.conf все еще содержит старое имя конфигурации. Отредактируйте этот файл и замените вхождения md0 на md_d0.

Answer 7

У меня была похожая проблема ... мой сервер не смонтировал md2 после того, как я увеличил разделы, связанные с устройствами. Читая эту ветку, я обнаружил, что на устройстве RAID md2 был новый UUID, и машина пыталась использовать старый.

Как и предполагалось ... используя вывод 'md2' из

mdadm --examine --scan

Я отредактировал /etc/mdadm/mdadm.conf и заменил старую строку UUID командой «один вывод сверху», и моя проблема исчезла.

Answer 8

md_d0 : inactive sda4[0](S) выглядит неправильно для массива RAID1. Кажется, предполагается, что в массиве нет активных устройств и одно запасное устройство ^{_{(обозначенное (S), вы увидите там (F) для отказавшего устройства и ничего для OK/ активного устройства)}} - для массива RAID1, который не Для работы с ухудшенной версией должно быть как минимум два устройства OK/ active ^{_{(и для поврежденного массива, по крайней мере, одно устройство OK/ active),}} и вы не можете активировать массив RAID1 без неисправных устройств, не являющихся неисправными не содержат копию данных, пока они не станут активными при сбое другого диска). Если я правильно читаю вывод /proc/mdstat , вы не сможете активировать массив в его текущем состоянии.

Есть ли в машине какие-либо физические диски, которые не раскручивались? Перечисляет ли ls /dev/sd* все диски и разделы, которые вы обычно ожидаете увидеть на этом компьютере?

Answer 9

Простой способ запустить массив при условии отсутствия проблем с оборудованием и наличия достаточного количества дисков / разделов для запуска массива заключается в следующем:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Может быть так, что по какой-то причине массив в порядке, но что-то помешало его запуску или сборке. В моем случае это было потому, что mdadm не знал, что исходное имя массива было md127, и все диски были отключены для этого массива. При повторном подключении мне пришлось собирать вручную (вероятно, ошибка, когда mdadm считал, что массив уже активен из-за автономного имени старого массива).