Кто виноват?

Разработчики системы инициализации :-)

Что делать?

Либо отказываться от внешнего bitmap, либо переделывать инициализацию. Если второе, то наврное проще всего собрать initrd без поддержки raid, в fstab поставить noauto и всю инициализацию raid'а делать из скрипта из /etc/init.d/.

Мой вариант - монтировать RAID автоматически по первому обращению с помощью autofs, если я не ошибаюсь, autofs развёртывается даже в минимальной инсталляции. В /etc/fstab /dev/md? вообще не добавлять, тогда система будет бутабельной энивей. Штатная инициализация говно очень негибкая и делать в ней что-либо не рекомендуется.

проще всего собрать initrd без поддержки raid, в fstab поставить noauto и всю инициализацию raid'а делать из скрипта из /etc/init.d/.

Такой вариант, признаться, приходил в голову, да и нагугливался. Но эти md0 и md1 представляют собой PV, на которых, помимо всяких образов ВМ, лежит ещё и /var/log (чтобы на SSD лишний раз не писать). Т.е. инициализировать RAID и LVM после монтирования ФС из fstab не вариант, как мне кажется.

монтировать RAID автоматически по первому обращению с помощью autofs

Там LVM с частью системных потрохов.

Штатная инициализация говно

Что-то в этом есть... Интересно, в хвалёном systemd всё так же хреново?

Там LVM с частью системных потрохов.

А я похоже ошибся, это всё равно бы не помогло вытащить bitmap. Ещё нужно как минимум, старт md откладывать на самый поздний этап, а не только одно монтирование.

В тему призываются Gotf и YAR.

Сравни производительность рейда с битмапом и без битмапа, а после выкинь битмап

А если сделать не файл в другой файловой системе, а выделенный раздел?

А как?

~$ mdadm --grow --bitmap=/dev/sde3 --force --bitmap-chunk=131072 /dev/md0
ftrunace: Invalid argument
mdadm: Cannot set bitmap file for /dev/md0: Invalid argument

Таки да, не хочет, хотя, казалось, как-то делал.

Тогда стоит разобраться с тем, почему у тебя ФС в RO при сборке массива. Отключить автосборку RAID'а в initrd, пусть собирается уже при старте основной системы; при необходимости - поправить порядок скриптов в /etc/rcS.d/

и raid собирается ro

Так он собирается или не собирается совсем? Если у меня bitmap на RO FS, то RAID не собирается вообще. Если ты про auto-read-only в /proc/mdstat, то оно меняется при попытке записи на массив.

root@elitebook:/home/rain# mount -o bind /bitmap /bitmap 
root@elitebook:/home/rain# mount -o remount,ro /bitmap
root@elitebook:/home/rain# > /bitmap 
bash: /bitmap: Файловая система доступна только для чтения
root@elitebook:/home/rain# mdadm -A /dev/md0 /dev/elvg/raiddev* -b /bitmap 
mdadm: cannot open bitmap file /bitmap: Read-only file system
root@elitebook:/home/rain# cat /proc/mdstat 
Personalities : [raid1] 
unused devices: <none>
root@elitebook:/home/rain# mdadm -A /dev/md0 /dev/elvg/raiddev* 
mdadm: /dev/md0 has been started with 2 drives.
root@elitebook:/home/rain# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active (auto-read-only) raid1 dm-7[0] dm-9[2]
      1048000 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>
root@elitebook:/home/rain# mount /dev/md0 /tmp/1/
root@elitebook:/home/rain# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 dm-7[0] dm-9[2]
      1048000 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Если bitmap за пределами массива, то можно считать, что не влияет. Если в суперблоке, то по-разному, вплоть до пренебрежимо малого. Тут многое зависит от параметров массива (особенно если это страйп) и планировщика I/O.

Тогда стоит разобраться с тем, почему у тебя ФС в RO при сборке массива.

boot.log при bitmap на монтируемой fs

boot.log при bitmap на корневой fs

Из лога видно, что система инициализации сначала собирает массивы, потом активирует менеджер томов, потом перемонтирует корневую ФС в режим чтения-записи, и наконец монтирует ФС из fstab.

Отключить автосборку RAID'а в initrd, пусть собирается уже при старте основной системы;

Копипаста выше - без /etc/mdadm.conf в initrd. С включенным в initrd mdadm.conf - точно такая же байда.

при необходимости - поправить порядок скриптов в /etc/rcS.d/

Не получится ли фэйла после очередного обновления? Машинка будет в продакшне. Не хотелось бы огрести глюков.

И ещё - на этих массивах будут лежать LV с некоторыми системными потрохами (/var/log, swap) и образами ВМ. Так что слишком поздно собирать их тоже не получится.

Так он собирается или не собирается совсем? Если у меня bitmap на RO FS, то RAID не собирается вообще. Если ты про auto-read-only в /proc/mdstat, то оно меняется при попытке записи на массив.

В обоих случаях массивы собираются с

md1 : active (auto-read-only) raid1 sdb1[0] sda1[1]
      976368768 blocks super 1.2 [2/2] [UU]

Вот интересно, неужели всем, кто в красношапках и дебианообразных (гугл говорит, что в них такая же фигня) использует внешний битмап, приходится курочить системные инит-скрипты? Или это настолько редко используемая фича, что даже в багтрекеры не попадает? Яфшоке, вообще.

Сast dyasny. Ты широко используешь красношапки, я знаю. Может, что подскажешь.

Ну, я вообще внутренний использую с более-менее большим размером блока.

Так что слишком поздно собирать их тоже не получится.

А сильно поздно и не надо, просто сделать это после checkrootfs

Не получится ли фэйла после очередного обновления? Машинка будет в продакшне. Не хотелось бы огрести глюков.

Да, поэтому надо сделать это максимально корректно в понятиях CentOS'а.

внутренний использую с более-менее большим размером блока.

Угу, всё к тому и идёт. Поиграться с размерами блоков, погонять тесты. Но SSD'шку изначально для битмапа и ставил, как-то не хочется отказываться.

эту фичу я не использую, но если где и спрашивать то на #rhel на freenode.

/var/log это не страшно. Из rc.sysinit туда пишется wtmp, boot.log, dmesg и может ещё какая мелочёвка. Основные логи пишет syslog и другие демоны, и скрипт создания raid'а и монтирования разделов можно запустить из /etc/rc3.d/ до этих демонов, но после rc.sysinit, при это будет штатнымое средство и на него обновление повлиять не должно. И swap тоже не обязательно из rc.sysinit активировать, можно и немого позже.

Другое дело, я как-то не нашёл правил работы с этим bitmap'ом. Ведь если ФС, на которой он лежит была повреждена, то ведь и файл с bitmap'ом может быть повреждён. И тогда что, нужно создавать bitmap заново? А были ли внесены изменения в корневую ФС знает только fsck, вызываемый из rc.sysinit...

quit

Поскольку проведённые тесты (на striped LV поверх обоих raid1, с активным NCQ + CFQ) не позволили выявить разницу в производительности между массивом с битмапом на SSD, без битмапа вообще и internal bitmap, решил остановиться на последнем варианте.

Спасибо всем отписавшимся за помощь в прояснении ситуации.