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

161985
Jonik

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

29

9 ответов на вопрос

24
Jimmy Hedman

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

mdadm --examine --scan >> /etc/mdadm/mdadm.conf 
Хорошо, `mdadm --examine --scan` создал` ARRAY / dev / md0 level = raid1 num-devices = 2 UUID = ... `(обратите внимание на md0 вместо md_d0!) Я поместил это в файл mdadm.conf (вручную, потому что была некоторая проблема с sudo и `>>` ("разрешение запрещено"), а sudo * * обязательна), а также обновил fstab для повторного использования md0 (не md_d0). Теперь я, похоже, больше не сталкиваюсь с «неактивной» проблемой * и * устройство RAID монтируется автоматически в / opt при загрузке. Тогда спасибо! Jonik 14 лет назад 2
Причина, по которой у вас возникли проблемы с `sudo ... >> mdadm.conf`, заключается в том, что оболочка открывает перенаправленные файлы перед запуском sudo. Команда `su -c '.... >> mdadm.conf'` должна работать. Mei 11 лет назад 3
10
Erik

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

То есть, по сути, вы говорите то же самое, что и принятый в настоящее время ответ, просто более многословно? :) Еще +1, хороший первый пост. Jonik 13 лет назад 1
7
Sean Reifschneider

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

4
Nick Woodhams

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

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

Это то, что сделал это для меня. Мои RAID-накопители подключены через SATA-карту PCI Express, поэтому я предполагаю, что во время загрузки система еще не видела эти накопители. Michael Robinson 9 лет назад 0
2
wazoox

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

Хорошо, в тех случаях, когда устройство * активируется * после перезагрузки, просто `mount / dev / md_d0` в` / etc / rc.local` работает нормально. С другой стороны, `mdadm -A / dev / md_d0` завершается с этим сообщением об ошибке в обоих случаях (поэтому я не мог использовать его до этого оператора` && `). В любом случае, половина проблемы кажется решенной, поэтому +1 за это. Jonik 14 лет назад 0
На самом деле mdadm.conf не содержит никакого имени конфигурации, по крайней мере, напрямую (хотя он ссылается на `/ proc / partitions`); см. отредактированный вопрос. Я никогда не касался mdadm.conf - что это за инструмент, который его генерирует? Jonik 14 лет назад 0
Для записи удалил обходной путь `/ etc / rc.local`, так как кажется, что все работает правильно: http://superuser.com/questions/117824/how-to-get-an-inactive-raid-device- рабочий снова / 118251 # 118251 :) Jonik 14 лет назад 0
2
Peter Errity

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

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

mdadm --examine --scan 

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

2
Vanderj68

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

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

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

1
David Spillett

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

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

Кажется, я больше не могу воспроизвести неактивную ситуацию, следуя совету в ответе Джимми (похоже, так или иначе после нескольких перезагрузок) ... Что приятно :) Спасибо в любом случае! Jonik 14 лет назад 0
Я перенес вопрос об этом состоянии в список рассылки Linux RAID и получил ответ: https://www.spinics.net/lists/raid/msg61352.html nh2 5 лет назад 0
Как я только что написал [здесь] (http://fibrevillage.com/storage/676-how-to-fix-linux-mdadm-inactive-array#!/ccomment-comment=175), `echo active> / sys / block / md0 / md / array_state` работал для меня, в результате чего мой RAID снова отображался как RAID1 с отсутствующим диском вместо RAID0 с запасным. nh2 5 лет назад 0
1
Areeb Soo Yasir

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

md20 : inactive sdf1[2](S) 732442488 blocks super 1.2  sudo mdadm --manage /dev/md20 --run 

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