потому, что нормальный софт-рейд делается в mdadm. и /boot заворачивается в массив. А grub-install делается и на sda и на sdb

man 4 md

Можно поподробней, лучше ссылку на какую нибудь статью.

Если я правильно понял, то вы предлагаете каждый из дисков массива сделать загрузочным.

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. Если я не прав то пожалуйста поправьте.

RTFM

Полумер нет. 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 контроллер.

Систему можно грузить с btrfs-raid, а вот ядро уже не получится, нужен отдельный boot

Тут есть такая проблема:

1) grub2 иногда пишет состояние в /boot/grub2/grubenv

2) grub2 не умеет писать в рейд.

Тут всё довольно просто и можно обойтись без потери данных. Наверное, ибо на бтрфсе не проверял.

Тебе надо

• взять свой готовый рэйд на btrfs
• создать на нём subvol под корень
• перенести туда свою систему
• сделать chroot в новую систему
• сгенерировать новый grub.conf и fstab
• убедиться, что прописываются правильные параметры ядра (то, что нужный subvol передаётся в качестве root, гугл знает, как должно быть, я уже не помню)
• установить на каждый диск grub2-install
• всё проверить, убедиться, что грузится деградированным, убедиться что может загрузиться с любого диска и т.п. В общем 100500 перезагрузок.

По идее должно работать вообще без всяких таблиц разделов, просто с винтами, напрямую отданными btrfs. Но только если граб так умеет. Возможно, в этом случае grub.conf придётся править руками, если скрипты такую конфигурацию не осилят.

Ну и для надёжности лучше сделать subvol под /boot и сделать его зеркалированным на каждый диск, ибо есть сомнения, что граб сможет загрузиться с деградировавшего массива со stripe'ом. Хотя вполне вероятно, что они напрасны.

В общем, т.к. конфигурация не стандартная, можно наступить на много граблей, но в теории всё это возможно, и кроме багов, препятствий не видно. Ну и в случае проблем всегда можно вернуться на оригинальную систему на отдельном диске.

Систему можно грузить с btrfs-raid, а вот ядро уже не получится, нужен отдельный boot

А почему, можно по подробнее? У граба же есть поддержка бтрфс.

По идее потеря grubenv не очень страшна.

И, вроде как, его вообще можно удалить или не использовать.

Ну и если с бтрфс по каким-то причинам не взлетит, а желание что-то сделать останется, всегда можно

• вывести два диска из бтрфс
• сделать на них таблицу разделов (/boot, efi(если надо), root, data), разделы fd00
• создать деградированные рэйды на 4 устройства (boot и efi имхо лучше делать как raid1, а не raid10, для efi нужна metadata=1.0, а не стандартная 1.2)
• примонтировать, скопировать систему
• chroot и grub2-mkconfig
• отредактировать fstab
• установить grub2 на оба диска
• всё проверить, ребутнуться, убедиться, что грузится с обоих выведенных дисков
• примонтировать btrfs в новой системе, поставить копирование на ночь
• когда всё скопируется, создать новую разметку на оставшихся дисках
• добавить их в массивы
• установить на них граб
• после окончания синхронизации получить работающее более-менее отказоустойчивое хранилище
• по желанию можно сделать ещё 100500 перезагрузок с целью всё проверить
• настроить оповещения
• спать спокойно

Такую схему проверял, и даже не раз. Тут граблей нет.

Вполне возможно, что сервер поддерживает intel matrix storage manager (imsm) raid, он же intel rapid storage technology (rst) raid, и умеет грузиться с массива. Тогда с помощью mdadm можно создать контейнер типа imsm на все диски, затем в этом контейнере создать два массива, один для загрузки (меньше 2 тб), второй для хранилища. На первом массиве можно будет создать таблицу разделов MBR. На втором массиве можно создать таблицу разделов GPT. Можно и не создавать разделов на втором массиве вовсе, использовать его без разделов как физический том BTRFS или LVM.

способов решения проблемы когда бивис должен видеть несколько физических HDD как один логический. При этом физические HDD должны объединяться в логический так как я захочу(raid1,raid0,raid10...).

Это уже аппаратный raid.

Подведу промежуточный итог обсуждения

Как я понял из обсуждения, есть 2 варианта решения проблемы: soft, hard.

В soft варианте:

