Вопрос по организации RAID-массива для десктопа на Debian

По спецификации ESP раздел доступен на запись, это не самоуправство. В т.ч. там могут храниться настройки на системах без nvram. Нельзя рассчитывать на то, что EFI никогда ничего не запишет на системный раздел. Моя материнская плата, например, умеет сохранять бэкап настроек на esp.

RAID1 нужен для дублирования диска

т.е. для всех ssd в массиве будет одинаковый TBW?
и при достижении soft-kill value в прошивке по лимиту TBW в потребительских ссд накроется весь массив синхронно?

К вопросу о ESP на двух накопителях. Я на десктопе использую два независимых, чтобы не синхронизировать ошибки и иметь независимые ФС. Старое ядро UKI копируется на резервный перед установкой нового, и фирмварь видит их все:

→ cat /etc/fstab 
# /dev/nvme?n1p1
UUID=A...  /boot/efiback                   vfat  noauto   0 0
UUID=F...  /boot/efi                       vfat  defaults 0 0

→ cat /etc/kernel/install.d/05-sync-efiback.install 
#!/bin/sh
VERB="$1"
ESP=/boot/efi
BACK=/boot/efiback

if [ "$VERB" = "add" ] && mountpoint -q "$ESP" && mount "$BACK"; then
    rsync -a --delete "$ESP"/ "$BACK"/
    umount "$BACK"
    echo "Backup $ESP to $BACK ✔"
fi

Через хуки в grub можно так же на более традиционной системе.

Через хуки в grub можно так же на более традиционной системе.

https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

https://web.archive.org/web/20260418234940/https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

Даже если это и произойдет, регулярный scrub это разве не отловит?

собери в raid1 nvme и hdd - получишь скорость nvme и надежность hdd :)

у меня такое с флагом writemostly на hdd - и на вызовах sync оно естественно жёстко тупит, хорошо видно по работе кеша браузера.

Чтение - да, отличное.

на esp.

На какой esp, если в системе их несколько? Если прошивка платы пишет и читает настройки со случайно выбранного раздела, ну удачи с такой платой. А если плата пишет только на один (первый, чтобы это не значило) esp-раздел, то собираем raid1 и второй раздел объявляем write-mostly. Да, настройки на второй ESP просто так не скопируются, изредка нужно будет делать синхронизацию, но косяков с ФС не возникнет.

что EFI никогда ничего не запишет на системный раздел.

Но, какие бы данные она туда не записала, — это не критичная для работы системы информация, отвал накопителя не приводит к смерти материнки. И плата должна туда не просто что-то записать, а записать так, что потом, при записи из Линукса, при обновлении загрузчика, скрашится ФС и EFI не сможет с этого ESP старатнуть систему.

P.S. RAID не подразумевает, что сегодня один дейвайс отвалился, а завтра снова заработал и т.д. Умер — значит умер и нужно разбираться. Это на случай, если вы там какие-то сценарии начнёте описывать, когда эта схема с write-mostly не сработает.

Вот фрагмент man mdadm, переведённый ИИ:

"-W, --write-mostly

Последующие устройства, перечисленные в команде --build, --create или --add, будут отмечены как ‘write-mostly’. Это применимо только для RAID1 и означает, что драйвер ‘md’ будет избегать чтения с этих устройств, если это возможно. Это может быть полезно при зеркалировании через медленную связь.

--write-behind=

Укажите, что режим write-behind должен быть включен (применимо только для RAID1). Если указан аргумент, он установит максимальное количество ожидающих записей, допустимых. Значение по умолчанию равно 256. Для использования режима write-behind требуется битовая карта намерений записи, и write-behind выполняется только на устройствах, отмеченных как write-mostly."

Вот выдержка из старого документа
RHEL 6 LVM Administrator Guide от 2020-08-18, переведённая ИИ:

"Вы можете управлять операциями ввода-вывода на логическом томе RAID1 с помощью параметров --writemostly и --writebehind команды lvchange.

--[raid]writebehind IOCount

Задает максимальное количество ожидающих записей, которые разрешены для устройств в логическом томе RAID1, отмеченных как write-mostly.

После превышения этого значения записи становятся синхронными, что приводит к тому, что все записи на составляющие устройства завершаются перед тем, как массив сообщает о завершении записи.

Установка значения в ноль очищает предпочтение и позволяет системе выбирать значение произвольно."

В приципе, mdadm и lvm2 как более высокоуровневые командные интерфейсы, сейчас используют одни и те же возможности ядра.

Т.е. на raid1 (nvme + hdd) можно регулировать: если записи не слишком интенсивные, то коммит опрации идёт на nvme, и только потом в фоне идёт синхронизация на hdd.

Проблема не в записях как таковых. Если медленно пишется - может полежать в памяти, в том числе на очереди на запись и тут не важно это очередь на блочное устройство md целиком, или где-то внутри его реализации в очереди записи на более медленное устройство.

Проблема в sync, кототорый любят делать приложения когда работают с sqlite или подобным.

mdadm + LVM + ext4

первый компонент лишний. lvm raid (можно на уровне разделов, а не диска) хватит по уши. при подыхании одного из двух устройств можно тупо сконвертить оставшийся том в линейный и пользоваться до замены сдохшего.

ну, и бэкап на отдельном hdd (usb или nas) не помешает, на самом деле. у lvm до сих пор бывают неприятные косяки (в последний раз это было разпердоливание фс при попытке снапшота кэшированного диска).

думаю для raid1 что mdadm, что lvm одинаковы и да после геммороя с аппаратными я онли софтовые использую. (я бы lvm использовал он гламурнее удобнее)

Для raid0 mdadm был гораздо быстрее lvm (на 2011год) и лучше для ssd, ибо lvm заполнял по очереди один диск и только потом второй изнашивая ssd (не оставляя свободное место на диске) не получая профита от чтения по двум дискам.

я бэкаплю (кривой самоделкой Rsync по хрону менее пары минут в сутки) онли /home здорово экономит время на моих ляпах, да музыка, вынесена из /home, а всякие конфиги из /etc символические ссылки в /home.

Версионности в гит хватает. А для личных даных и настроек софта такого пока костыля хватает.

Не конструктивно. Бэкапить – это прошлвый век.

Бэкапить всё равно придётся. Как выше правильно сказали, от пожара, наводнения, скачка напряжения и вируса-шифровальщика рэйд вас не спасёт.

mdadm научили паралелить чтение с двух дисков в raid 1?