Загрузка Linux с корнем на RAID
Для того, чтобы загрузить ядро linux с корневой файловой системой лежащей на RAID-массиве нужно передать ядру следующие параметры (рабочий пример для Grub). Значимыми для нас опциями являются первая и вторая строка параметров.
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, который создает только новые суперблоки на каждом диске массива, а сами данные не трогает.
Источник
Как загрузиться с RAID
Подскажите кто в курсе, как делается загрузка с RAID. Я имею в виду такую загрузку, что бы и linux и grub и вообще все что находится на HDD(mbr, gpt. ) было в RAID. Что бы BIOS загружал систему из RAID.
Сейчас использую вариант когда мой домашний сервер загружается с одного диска, потом после загрузки монтирует «ценные» данные, которые хранятся в BRTFS RAID. В целом так достаточно неплохо живется, но когда дохнет диск с системой требуются известные танцы с бубном. Как выйти из данной ситуации?
Предложения вынести /boot а потом восстанавливать только его считаю полумерой. Это конечно сэкономит немного времени, но не решит вопрос принципиально.
потому, что нормальный софт-рейд делается в mdadm. и /boot заворачивается в массив. А grub-install делается и на sda и на sdb
Можно поподробней, лучше ссылку на какую нибудь статью.
Если я правильно понял, то вы предлагаете каждый из дисков массива сделать загрузочным.
man mdadm и гугл. Установка (ваш дистрибутив) на raid — но по запросам в гугле читать вдумчиво и понимать что происходит. Иначе получится от васяна инструкция, которая приведет к проблемам.
Только ESP сам по себе, раздел с системой в RAID1. grubx64.efi этот бутерброд нормально загружает.
С бтрфс не пробовал, но вроде как grub умеет с неё запускаться.
Соответственно тебе надо иметь два диска с бтрфс, /boot так же можно держать на нём.
На оба диска тебе нужно сделать граб-инсталл. Далее убеждаешься, что твой бтрфс не сдохнет без одного из дисков, выбором загрузочного диска убеждаешься, что грузится с каждого из дисков и спишь спокойно.
Если /boot на бтрфс не приемлем, то просто делаешь из него mdadm raid1, ну и grub2-install на оба диска.
Если у тебя efi, то тебе понадобится фат32 раздел для загрузки. Можно его установить на mdadm raid1 с metadata=0.99(емнип). У меня так работает, всё зеркалируется, проблем не замечено.
Наверное я не правильно выразился в 1 посте.
Под /boot я понимаю то место, куда bios передает управление. И он тоже должен быть на RAID.
Раздел с отдельным ESP это полумеры. По mdadm, я так понял что софт рейд работает с разделами дисков, что подразумевает наличие «таблицы разметки» которая не будет входить в результирующий RAID. Если я не прав то пожалуйста поправьте. Если прав, то это тоже полумера.
Если я правильно понял, то у тебя btrfs в raid1, созданная сразу на всём диске, вообще без таблицы разделов. Так?
А твой бивис может загрузить ось с диска вообще без разметки? Я не проверял, но всегда сомневался, что кто-то так может.
Опиши в чём проблема, что у тебя сейчас не получается. А то непонятно.
Мне нужно некое понимание способов решения проблемы когда бивис должен видеть несколько физических HDD как один логический. При этом физические HDD должны объединяться в логический так как я захочу(raid1,raid0,raid10. ). А уже поверх этого логического диска накатывается таблица разделов и файловая система. Причём уже не важно какая.
По mdadm, я так понял что софт рейд работает с разделами дисков, что подразумевает наличие «таблицы разметки» которая не будет входить в результирующий RAID. Если я не прав то пожалуйста поправьте.
Полумер нет. mdadm работает с разделами, которые ты на диске создаешь руками. Перед заменой диска в массиве разметка диска — твоя проблема, остальное делает мдадм. Ты можешь даже на одном диске рейд любого уровня собрать — твои проблемы. Ногу прострелить мдадм не запрещает.
Давайте договоримся о понятиях.
Я предлагаю называть полумерой все решения при которых не зеркалируется или не используется какая либо часть диска. В том числе и таблица разметки.
Из остального, ваш вариант и вариант Ivan_qrt наиболее интересны, но не на столько что бы мне менять ради них свою систему. Раз в 5 лет я в состоянии убить час времени на то что бы восстановить из дампа свою систему.
Подписался. Интересно, это виртуал или нет?
Мне нужно некое понимание способов решения проблемы когда бивис должен видеть несколько физических HDD как один логический.
Только аппаратный рэйд. Других вариантов нет. Бивис всегда видит hdd, подключённые к мамке, как hdd.
А уже поверх этого логического диска накатывается таблица разделов и файловая система. Причём уже не важно какая.
Имхо ты делаешь что-то не так. Зачем тебе это, опиши задачу.
Так может рейд и не нужен?.
Давайте вы поймете, что рейд никак не средство от бэкапа, а всего лишь средство резервирования оборудования. И наличие рейда не отменяет необходимость бэкапов. Это во-первых. Во-вторых, даже с аппаратным контроллером нужно зачастую инициализировать новый диск в массив. Считайте http://avreg.net/howto_software-raid-replacing-faulty-drive.html платой за неиспользование аппаратного контроллера. Я не буду сейчас углубляться в то, что есть рейд на материнках, разъяснять все нюансы и т.п., я просто поясняю, что подход о полумерах несколько не верен. Нужно исходить из задачи. Полной автоматизации даже крутые контроллеры зачастую не дают.
Он хочет от софтового рейда такого же удобства как на аппаратном контроллере.
Имхо софт рэйд в удобстве может не уступать аппаратным решениям.
Если очень не хочется создавать таблицу разделов самому, и добавлять разделы в рэйд, то можно и скрипт на 10 строк наваять, а можно даже над правилом для удава подумать, которое будет автоматом новые винты в raid добавлять (в качестве hot spare или восстанавливать, если деградировал).
Только вот нах это надо не понятно, ибо раз в несколько лет можно и руками за пару минут всё необходимое сделать (за синхронизацией же необязательно наблюдать).
Ну правило для удава — перебор, там надо столько костылить шопипец. А 6 команд можно сделать моментально, потому такой автоматизации и нет — она не нужна.
Как таковой задачи нет.
Некогда n лет назад, я купил себе HP Microserver, для хранения мультимедийного контента в домашней сети. В этот сервер я напихал 5 дисков. 1 на 250Gb и 4 на 3Tb, поскольку работать со зверопарком физических дисков нет особого желания, то встал вопрос объединения этого хозяйства в логические массивы. 1 диск на 250Gb остался системным, остальные объединились в raid10. Технологии объединения в raid выбирал из mdraid+lvm, dmraid, btrfs. Выбор пал на btrfs (не надо холиваров, просто захотелось посмотреть). Массив пережил не один диск, менял 3 или 4, полет нормальный. На нем же хранится дамп системного диска, который уже тоже умирал. Сервер работает 24/7, поэтому скорость загрузки не критична. uptime где то 1,5 года.
Сейчас подумываю над увеличением размера raid массива, при этом в голову закралась мысль: — А почему бы не установить на него ОС? В этом случае появится возможность посмотреть фичу снапшотов, квот, чего там еще есть, а самое интересное горячее подключение системных дисков. Но бивис грузить систему с программного btrfs raid не умеет. Отсюда собственно и вопросы, кто как решал подобные задачи? Какие вообще есть технологии?
Предложенные вами варианты конечно более продвинутые чем мой, но не на столько что бы ради этого терять контент(
5Tb). Сам сервер относительно старый, uefi не умеет, загрузиться с диска gpt не сможет.
Мне этот пост скорее нужен как сбор информации о том как народ решает подобные задачи. Какие появились новые возможности и т.д. Может для моей хотелки проще сменить сервер и получить загрузку с btrfs raid из коробки, или купить недорогой raid контроллер.
Источник
Как загрузиться с RAID?
torm7 — что у тебя в итоге получилось?
У меня такой же вопрос.
Если mdadm, то есть на самом деле модуль md в ядре представляет пару дисков как устройство /dev/md/N, то пусть и продолжает представлять и обеспечивать посекторное копирование RAID 1.
BIOS грузит MBR, MBR грузит core.img от GRUB, записанный в BIOS-partition от GPT, этот core.img несёт в себе поддержку RAID, GPT, LVM и грузит всё остальное (grub.conf, kernel, initramfs) с основного раздела на GPT.
Дальше ядро запускает модуль md, (не знаю, что там про GPT) и поддержку LVM, после чего монтирует корневой раздел.
В случае выхода из строя диска это тоже всё наверное продолжит работу. Однако синхронизация будет выполняться для массива и закопирует как MBR, так и всё остальное.
Что скажете, непонятливые читатели ЛОРа, так и не смогшие ответить на простой вопрос два года назад?
Нуууу и в чём проблемы?
хочется подтверждение «да, у меня именно так и работает и я удачно пережил 6 лет и четыре отказа дисков»
Пережил без даунтайма по причине отказа дисков или без потери данных?
Но могу спросить и конкретнее:
mdadm создаёт свои таблицы версии 1.2 во втором секторе (т.е. начиная с 4096 байта диска)
в то же время, BIOS partition у GPT начинается так же где-то в том же районе (и туда записывается core.img)
Произойдет ли наложение второго на первое или нет?
UPD:
https://en.wikipedia.org/wiki/BIOS_boot_partition
или наложение Partition Entry Array на метаданные v1.2 от MDADM
Без даунтайма и потери данных
Вот чтоб совсем без даунтайма небыло. Нам не нужно и не по карману. Спокойно штатно остановили, заменили неисправное оборудование, запустили, подождали, проверили. На горячую, по живой системе никто не проверял, т.к. потребности нет.
ок, с какого места диска начинаются метаданные GPT?
Они в конце диска записываются.
Почитай хотя бы Википедии.
почитал. Для версии 1.2 они записываются не в конец. Сам почитай хотя бы.
Знаешь, теперь я начинаю сомневаться, что у меня было именно так, как ты описываешь, то ведь было несколько лет назад. У меня совершенно точно было без GPT, только mbr-таблица разделов. И еще использовался старый gurb, не тот, который grub2.
По идее, с EFI тебе grub в принципе не обязателен, прошивка может сама загрузить ядро и initrd ESP-раздела первого попавшегося диска, а ядро уже само соберет рейд когда все загрузится.
А еще сейчас можно заказать нормальный, пусть и устаревший, рейд-контроллер LSI за недорого, и забыть про все эти приключения.
нет, мне хотелось бы, чтобы на ЛОР начали нормально отвечать на вопросы или проходить мимо.
Если спрашивают про BIOS, то чтобы не предлагали UEFI. Если спрашивают про GPT, то чтобы не предлагали обойтись одним MBR (а то диски бывают 3Tb, а MBR не умеет >2TB)
сейчас можно заказать нормальный, пусть и устаревший, рейд-контроллер LSI за недорого
отлично, заказываю за твой счёт. Высылай. Доставка тоже за твой счёт. Ну и просто денег тоже можешь подарить, я не гордый.
У тебя такие вопросы, что из них непонятно, что ты спрашиваешь. Спрашивай нормальные вопросы, на лоре не техподдержка фирмы-производителя твоего сервера. Если ты упоминаешь gpt, я по-умолчанию предполагаю, что у тебя efi. Если же это не так, надо подробно расписать, что как и почему, а не выдавать не фильтрованный поток сознания, как в ОП.
Если же это не так, надо подробно расписать
в топике Torn7 используется BIOS и 3Tb диски. У меня тоже. Я бы мог в тот топик дописать, но он уже архивирован, поэтому я сделал новый и сослался на старый.
mdadm создаёт свои таблицы версии 1.2 во втором секторе (т.е. начиная с 4096 байта диска)
У тебя целиком диск отдан под рейд, или все таки раздел? Во втором случае mdraid пишет метадату в начало раздела, а не диска, и никто никуда не наложится.
У меня пока ничего нет. Я размышляю, как сделать. Хочу RAID делать на целиком диски. Это позволит их целиком восстанавливать/синхронизировать.
Поэтому второй случай мне не подойдёт.
Я лучше от GPT тоже откажусь, диски возьму поменьше. А затем помучаюсь и подумаю, как сдвинуть core.img при установке (чтобы не накладывался на метаданные от mdadm)
Вообще так рекомендуют не делать. Но в таком случае тебя не должна волновать судьба mbr/gpt.
Ну как минимум, Torn7 говорит о btrfs raid, а ты про mdraid, что есть немного разные сущности. mdraid это, фактически, надстройка над обычными block devices, а btrfs raid реализован в драйвере файловой системы btrfs.
С 1.2 сомневаюсь, надо, чтобы метаданные в конце диска были. А это 0.9/1.0. И, может, ещё какое-то шаманство.
да, я не хочу btrfs, я хочу mdadm (а не dmraid). mdraid — это по-видимому подсознательный результат скрещивания двух предыдущих.
не, а чего? Сначала разметить диск в GPT, это позволит записать core.img не с начала диска. Потом разметку GPT затереть (но MBR и core img останется. В MBR прописать раздел такого же размера, как был на GPT. После этого метаданные mdadm 1.2 записать.
Либо, как вариант, вообще не записывать метаданные mdadm на диски. Перестанет работать автособирание в initramfs, но это можно обойти, если всё что нужно написать в mdadm.conf в initramfs
mdraid довольно часто употребляемое наименование которое встречается даже в документации, т.к. mdadm (Multiple Disk ADMinistrator) это всего лишь название утилиты управления.
В данный момент, мне видится, что вариант с mdadm.conf в initramfs более живучий в том случае если через много лет что-то все-таки пойдет не так и тебе понадобится разбираться в этом заново. Во всяком случае, не надо будет вспоминать, что ты там стирал и перезаписывал. Но имеет смысл смоделировать ситуацию на кошках (виртуальных машинах).
для тех, кто найдёт этот топик через поисковик
не парьте мозг — бут раздел на флешку (если не хочется тратить винт и занимать порт), а с него можно грузить какой угодно рейд, и в случае смерти рейда иметь живой бизибокс для базовой диагностики.
ага, и следующий вопрос — как сделать RAID из флешек
ага, и следующий вопрос — как сделать RAID из флешек
Рейд из флешек грузить с сервера по сети. На серверах сетевой загрузки рейд не делать, а просто иметь их три. 😀 Еще, конечно же, надо продублировать весь сетап в 5 датацентрах на 5 континентах. И криптографию на торсионных полях. Вроде ничего не забыл. стандартный набор ЛОРовца, каждый должен знать!
На серверах сетевой загрузки рейд не делать
Я думаю, если я начну отвечать на этот вопрос, то тред сорвется в лютый оффтоп, по этому оставим как есть.
вот, разумных причин у тебя нет, только люто оффтопичные.
а мог бы привести сравнение/подсчёт TCO различных вариантов
Эталонный изврат. Берем дисковый массив, предполагающий надежность. Извращаемся над ним, чтоб эта надежность не имела значение. А имели значение всякие bios, gpt, mbr, grub. Но не надежность массива. Ни в коем случае. Хоть бы заикнулся про память с контролем четности для софт-рейда. Нет важен куда запишется какой-то core.img
ты так говоришь, как будто сейчас начнёшь за zfs против mdadm агитировать.
И чем поможет zfs при описанных тобой извратах? Ты эталонный извращенец. Сперва ответь, зачем тебе raid1? Чтобы с него грузиться? Raid1 не загрузчик.
По-моему, должно быть совершенно очевидно, что я намерено предлагал совершенно абсурдный вариант. Не вижу смысла заниматься подсчетами в данном случае.
чтобы если флешка откажет, вынуть её, вставить другую, а система сама бы всё восстановила.
ну я пережил уже вторую замену пар, последний раз перешел на гпт и груб2, как раз спрашивал про легаси, но никто не отозвался. решил сам, да диски 3тб корень в райде. могу завтра глянуть
ТС хочет не просто корень в рейд, а весь накопитель зеркалировать, в месте с таблицей разделов, загрузочной записью и прочим. Но если у тебя именно так, очень интересно послушать. Я тут внезапно понял, что в 11 году какую-то херню сделал, которая работала совсем не так, как я думал, но при этом вела себя как ожидалось.
тыж понимаешь, что так нельзя в прямом смысле сделать. скопировать таблицы, поставить груб2 прямо на райд, не забыть про раздел костыль, чтоб загрузиться из биос, вот так можно
Что ты хочешь восстановить? Восстанавливают из бекапов. Сделай себе 100500 загрузочных дисков/флешек и вставляй их по мере необходимости. Raid не про восстановление. Хватит уже извращаться.
одну половину RAID-а с другой.
тебе хватит, ты и переставай
Сделай себе 100500 загрузочных дисков/флешек
Их изготовление — 100500 операций, более сложных, чем «вставить чистую флешку в разъём»
так все же опиши, что за радость синкать загрузочник и таблицу разделов? все это востанвливается парой команд с живого диска
одну половину RAID-а с другой.
Он это сделает. Но ты же хочешь совсем другого?
тебе хватит, ты и переставай
Я извращаюсь, потому что с извращенцем общаюсь. С волками жить — по волчть выть
Что скажете, непонятливые читатели ЛОРа, так и не смогшие ответить на простой вопрос два года назад?
Что тебе стоит научится описывать свои мысли более внятно.
Я правильно понял, что ты хочешь сделать рэйд целиком на весь диск, без разметки. Но при этом переживаешь, что метаданные рэйда затрут mbr?
Тут остаётся только проверить. Вряд ли кто-то, кроме тебя решит заниматься таким извратом. Так что всё в твоих руках. Большинству людей сделать
По поводу хитрых планов. Когда у тебя откажет диск, тебе придётся много плясать с бубном, если у тебя не будет возможности сделать grub2-install /dev/sdX . Так что если рэйд без разметки конфликтует с mbr, то лучше откажись от этой затеи.
почему тебе так показалось?
Я хочу, чтобы RAID, созданный из всего диска (флешки), восстановил свою половину целиком (т.е. отказавшую флешку).
ты хочешь сделать рэйд целиком на весь диск
почему без разметки? Тут неоднозначно у тебя написано. Диск у меня с разметкой, только RAID не на отдельный раздел, а на диск целиком.
Но при этом переживаешь, что метаданные рэйда затрут mbr?
нет, не mbr, почитай повнимательнее.
Сначала разметить диск в GPT, это позволит записать core.img не с начала диска.
Под core.img что подразумевается? stage1.5? Он и так не в начале диска. А если под core.img подразумевается mbr, то она обязана быть в начале диска, иначе биос её не прочитает.
Либо, как вариант, вообще не записывать метаданные mdadm на диски.
А куда ты их собрался записывать? Выносить на ещё один диск? В чём смысл?
Под core.img что подразумевается? stage1.5?
верно. Но и метаданные mdadm тоже не затирают mbr. Они как раз с core.img за одно место дерутся.
А если под core.img подразумевается mbr
MBR обязана быть в начале диска, иначе биос её не прочитает.
верно, но нерелеванто
как вариант, вообще не записывать метаданные mdadm на диски.
А куда ты их собрался записывать?
в mdadm.conf в initramfs, выше это написано.
Если использовать by-path указание дисков, то менять/редактировать mdadm.conf будет не нужно.
Хочу чуть поправить себя. Raid1 не восстанвливает свою вторую половину. Он восстанавливает свое нормальное рабочее состояние из ненормального сломанного состояния. Хочеть быть нормальным, не извращенцем. Нормальные ждут от другого нормального поведения, это есть надежность. То что кто-то снаружи выводит его из нормального состяния, извращается, и при этом требует нормальное поведение — это уже совсем не про надежность. Только по случайному стечению обстоятельств извращение может выглядет как нормальное поведение.
кто-то снаружи выводит его из нормального состяния
энтропия, сынок. Ничего личного
почему без разметки? Тут неоднозначно у тебя написано. Диск у меня с разметкой, только RAID не на отдельный раздел, а на диск целиком.
Ну тут либо у тебя на диске разметка, либо рэйд. Два в одном не получится. Если ты имеешь ввиду, что на /dev/mdX ты сделаешь разметку или lvm, то это к загрузке уже не особо относится.
Они как раз с core.img за одно место дерутся.
Я могу заблуждаться, но вроде как stage1.5 пишется либо в bios boot partition (если у тебя gpt), либо в /boot, если mbr. Учитывая, что у тебя ни того, ни другого, весь вопрос в том, как себя поведёт grub-install.
Если поверх /dev/mdX ты создашь gpt, то создай на нём bios boot partition поближе к началу диска. stage1.5 запишется в него, для mdadm это будет валидный раздел, который будет зеркалироваться и не будет затираться метаданными.
Дальше делаешь grub-install на все диски, и загрузчик в mbr будет содержать offset для stage1.5. По идее так должно работать. От grub-install при восстановлении ты не избавишься, но разделы он зазеркалирует, да.
Если поверх /dev/mdx будет mbr, то создай раздел под /boot в начале диска. Остальное тоже самое.
С lvm видимо тоже самое, но в том, что grub-install не сойдёт с ума, я не уверен. Возможно придётся руками mbr писать.
в mdadm.conf в initramfs, выше это написано.
Если использовать by-path указание дисков, то менять/редактировать mdadm.conf будет не нужно.
А где рэйд будет хранить инфу о своём состоянии? Метаданные это же не только UUID’ы дисков и тип рэйда, но и журнал.
Источник