• MBR. На каждый из дисков массива устанавливаем устанавливаем grub, который будет загружать ядро из раздела /boot который уже должен находиться в массиве raid (mdraid, btrfs raid). MBR на всех дисках должен передавать управление в одно и то же место, для того что бы в BIOS можно было выставлять в качестве загрузочного любой диск. Физический объем одного диска не может быть > 2Tb.
• UEFI. На каждом диске массива создается раздел ESP одинакового размера который будет загружать ядро из раздела /boot который уже должен находиться в массиве raid (mdraid, btrfs raid). Разделы ESP должны быть настроены одинаково, что бы не было сюрпризов при загрузке с разных разделов. Физический объем одного диска может быть > 2Tb.

Общим в этих системах является то что в ручную надо следить за состоянием mbr/esp и своевременно обеспечивать их синхронизацию между собой, т.к. bios может передать управление только одному устройству из массива.

В hard варианте:

• Диски подсоединяются к серверу через контроллер, который делает из дисков raid массив, а в bios предоставляет нарезку этого массива как самостоятельные диски.

Плюсом hard варианта является полноценная реализация raid, но привязываешь свою жизнь к конкретной железке. Плюсом soft варианта является простота переноса, дешевизна. Но он не дает полноценного решения. Надо заморачиваться с синхронизацией загрузчиков на устройствах.

На моем сервере soft вариант не подходит. В mbr варианте лишусь 1/3 объема массива. В uefi варианте не смогу загрузиться с него т.к. bios не умеет. Остается либо hard либо менять сервер.

Как я понял из обсуждения, есть 2 варианта решения проблемы: soft, hard.

Как я понял, ты ни хрена не понял, и написал какую-то фигню (про soft raid).

Физический объем одного диска не может быть > 2Tb.

Что мешает разбить диски на gpt? Его не умеют только самые древние биосы, и то с bios boot partition, возможно умеют.

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

Если /boot-раздел у тебя будет зеркалироваться, то у тебя так и будет, просто потому что по другому не получится. Но откуда такое требование взялось нихрена не понятно. Bios будет передавать управление загрузчику с того же диска, с которого считана MBR. Передать управление на другой диск формат MBR не позволит.

Общим в этих системах является то что в ручную надо следить за состоянием mbr/esp и своевременно обеспечивать их синхронизацию между собой, т.к. bios может передать управление только одному устройству из массива.

Ты то, что я писал про об объединении efi-разделов в raid с metadata=1.0 не прочитал, или не понял? В mbr-варианте ты зачем собрался следить вручную? Что у тебя там так внезапно может поменяться-то? Ничего, и нигде тут вручную «синхронизировать» не надо.

Судя по всему у тебя какие-то предрассудки в голове засели, от которых ты никак не хочешь избавляться.

Ок. Объясни тогда куда биос передает управление.

В моем понимании для hdd это происходит так: В случае mbr: БИОС в чипе передает управление выбранному устройству в первый сектор. От туда управление передается на указанный там загрузочный раздел, где установлен grub. grub начинает загрузку linux или передает управление дальше. В случае uefi: БИОС в чипе передает управление выбранному устройству в специальный раздел EFI. Там находятся разные загрузчика grub, lolo, win... Если в качестве умолчательного стоит grub то он либо начинает загрузку linux либо передает управление другому загрузчику.

Ты как это понимаешь?

Сам сервер относительно старый, uefi не умеет, загрузиться с диска gpt не сможет.

Так он не обязан иметь EFI, чтобы уметь грузить GPT.

Объясни тогда куда биос передает управление.

grub > bios_grub (non-fs partition) > ...
Тут довольно подробно расписано: http://www.wensley.org.uk/gpt

БИОС в чипе

Что это такое?

https://wiki.archlinux.org/index.php/GRUB_(Русский)#.D0.97.D0.B0.D0.B3.D1.80....

В случае загрузки с gpt происходит следующее:

На первых секторах диска располагается mbr - master boot record. Что на gpt, что на mbr. Это небольшая запись с кодом и данными - минимальный загрузчик. Биос загружает его. Этот минимальный загрузчик записывается на диск при grub2-install. Этот минимальный загрузчик передаёт управление grub stage1.5 (или 2), который, как правило, расположен на bios boot partition (так же устанавливается во время grub2-install). Stage 1.5 читает твой /boot, грузит полноценный граб, рисует менюшку, передаёт управление выбранному ядру или другому загрузчику. В большинстве случаев биосу вообще не важно, какая на диске разметка, и есть ли она вообще. Он читает только первый сектор, проверяет, что он загрузочный и грузит. Дальше не его проблемы.

В случае загрузки с uefi:

Uefi читает разметку твоего диска, находит на нём esp раздел (ef02 раздел с fat32), находит на нём все исполняемые файлы в формате PE, в зависимости от настроек выбирает нужный файл и передаёт управление ему. Это может быть grub, это может быть ядро, подготовленное специальным образом, это может быть любая хрень, способная загрузиться на голом железе (efi-приложение).

