Как работает програмный RAID

[FreeArcher]

Создал себе програмный рэйд, через mdadm. Все получилось перенес данные уже. Но сегодня после перезагрузки присмотрелся к инфе:

Код: Выделить всё

    [famely@fr-comp ~]$ cat /proc/mdstat
    Personalities : [raid1]
    md0 : active raid1 sdb1[1]
          312437376 blocks super 1.2 [2/1] [_U]

Код: Выделить всё

[famely@fr-comp ~]$ sudo mdadm -D /dev/md0
    /dev/md0:
            Version : 1.2
      Creation Time : Tue Jul 31 21:40:36 2012
         Raid Level : raid1
         Array Size : 312437376 (297.96 GiB 319.94 GB)
      Used Dev Size : 312437376 (297.96 GiB 319.94 GB)
       Raid Devices : 2
      Total Devices : 1
        Persistence : Superblock is persistent

        Update Time : Wed Aug  1 08:26:33 2012
              State : clean, degraded
    Active Devices : 1
    Working Devices : 1
    Failed Devices : 0
      Spare Devices : 0

               Name : fr-comp:0  (local to host fr-comp)
               UUID : 0c0bc106:6e19a49a:de962ec8:c7c7ab5f
             Events : 25

        Number   Major   Minor   RaidDevice State
           0       0        0        0      removed
           1       8       17        1      active sync   /dev/sdb1

Правильно ли я понимаю, что сейчас в массиве задействован только 1 раздел?
Создавался так:

Код: Выделить всё

    mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda6 /dev/sdb1

sda - 500 Гб - там выделен логический раздел
sdb - 350 Гб - тут один раздел занятый полностью под рэйд.

Мне как бы непонятно откуда вобще Линукс берет информацию о моем Рейде?
Никаких конфигов mdadm не создал. Я создал сам /etc/mdadm/mdadm.conf , но что-то сомневаюсь что его читают.
Монтирую рэйд в fstab

Код: Выделить всё

    /dev/md0       /mnt/DATA       ext4           defaults       1  2

Если грузится с LiveCD то рейд определяется как устройство /dev/md127.
Но по анализу все так же.

Прошу подсказать по вопросам и тогда думаю будет понятнее в какую сторону копать.

[Ленивая Бестолочь]

линукс определяет компоненты рейда по типу раздела, у mdraid это FD: Linux raid autodetect.
проставте типы разделов, например с помощью cfdisk.

добавьте свой сбежавший раздел обратно:

Код: Выделить всё

mdadm --add /dev/md0 /dev/sda6

проверьте, что всё ок в mdstat и сгенерируйте правильный конфиг:

Код: Выделить всё

         echo 'DEVICE /dev/hd[a-z] /dev/sd*[a-z]' > mdadm.conf
         mdadm --examine --scan --config=mdadm.conf >> mdadm.conf

проверьте конфиг и положите его на место.

после этого ещё желательно перегенерировать initrd/initramfs, чтобы конфиг попал в неё тоже, если она используется конечно:

Код: Выделить всё

update-initramfs -u -k all

это команда для дебиана, как в мопсе я не в курсе.


ах да,

Правильно ли я понимаю, что сейчас в массиве задействован только 1 раздел?

правильно. второй не подцепился.

[FreeArcher]

Ленивая Бестолочь, спасибо.
Linux raid autodetect - ставил, но перепроверю.
И всетаки нужен ли mdadm.conf, ведь LiveCD и без него определяет рэйд?
У dracut есть опция

Код: Выделить всё

       --nomdadmconf
           do not include local /etc/mdadm.conf

update-initramfs -u -k all, как я понял в федоре используется dracut.


И да поравил профиль я использую Fedora (RFRLinux).

[Ленивая Бестолочь]

LiveCD и без него определяет рэйд?

ну livecd на то и live, чтобы запускаться на наибольшем колличестве систем и по максимуму всё определять.
возможно он ориентируется исключительно на тип раздела, а может быть там есть на этот счёт свои скрипты какие-то.

У dracut есть опция

ну, выходит, что по умолчанию (без этой опции) dracut будет включать конфиг mdadm в initramfs, что в общем то вполне себе хорошо.

