На ваш бонусный вопрос:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
После загрузки мое устройство 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.
У меня была похожая проблема ... мой сервер не смонтировал md2 после того, как я увеличил разделы, связанные с устройствами. Читая эту ветку, я обнаружил, что на устройстве RAID md2 был новый UUID, и машина пыталась использовать старый.
Как и предполагалось ... используя вывод 'md2' из
mdadm --examine --scan
Я отредактировал /etc/mdadm/mdadm.conf
и заменил старую строку UUID командой «один вывод сверху», и моя проблема ушла.
Когда вы делаете вид, что - то делать с /dev/md[012346789}
он идет /dev/md
. /dev/md0
продолжается в /dev/md126
или /dev/md127
вы должны:
размонтировать /dev/md127
или размонтировать /dev/md126
.
Это временно, чтобы позволить вам выполнять команды и некоторые приложения без остановки вашей системы.
md_d0 : inactive sda4[0](S)
выглядит неправильно для массива RAID1. Кажется, предполагается, что в массиве нет активных устройств и одно запасное устройство (обозначенное (S), вы увидите там (F) для отказавшего устройства и ничего для OK / активного устройства) - для массива RAID1, который не для работы с ухудшенной версией должно быть как минимум два устройства OK / active (и для поврежденного массива, по крайней мере, одно устройство OK / active), и вы не можете активировать массив RAID1 без неисправных устройств без резервирования (как запасных) не содержат копию данных, пока они не станут активными при сбое другого диска). Если я /proc/mdstat
правильно читаю этот вывод, вы не сможете активировать массив в его текущем состоянии.
Есть ли в машине какие-либо физические диски, которые не раскручивались? Есть ли в ls /dev/sd*
списке все диски и разделы, которые вы обычно ожидаете увидеть на этом компьютере?
Простой способ запустить массив при условии отсутствия проблем с оборудованием и наличия достаточного количества дисков / разделов для запуска массива заключается в следующем:
md20 : inactive sdf1[2](S) 732442488 blocks super 1.2 sudo mdadm --manage /dev/md20 --run
Может быть так, что по какой-то причине массив в порядке, но что-то помешало его запуску или сборке. В моем случае это было потому, что mdadm не знал, что исходное имя массива было md127, и все диски были отключены для этого массива. При повторном подключении мне пришлось собирать вручную (вероятно, ошибка, когда mdadm считал, что массив уже активен из-за автономного имени старого массива).