При этом у тебя в soft raid надо руками следить за grub stage1 и grub stage1,5 на каждом физическом диске? Или у тебя этим raid занимается? Если нет, то именно это я и имел в виду что Общим в этих системах является то что в ручную надо следить за состоянием mbr/esp и своевременно обеспечивать их синхронизацию между собой, т.к. bios может передать управление только одному устройству из массива

Что это такое?

Под «БИОС в чипе» я понимаю ту часть, которая находится в чипе, который впаян в материнскую плату.

Про ESP раздел не понял. То есть ты хочешь сказать что ESP раздел может находиться в RAID массиве? Как же тогда он получает управление? Или в «БИОС в чипе» есть понимание mdraid, или он получает управление не от туда.

Я правильно понимаю что понятие «файловая система» впервые появляется в grub stage1,5?

При этом у тебя в soft raid надо руками следить за grub stage1 и grub stage1,5 на каждом физическом диске?

За чем именно ты собрался следить? Каждый день с утра проверять неизменность порядка байтиков, или что? Ты один раз делаешь grub2-install на каждом диске и всё. Больше не за чем следить не надо.

Про ESP раздел не понял. То есть ты хочешь сказать что ESP раздел может находиться в RAID массиве?

Да, именно это я и сказал. Но metadata должна быть 1.0.

Как же тогда он получает управление?

Если ты попытаешься прочитать то, что тебе пишут, то увидишь, что esp-раздел не получает управление. Это всего лишь раздел с fat32, а не исполняемый код.

Или в «БИОС в чипе» есть понимание mdraid, или он получает управление не от туда.

Есть биос, а есть uefi. Это две различные вещи. У биоса нет понимания вообще ни о чём. Он просто читает первый сектор диска и запускает код, находящийся в нём. На всё остальное ему насрать.

Uefi ищет помеченные ef02 разделы, и пытается прочитать их как fat32. Про рэйд оно ничего не знает. При metadata 1.0 данные о рэйде расположены в конце раздела, поэтому для uefi такой esp раздел выглядит как обычная файлуха.

Я правильно понимаю что понятие «файловая система» впервые появляется в grub stage1,5?

Гарантию не дам, но судя по всему да.

Если ты попытаешься прочитать то, что тебе пишут, то увидишь, что esp-раздел не получает управление. Это всего лишь раздел с fat32, а не исполняемый код.

Вот теперь вообще все перестало быть понятным, нафига он тогда нужен, если управление он не получает, в загрузке не участвует? У меня в голове стойко сидит мысль что uefi это просто способ загрузки ПК при котором «БИОС в чипе» имеет понятие о том что такое gpt, fat32, находит раздел ef02 и передает туда управление, где уже находятся всевозможные газрузчики ОС grub, ntldr, elilo...

facepalm.efi

Выбей неправильную мысль из головы и удосужься уже прочитать документацию. За то время, которое ты потерял в данной теме, ты мог бы уже несколько раз перечитать всё, связанное с загрузкой Linux на PC.

Какую?

man mdadm, например. Советовали же, емнип, выше по треду.

Или что-нибудь из этого, если документация слишком сложная.

И где там написано то что я спрашиваю?

Вот теперь вообще все перестало быть понятным, нафига он тогда нужен

Я не вижу смысла писать повторно то, что уже написано в этом треде. Перечитай хотя бы его. Здесь вполне ясно описано, зачем уефи нужен esp-раздел. И выкинь из головы неправильную терминологию.

Если будет всё ещё непонятно, то почитай арч-вики про граб. Ссылка в треде. Будут конкретные вопросы - задавай.

Совсем народ обленился. Тебе, как тому chukcha, тоже просто поныть захотелось?

Читай про mdadm, чтобы создать нужную структуру raid, читай про grub, чтобы сделать этот raid загрузочным.

Там несложно. Я осилил 5 лет назад.

На каждом диске массива создается раздел ESP одинакового размера

На разделе (по крайней мере в debian) лежит только файл grubx64.efi. Ядро и прочие кишки grub лежат уже в /boot на массиве. По уму надо прописать оба раздела в NVRAM, чтобы в случае краха первого диска загрузка пошла со второго пункта.

Ну это с моего дивана так видно. По уму надо хотя бы на виртуалке потыкать такой сценарий, не смотря на всю глючность её BIOS.

Тред не дочитал. Гружу пару серверов с USB-flash, соответственно, куда покласть /boot вопроса нет. Тем более, в HP DL-380 на плате распаян аккуратненький USB-разъём, а его высоты в 2 юнита хватает, чтобы воткнуть большинство флэшек.