[Bluetooth]

линукс определяет компоненты рейда по типу раздела, у mdraid это FD: Linux raid autodetect.

По крайней мере в дебиане lenny и squeeze это не так. Думаю, проверяются все разделы, вне зависимости от типа в таблице разделов.

[KiWi]

линукс определяет компоненты рейда по типу раздела, у mdraid это FD: Linux raid autodetect.

По крайней мере в дебиане lenny и squeeze это не так. Думаю, проверяются все разделы, вне зависимости от типа в таблице разделов.

Вообще, в ubuntu lucid это делает udev-скрипт, который тип таки проверяет:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
RUN+="/sbin/mdadm --incremental $env{DEVNAME}"

Думаю, в debian аналогично.
Это чтобы собиралось совсем автоматом. Возможно, где-нибудь сверху есть ещё какая-нибудь собиралка.

[FreeArcher]

Вобщем восстановил я рейд, как было написано. Все сделал.
Но, Линукс у меня неожиданно помер, отказался грузится причем , как то совсем непонятно в причинах. Ну не суть, я уже заколебался, так что проще переустановить. Благо Федора разворачивается буквально за 5 минут.

И главный вывод из этого, что на чистая системе мой Рэйд определился и работает! Осталось только подмонтировать.
Т.е. никаких dracut, /etc/mdadm.conf нет и все работает. В итоге вывод ядро само по типу раздела "FD: Linux raid autodetect" находит разделы рейда и видимо из них же черпает информацию о типе рэйда и входящих в него разделах.

Так что получается вобще не нужен /etc/mdadm.conf и обновление initramfs? Или есть какие-то подводные камни?

[Bluetooth]

Вообще, в ubuntu lucid это делает udev-скрипт, который тип таки проверяет:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
RUN+="/sbin/mdadm --incremental $env{DEVNAME}"

Эмм, а разве переменная ID_FS_TYPE - это переменная, содержащая тип раздела? Из названия следует, что она содержит тип фс на разделе, а из одного лишь типа раздела это не выяснить.
Впрочем, в правилах udev для lenny и для squeeze все равно нет ничего похожего(точнее, в squeeze подобная строчка закомменчена).

Так что получается вобще не нужен /etc/mdadm.conf и обновление initramfs? Или есть какие-то подводные камни?

Как правило, прописывать ничего в конфигах не надо. И в initramfs, как правило, прописывается собрать все рейды, которые найдет.

[Ленивая Бестолочь]

Эмм, а разве переменная ID_FS_TYPE - это переменная, содержащая тип раздела? Из названия следует, что она содержит тип фс на разделе, а из одного лишь типа раздела это не выяснить.

"тип раздела" в таблице разделов исторически должен был содержать тип ФС. ну понятно, что на практике содержит всё подряд. так что скорее всего это как раз то, о чём мы говорим.

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

[Bluetooth]

Эмм, а разве переменная ID_FS_TYPE - это переменная, содержащая тип раздела? Из названия следует, что она содержит тип фс на разделе, а из одного лишь типа раздела это не выяснить.

"тип раздела" в таблице разделов исторически должен был содержать тип ФС. ну понятно, что на практике содержит всё подряд. так что скорее всего это как раз то, о чём мы говорим.

Тип раздела исторически и сейчас содержит тип раздела. А фс при этом может быть разная. Наиболее распространенная ситуация:
тип раздела выставляется 0x83, А внутри может быть ext2, ext3, ext4 и другие фс. Так вот в таблице разделов записано 0x83. Вряд ли одно только значение 0x83 будет полезно в качестве значения переменной ID_FS_TYPE. Поэтому, есть подозрения, что для этой переменной используется более сложный механизм, нежели простое чтение таблицы разделов.

[KiWi]

Эмм, а разве переменная ID_FS_TYPE - это переменная, содержащая тип раздела? Из названия следует, что она содержит тип фс на разделе, а из одного лишь типа раздела это не выяснить.

"тип раздела" в таблице разделов исторически должен был содержать тип ФС. ну понятно, что на практике содержит всё подряд. так что скорее всего это как раз то, о чём мы говорим.

