корневой раздел на fake-RAID (imsm)
Доброе время суток, уважаемые.
Пытаюсь "собрать" систему с использованием FW RAID Intel Matrix Storage Management и mdadm 3.0.
Два винта включены в RAID1 средствами BIOS.
В процессе установки с Live-CD определен контейнер и его составляющие:
# mdadm --create --verbose /dev/md/imsm /dev/sd[ab] --raid-devices 2 --metadata=imsm # mdadm --create --verbose /dev/md/v0 /dev/md/imsm --raid-devices 2 --level 1
Полученное "зеркало" /dev/md/v0 разбито fdisk'ом на два раздела (под swap и под /). Раздел /boot будет на флешке, т.к. grub "не понимает" формата метаданных, отличного от 0.90 (по крайней мере, я не смог установить grub на этот RAID).
После установки системы впал в задумчивость - а как же, собственно, монтировать корневой раздел при загрузке? Несколько дней гуглил, плюс ставил собственные эксперименты - ответа пока не нашел.
Наверняка у кого-то используется подобная конфигурация - поделитесь инфой, как обеспечивается автоматическое "поднятие" RAID-массива при загрузке ОС, и как потом монтируется корневой раздел.
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
Думаю, имеет смысл собрать
Думаю, имеет смысл собрать initramfs со всем необходимым для монтирования RAID, что можно сделать, ЕМНИП, при помощи genkernel.
Гость написал(а): Думаю,
Пробовал. И с самописным init'ом, и с тем, который genkernel генерит. Не получается "собрать" RAID.
как, как - никак. 1) imsm -
как, как - никак.
1) imsm - дефективен бай ДНК - тема на форуме была.
2) ядро не может собрать раздел с метадатой версии выше 0.90.
3)
тема сисекпричина юзежа imsm не раскрыта ( винды пока не наблюдается) - вывод мдадм простой рулить вместе с lwmCompute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): 1) imsm
Ссылочку не дадите?
Что значит "не может"? Я неоднократно перегружался с установочного образа и "собирал" ранее созданный массив. Массив собирался нормально, второй винт не "отваливался", никаких ошибок зеркала или файловой системы не было.
Это grub "не понимает" версии метаданных выше 0.90 - ну так я вообще с флешки гружусь.
Мне такой подход (когда создается RAID целиком из двух винтов (sda и sdb), когда RAID является единым "устройством", которое разбивается на разделы) показался идеологически более правильным.
До этого с программными RAID-массивами дела не имел.
За эти несколько дней перекопал довольно много инфы в сети - Вы первый говорите о том, что так делать нельзя.
Целесообразность
Целесообразность использования fake raid под вопросом из-за того как он работает, фактически это тотже softraid из ядра, но ему обьяснили как работать с другим типом метаданных. Тоесть, логически между ними нет разницы. Разница появляется в реальности, так как со своим софтрейдом ядро будет работать всегда, независимо от матери("контроллера") а вот fakeraid - нет. Также, схема метаданных добывается методом реинжиниринга, и нет никаких гарантий правильного её описания. В итоге мы имеем выбор:
1) softraid из ядра со своей схемой, работающий стабильно и везде в linux
2) softraid из ядра с левой схемой, возможно неадекватно работающий и/или непонимающий всех фишечек производителя, также как зря поддерживаемый программами для работы с raid.
Исходя из этого, как правило fakeraid используют в крайних случаях, когда без него совсем никак, вроде dual boot с виндой.
evadim
Вы утверждаете - или только предполагаете?
Насколько я разобрался - ядру вообще глубоко фиолетово, какие там метаданные. У ядра есть тем или иным образом собранный программный массив, с которым он работает. А как этот массив собирался, или как создавался - ядру дела нет. Поэтому "обучение" mdadm "левым" метаданным оказалось делом несложным.
Поэтому мне и непонятно - почему к fake-RAID такое негативное отношение...
Потому, что не понятно зачем
Потому, что не понятно зачем нужна дополнительная прослойка, которая почти ничего не дает, зато завязана на конкретную материнку и гарантии что она(прослойка) работает 100% правильно никто не даст.
IVB написал(а): evadim
Поскольку никто так и не ответил - пришлось подробно разбираться самому.
В процессе разборок выяснилось, что поддержка external metada вносит дополнительные сложности в работу системы, а именно: грузится демон mdmon, который отслеживает изменение статуса рейда. Сначала этот mdmon нужно запустить на этапе загрузки initrd, причем ему нужна r/w файловая система, а потом еще нужно "пнуть" этот демон после нормальной загрузки, чтобы он переключился на "правильную" файловую систему с той, которую ему подсунули на этапе загрузки initrd.
В общем, я принял решение отказаться от использования external metadata, создал обычный программный рейд из двух дисков и разбил его на разделы.
При таком варианте даже initrd оказался не нужен - достаточно в конфиге GRUB'а иметь:
md=0,/dev/sda,/dev/sdb root=/dev/md0p2
IVB написал(а): ...В общем, я
Что вам и предлагали с самого начала... :)
SysA написал(а): IVB
Если бы мне с самого начала сказали "Чувак, почитай то-то и то-то", или хотя бы "погугли на предмет mdmon" - это было бы аргументом. Но когда мне говорят "Это плохо - потому что это плохо" - это не может служить аргументом.
В любом случае - спасибо всем ответившим, они были правы: использование external metadata оправдано только в крайних случаях - например, когда один и тот же массив должен быть доступен под Линухом и под Виндой.
IVB написал(а): Если бы мне с
следил за темой ради интереса, в итоге как я понял решение не найдено...
ЗЫ: помню в каком то лохматом году поставил контроллер Fasttrack tx2000. в итоге оказался софтовый и под линуксом 2 диска... ставлю FreeBSD и о чудо - она все нормально определила как raid и грузилась с него без всяких initrd... философский вопрос: почему же в линуксе не так?
________________________
"We Will Win"честно говоря не вижу причины
честно говоря не вижу причины для беспокойства ... у меня уже используется подобный сервер. Отличия - я просто отключил рейд в биосе, выставив AHCI (что прекрасно поддерживается ядром линукса и уж точно должно присутствовать в Intel контроллерах):
serverxxx ~ # mount
/dev/md3 on / type ext4 (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
securityfs on /sys/kernel/security type securityfs (rw,noexec,nosuid,nodev)
/dev/mapper/cryptvg-backup on /backup type ext4 (rw)
/dev/md1 on /boot type ext2 (rw,noatime)
serverxxx ~ # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb1[1] sda1[0]
112320 blocks [2/2] [UU]
md2 : active raid1 sdb2[1] sda2[0]
4200896 blocks [2/2] [UU]
md3 : active raid1 sdb3[1] sda3[0]
15735552 blocks [2/2] [UU]
unused devices:
Я правильно вас понял: загружаем систему с md-raid? Причем grub я не стал выносить с рейда ...
честно говоря не вижу причины
Само собой, мне беспокоится неочем :)
По теме :
на линуксовом софт-райде /ме тоже поставил немало машин, но юзать встроенный факе-раид мне в голову и в страшном сне не пришло бы.
если нужен RAID1 то обычно делал так:
100 мб /boot - md0 ( metadata - 0.90)
10Г / - мд1 (metadata - 0.90)
свап - не в райд ( ман swapon - pri=1 для обоих разделов)
остальное - мд3 (metadata - max )
на md3 при надобности lvm
если совем край - то на нарезается md4 с раид0 для дампа туда нужного файла при бекапе перед отправкой на сетевой локейшн
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): юзать
Почему? Что с ним "не так"?
Я понимаю, что "старый" способ (когда массивы создаются из разделов, а не из дисков) более привычен, т.к. "новый" способ появился совсем недавно - в mdadm 3.0+. Но почему Вы так негативно отметаете этот новый способ? Только потому, что он новый?
т.к. "новый" способ появился
Вы ошибаетесь - загнать в раид несколько блок-девайсов ( и пофик, есть на них таблица разделов или нет, и даже пофик, где они были физически) можно было всегда - как пример - /dev/md0p1 - что за зверь,по твоему ? :)
так же всегда можно было комбинировать и загонятз раид на раид
Проблема в том, что кроме сборки массива есть еще куча его операций, и как данные операции работают в линукс-раид - все уже протестировали, остальные конфиги же являются уделом тестеров, которым не нужны их данные
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)