LINUX.ORG.RU
решено ФорумAdmin

bitmap в файле дохнет при ребуте

 ,


0

3

Машинка с CentOS 6.5, в ней SSD под систему (/) и 4 терабайтника, объединённых в два зеркала посредством mdadm (

~$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
~$ mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
). Добавляем bitmap:
~$ mdadm --grow --bitmap=/bitmap/md0.bitmap --bitmap-chunk=131072 /dev/md0
~$ mdadm --grow --bitmap=/bitmap/md1.bitmap --bitmap-chunk=131072 /dev/md1

~$ cat /etc/mdadm.conf
ARRAY /dev/md0  metadata=1.2 UUID=696547c7:ec6437cb:b9661802:47b7bbd2 name=masterw.wm:0 bitmap=/bitmap/md0.bitmap
ARRAY /dev/md1  metadata=1.2 UUID=e8cbb8ee:0ef60270:27506bd3:8df71334 name=masterw.wm:1 bitmap=/bitmap/md1.bitmap
Пока всё хорошо. Пересобираем initrd. Всё ещё хорошо. Перезагружаемся, и всё становится плохо. Ниже представлены два варианта развития событий:

  • Вариант 1: /bitmap - просто каталог в корне. Тогда при загрузке в самом начале boot.log появляется печальная запись о том, что невозможно добавить bitmap ввиду того, что он находится на read-only filesystem, и raid собирается ro. Оно и понятно - на момент сборки массива корень ещё не перемонтировался в rw.
  • Вариант 2: /bitmap - точка монтирования ФС из fstab. В таком случае в boot.log появляется не менее печальная запись о том, что, мол, «нет такого файла или каталога», и массив опять оказывается ro. Тоже всё, в принципе, понятно - к моменту сборки массива файловые системы из fstab ещё не примонтированы.

    Таким образом, задействование bitmap'а в файле видится невозможным без перековыривания системы инициализации.

    Кто виноват? Что делать?

★★★

Кто виноват?

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

Что делать?

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

mky ★★★★★ ()

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

d_a ★★★★★ ()
Ответ на: комментарий от mky

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

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

nbw ★★★ ()
Ответ на: комментарий от d_a

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

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

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

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

nbw ★★★ ()
Ответ на: комментарий от nbw

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

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

d_a ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от nbw

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

Тогда стоит разобраться с тем, почему у тебя ФС в 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>

YAR ★★★★★ ()
Последнее исправление: YAR (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Gotf ★★★ ()
Ответ на: комментарий от YAR

Тогда стоит разобраться с тем, почему у тебя ФС в 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]
и приходят в нормальный режим при попытке записи на них, как ты и написал.

nbw ★★★ ()
Последнее исправление: nbw (всего исправлений: 2)
Ответ на: комментарий от Gotf

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

nbw ★★★ ()
Последнее исправление: nbw (всего исправлений: 1)
Ответ на: комментарий от nbw

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

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

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

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

YAR ★★★★★ ()
Ответ на: комментарий от YAR

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

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

nbw ★★★ ()
Ответ на: комментарий от nbw

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

dyasny ★★★★★ ()
Ответ на: комментарий от nbw

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

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

mky ★★★★★ ()

quit

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

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

nbw ★★★ ()
Последнее исправление: nbw (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.