Тип раздела исторически и сейчас содержит тип раздела. А фс при этом может быть разная. Наиболее распространенная ситуация:
тип раздела выставляется 0x83, А внутри может быть ext2, ext3, ext4 и другие фс. Так вот в таблице разделов записано 0x83. Вряд ли одно только значение 0x83 будет полезно в качестве значения переменной ID_FS_TYPE. Поэтому, есть подозрения, что для этой переменной используется более сложный механизм, нежели простое чтение таблицы разделов.

Вообще, да, ID_FS_TYPE приезжает из blkid, который делается в /lib/udev/rules.d/60-persistent-storage.rules.

[FreeArcher]

Что-то мне этот рэйд мозг выносит.

Вобщем решил протестировать его.
Отключил физически один из дисков и попробовал загрузится. И вот те раз система ступарится на моменте инициализации рейда ругаясь на него. Предлагает ввести пароль рута и ковырять дальше.
Очень удивило это поведение, ну вылетел один диск - дальше то надо продолжать ведь работать, а если это был бы сервер...
При этом если грузишься с ЛивСД - то рейд определяется, хоть и с одним винтом.

Ладно сделал mdadm -add. Рейд восстановился 350 ГБ около 2х часов долговато как-то, притом почему бы просто не подключить диск, я так понимаю так долго заново создавалось зеркало переливалась инфа на второй диск?
Перегружаюсь и ситуация снова повторяется, т.е. рейд не определился.

Пытаюсь выкрутится: удаляю mdadm.conf и комментирую строку в fstab. И замечательно гружусь, причем рейд рабочий, раскомментировал fstab и подмонировал.
Опять же ставится под сомнение необходимость mdadm.conf.

Даже не знаю что спросить, просто мне кажется вот такие проблемы (невозможность загрузится и 2х часовая задержка на синхронизацию), как то не допустимо для реальной работы на серверах.
Может моя логика действия не верная или это нормально и нужно мерится, и не дергать за ненадобностью винты?

[Bluetooth]

Отключил физически один из дисков и попробовал загрузится. И вот те раз система ступарится на моменте инициализации рейда ругаясь на него. Предлагает ввести пароль рута и ковырять дальше.

Ну так ввели пароль и что увидели? /proc/mdstat что говорил?

Рейд восстановился 350 ГБ около 2х часов долговато как-то

средняя скорость около 50мб/с - нормально, в общем-то, для винтов начальной линейки.

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

Да, все содержимое зеркалировалось. А сделано это для того, чтобы инфа на двух дисках была одинаковой. Если "просто подключить диск", то этого уже не будет :)

Перегружаюсь и ситуация снова повторяется, т.е. рейд не определился.

Есть подозрение, что рейд не определялся не из-за отсутствующего винта. Опять же. как это выглядело?

Пытаюсь выкрутится: удаляю mdadm.conf и комментирую строку в fstab. И замечательно гружусь, причем рейд рабочий, раскомментировал fstab и подмонировал.
Опять же ставится под сомнение необходимость mdadm.conf.

Как уже было сказано в большинстве дистрибутивов в большинстве случаев все работает и без mdadm.conf.
У Вас же, скорее всего, был некорректный mdadm.conf.
Но опять же, в Ваших сообщениях никакой конкретики нет вообще, а без конкретных данных мы не можем сказать, в чем проблема была.

просто мне кажется вот такие проблемы (невозможность загрузится и 2х часовая задержка на синхронизацию), как то не допустимо для реальной работы на серверах.

Так и есть. Поэтому нужно уметь работать с рейдами, чтобы такие проблемы не возникали. Кстати, если Вы подумаете, то поймете, что 2х часовая синхронизация после подключения нового винта обусловлена необходимостью скопировать данные оттуда, где они есть, туда, где их нет. И делается это специально в фоне, потому что может занимать длительное время. Также можно регулировать и скорость ресинка.

Может моя логика действия не верная или это нормально и нужно мерится, и не дергать за ненадобностью винты?

Сломал мозг, пока не понял, что "мерится" == "мириться".
Мириться ни с чем не надо,тренируйтесь, разбирайтесь, пока не научитесь хорошо работать с рейдами.

