Для того, чтобы загрузить ядро linux с корневой файловой системой лежащей на RAID-массиве нужно передать ядру следующие параметры (рабочий пример для Grub). Значимыми для нас опциями являются первая и вторая строка параметров.
Значения параметров:
1. root=/dev/md0 задает имя файла устройства с корневой ФС.
2. md=0,/dev/sda1,/dev/sdc1
На этом параметре хотелось бы остановиться подробнее. Он имеет следующий формат:
Есть еще один важный момент. В документации заявлено, что драйвер поддерживает версии суперблока 0.90.0 и md-1.
Но загрузится с RAID-1 с версией суперблока 1.2, который создается mdadm по-умолчанию у меня не получилось. Пришлось пересоздавать массив с версией 0.90.0, после чего загрузка прошла успешно. Возможно, в виду имелась поддержка версии 1.0, за исключением версий 1.1 и 1.2.
Создать массив с суперблоком версии 0.90 можно указав mdadm ключ --metadata=0.90, например так:
Если массив уже создан, но суперблок имеет версию 1.2, изменить его на версию 0.90 можно только создав новый массив указанной выше командой, и перенеся данные со старого массива на новый. Т.е. бэкап данных ОБЯЗАТЕЛЕН!
Сейчас объясню почему. Я специально проверил возможность замены суперблока с 1.2 на 0.90 без потери данных на тестовом массиве. Забегая наперед скажу, что такой возможности нет. Во всяком случае у меня не получилось. Если знаете как это сделать — расскажите, буду признателен.
Теоретически, как можно было бы подумать, можно затереть суперблок командой:
и создать новый массив без синхронизации дисков (--assume-clean), но версии 0.90 командой:
Это работает. Массив создается, таблица разделов остается (на массиве был создан один раздел с ext4), но файловая система (ext4) созданная ранее (до очистки суперблоков) отказывается монтироваться, ругаясь на поврежденный суперблок. После сравнения суперблоков этой ФС в массивах v1.2 и v0.90 оказывается что они различаются. Причем не сохраняется ни главный, ни резервные суперблоки (в 1 блоке и в 8193). Таким образом даже команда
не спасёт. Т.е. для Ваших данных смена версии суперблока RAID-массива прошла х… В общем, плохо.
Поэтому лучше, и главное — безопаснее, создать новый массив и перенести данные на него.
К слову сказать, восстановление поврежденного суперблока той же версии (допустим был массив с версией 1.2, и восстанавливаете Вы поврежденный суперблок той же версии) двумя приведенными выше командами работает великолепно и данные остаются в порядке. Благодаря ключу --assume-clean, который создает только новые суперблоки на каждом диске массива, а сами данные не трогает.
Документация на драйвер md (англ.)
title Gentoo Linux 3.0.8 Hardened
kernel (hd0,0)/linux-3.0.8-hardened/linux \
root=/dev/md0 \
md=0,/dev/sda1,/dev/sdc1 \
rootfstype=ext4 \
rootflags=nodelalloc,data=ordered,journal_checksum,barrier=1,acl,user_xattr \
panic=15 \
vga=792
Значения параметров:
1. root=/dev/md0 задает имя файла устройства с корневой ФС.
2. md=0,/dev/sda1,/dev/sdc1
На этом параметре хотелось бы остановиться подробнее. Он имеет следующий формат:
md=md_device_number,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devn
- md_device_number — номер md-устройства. Например, 0 означает /dev/md0, 1 это /dev/md1. Прошу обратить внимание — это именно НОМЕР устройства, а не количество дисков входящих в массив, как иногда встречается в описаниях в Сети.
- raid_level — уровень RAID. Является обязательным для линейного режима (значение -1) и RAID-0 (значение 0). Для остальных типов массивов информация берётся из суперблока и это значение должно быть опущено.
- chunk_size_factor — задает размер чанка. Минимальное значение 4кб (4k).
- fault_level — насколько я понял из документации, этот параметр игнорируется драйвером MD (нафига тогда предусматривали?)
- dev0,...,devn — список устройств, входящих в массив.
Есть еще один важный момент. В документации заявлено, что драйвер поддерживает версии суперблока 0.90.0 и md-1.
Но загрузится с RAID-1 с версией суперблока 1.2, который создается mdadm по-умолчанию у меня не получилось. Пришлось пересоздавать массив с версией 0.90.0, после чего загрузка прошла успешно. Возможно, в виду имелась поддержка версии 1.0, за исключением версий 1.1 и 1.2.
Создать массив с суперблоком версии 0.90 можно указав mdadm ключ --metadata=0.90, например так:
$ mdadm --create /dev/md0 -n 2 -l 1 --metadata=0.90 /dev/sd[ac]1
Если массив уже создан, но суперблок имеет версию 1.2, изменить его на версию 0.90 можно только создав новый массив указанной выше командой, и перенеся данные со старого массива на новый. Т.е. бэкап данных ОБЯЗАТЕЛЕН!
Сейчас объясню почему. Я специально проверил возможность замены суперблока с 1.2 на 0.90 без потери данных на тестовом массиве. Забегая наперед скажу, что такой возможности нет. Во всяком случае у меня не получилось. Если знаете как это сделать — расскажите, буду признателен.
Теоретически, как можно было бы подумать, можно затереть суперблок командой:
#!!! Не выполняйте следующие две команды на реальном массиве. Это пример !!!
$ mdadm --zero-superblock /dev/sd[ac]1
и создать новый массив без синхронизации дисков (--assume-clean), но версии 0.90 командой:
$ mdadm --create /dev/md0 --assume-clean -n 2 -l 1 --metadata=0.90 /dev/sd[ac]1
Это работает. Массив создается, таблица разделов остается (на массиве был создан один раздел с ext4), но файловая система (ext4) созданная ранее (до очистки суперблоков) отказывается монтироваться, ругаясь на поврежденный суперблок. После сравнения суперблоков этой ФС в массивах v1.2 и v0.90 оказывается что они различаются. Причем не сохраняется ни главный, ни резервные суперблоки (в 1 блоке и в 8193). Таким образом даже команда
$ mount -o sb=8193,nocheck -t ext4 /dev/md0 /mnt/test
не спасёт. Т.е. для Ваших данных смена версии суперблока RAID-массива прошла х… В общем, плохо.
Поэтому лучше, и главное — безопаснее, создать новый массив и перенести данные на него.
К слову сказать, восстановление поврежденного суперблока той же версии (допустим был массив с версией 1.2, и восстанавливаете Вы поврежденный суперблок той же версии) двумя приведенными выше командами работает великолепно и данные остаются в порядке. Благодаря ключу --assume-clean, который создает только новые суперблоки на каждом диске массива, а сами данные не трогает.
Документация на драйвер md (англ.)