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

После загрузки мое устройство 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 также автоматически подключается!

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

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

Я обнаружил, что мне нужно добавить массив вручную /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 в течение многих лет без проблем.

Предупреждение: Прежде всего позвольте мне сказать, что приведенное ниже (из-за использования «--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 устройств, и я смог добавить заменяющее устройство, и оно перестраивается. Я могу получить доступ к файловой системе без каких-либо проблем.

У меня были проблемы с 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 пропустит все системные сообщения, которые мешают вам загрузиться. В моем случае это было на удаленном сервере, поэтому это было необходимо.

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

Вы можете активировать ваше устройство 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.

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

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

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

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

mdadm --examine --scan

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

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

размонтировать /dev/md127 или размонтировать /dev/md126.

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

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

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

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

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