[FreeArcher]

Bluetooth, спасибо за развернутый ответ.

Ну так ввели пароль и что увидели? /proc/mdstat что говорил?

А ничего не говорил в том то и дело, будто рейда и не было никогда.

Я особой конкретики не спрашивал, потому и не было никаких логов. Просто какие то общие рекомендации, хотел получить. Ну вроде как получил, спасибо.

Единственное спрошу, что находится в mdadm.conf?
Как я понимаю, там список разделов которые нужно опрашивать и UUID рейда и разделов входящих в него одной строкой?

[sash-kan]

А ничего не говорил в том то и дело, будто рейда и не было никогда.

если команда
$ cat /proc/mdstat
не вывела вообще ничего, это значит, что не загружен ни один рейдовый модуль (это когда они модулями собраны, что, с большой долей вероятности, у вас и наличествует)·
соответственно, имеет смысл разобраться с initrd: включены ли в него нужные модули, и если включены, то почему не загрузились·

[sash-kan]

соответственно, имеет смысл разобраться с initrd

как у вас в дистрибутиве перегенерируется initrd, я вам не подскажу, равно как не подскажу, как повлиять на список модулей, которые при генерации будут в него включены (скопированы из /lib/modules)·
но могу напомнить, что список доступных в конкретный момент модулей (а вас должен заинтересовать тот момент, когда система у вас «заступоривается» и отказывается продолжать инициализацию) можно посмотреть командой
# modprobe -l
убедитесь, что в списке будут присутствовать все те рейд-модули, которые загружены в состоянии «всё работает»·

[FreeArcher]

# modprobe -l
убедитесь, что в списке будут присутствовать все те рейд-модули, которые загружены в состоянии «всё работает»·

#lsmod - может имеется в виду, modprobe не принимает такие параметры?

[sash-kan]

нет·
см.:
$ man lsmod
$ man modprobe

modprobe не принимает такие параметры

если в initrd какая-то урезанная версия программы modprobe, посмотрите «ручками» в под-каталогах /lib/modules/

[FreeArcher]

нет·
см.:
$ man lsmod
$ man modprobe

modprobe не принимает такие параметры

если в initrd какая-то урезанная версия программы modprobe, посмотрите «ручками» в под-каталогах /lib/modules/

Ты наверное имеешь в виду мосмотреть какой модуль используется через lsmod.
У меня это "raid1".
А потом
#modprobe raid1 - подгрузить его. Если ввдруг он не запустится.

[sash-kan]

FreeArcher
ещё раз на пальцах·
ваша нормально загрузившаяся система, в которой примонтирована ваша полноценная rootfs с полным комплектом модулей в /lib/modules, находит и благополучно собирает рейд-массив·
в частности, благодаря тому, что в linux подгружен нужный рейдовый модуль (raid1, например)·

насколько я понял, вам нужно, чтобы ваш рейд-массив собирался ещё в процессе загрузки, когда linux-у доступны только те модули, что включены в initrd·
судя по вашим словам, система на этапе загрузки останавливалась и жаловалась на то, что не может собрать рейд-массив·
судя по тому, что команда
$ cat /proc/mdstat
в этот момент не возвращала вообще ничего, нужные модули (raid1, например), не были загружены в linux·
чтобы убедиться в том, что они действительно не загружены, нужно повторить ту же ситуацию (остановку загрузки по причине невозможности собрать рейд-массив) и посмотреть список загруженных модулей linux-а·
с помощью программы lsmod·
если они действительно не загружены, причин, по которой это могло произойти, наверно, более чем достаточно, но наиболее вероятна одна: нужные модули просто не включены в initrd·
проверить список доступных для загрузки модулей можно командой
# modprobe -l
если она ничего не покажет — не страшно·
просто «ручками» пройдитесь по под-каталогам католога /lib/modules·
если вы там не обнаружите нужного модуля (raid1, например), то вам надо перегенерировать initrd таким образом, чтобы нужный модуль таки попал в initrd·
если вы нужный модуль где-то в дебрях /lib/modules обнаружите, нужно выяснять причину, по которой он не загружается·

p.s. я нажевал более чем достаточно ключевой информации·
удачи·