Pull to refresh

Проблема одновременного использование kernel raid autodetect для / на /dev/md0 и superblock v1.2 для других /dev/md, или как можно уронить (и поднять) сервер после его обновления

Reading time 3 min
Views 7.8K

Спасибо, что дочитали заголовок. Это был тест.


Сегодня, после наката очередных обновления на свой любимый Gentoo сервер и профилактического reboot'a, внезапно, отвалился /dev/md1 со словами мудрого ядра: sdc1 does not have a valid v0.90 superblock, not importing!

Шок! Паника! хорошо, что не в ядре…

А в чём, собственно, дело?


Для начала расскажу о конфигурации сервера, чтобы было легче понять суть проблемы и способ её решения. Итак, ядро 3.10.7 с включённым RAID autodetect и двумя RAID1 (зеркало) дисками.

На /dev/md0 монтируется root, на /dev/md1 база данных (Percona):
db13 ~ # cat /etc/fstab | grep md
/dev/md0                /               ext3            noatime         0 1
/dev/md1                /mnt/db         reiser4         noatime         0 0

И кусочек /boot/grub/grub.conf:
title Gentoo Linux 3.10.7 md0
root (hd0,0)
kernel /boot/kernel-3.10.7 root=/dev/md0

Так вот, для успешной сборки md устройств ядром во время загрузки должно быть выполнено два условия:
  1. Тип 0xFD у партиций, на которых строится RAID
  2. Версия формата superblock 0.90 на устройстве /dev/md, которое создается при помощи mdadm

Если с п.1. в моей конфигурации все было хорошо, то, как оказалось, формат superblock был 1.2 Подозреваю, что /dev/md1 я создавал после того, как пришла новая версия mdadm, которая по-умолчанию использует именно этот формат. Как результат, ядро ругается страшными словами:
dmesg | grep md
[    0.000000] Command line: root=/dev/md0 raid=/dev/md0
[    0.000000] Kernel command line: root=/dev/md0 raid=/dev/md0
[    1.063603] md: raid1 personality registered for level 1
[    1.266420] md: Waiting for all devices to be available before autodetect
[    1.266494] md: If you don't use raid, use raid=noautodetect
[    1.266781] md: Autodetecting RAID arrays.
[    1.293670] md: invalid raid superblock magic on sdc1
[    1.294210] md: sdc1 does not have a valid v0.90 superblock, not importing!
[    1.312482] md: invalid raid superblock magic on sdd1
[    1.312556] md: sdd1 does not have a valid v0.90 superblock, not importing!
[    1.312579] md: Scanned 4 and added 2 devices.
[    1.312595] md: autorun ...
[    1.312610] md: considering sdb3 ...
[    1.312626] md:  adding sdb3 ...
[    1.312641] md:  adding sda3 ...
[    1.312657] md: created md0
[    1.312665] md: bind<sda3>
[    1.312754] md: bind<sdb3>
[    1.312770] md: running: <sdb3><sda3>
[    1.313064] md/raid1:md0: active with 2 out of 2 mirrors
[    1.313166] md0: detected capacity change from 0 to 7984840704
[    1.313262] md: ... autorun DONE.
[    1.320413]  md0: unknown partition table
[    1.338528] EXT3-fs (md0): mounted filesystem with ordered data mode
[    2.581420] systemd-udevd[861]: starting version 208
[    3.122748] md: bind<sdc1>
[    4.896331] EXT3-fs (md0): using internal journal


Когда не помогает Google


Выбор совсем небольшой — либо отключать автоопределение массивов в ядре (перекомпиляция и правки в grub.conf), либо изменять формат суперблока (полный бэкап данных и убийство зеркала с последующим его восстановлением). Оба варианта «не вариант», так как по сути своей деструктивны и могут привести к потери данных, да и времени могут занять немало (как выяснилось в процессе поиска решения kernel autodetect is depricated feature)

К слову сказать, после старта севрера /dev/md1 прекрасно запускается при помощи команды
mdadm --manage /dev/md1 --run
. Конечно, можно было бы прописать эту строчку куда-нибудь в rc-скрипты, но, согласитесь, это как-то не спортивно.

Эврика!


Решение пришло не сразу, хотя лежало на поверхности — всё, что нужно сделать, это убрать тип 0xFD (заменить на 0х83) у дисков в /dev/md1 и тогда ядро перестанет безуспешно пытаться собрать этот массив, мешая при этом udevd делать свою работу. И действительно, после применения fdisk для изменения типа партиций на обеих зеркалах и перезагрузки сервера, все чудесным образом завелось:
dmesg | grep md
[    0.000000] Command line: root=/dev/md0 raid=/dev/md0
[    0.000000] Kernel command line: root=/dev/md0 raid=/dev/md0
[    1.063924] md: raid1 personality registered for level 1
[    1.248078] md: Waiting for all devices to be available before autodetect
[    1.248201] md: If you don't use raid, use raid=noautodetect
[    1.248504] md: Autodetecting RAID arrays.
[    1.265058] md: Scanned 2 and added 2 devices.
[    1.265243] md: autorun ...
[    1.265258] md: considering sda3 ...
[    1.265274] md:  adding sda3 ...
[    1.265290] md:  adding sdb3 ...
[    1.265305] md: created md0
[    1.265321] md: bind<sdb3>
[    1.265331] md: bind<sda3>
[    1.265428] md: running: <sda3><sdb3>
[    1.265865] md/raid1:md0: active with 2 out of 2 mirrors
[    1.265891] md0: detected capacity change from 0 to 7984840704
[    1.266068] md: ... autorun DONE.
[    1.276627]  md0: unknown partition table
[    1.294892] EXT3-fs (md0): mounted filesystem with ordered data mode
[    2.713383] systemd-udevd[860]: starting version 208
[    3.128295] md: bind<sdc1>
[    3.159107] md: bind<sdd1>
[    3.170320] md/raid1:md1: active with 2 out of 2 mirrors
[    3.170333] md1: detected capacity change from 0 to 17170300928
[    3.178113]  md1: unknown partition table
[    4.911712] EXT3-fs (md0): using internal journal
[    5.027077] reiser4: md1: found disk format 4.0.0.


Буду рад, если Google, найдя этот текст, покажет его моим коллегам по цеху, попавшим в похожую ситуацию.
Tags:
Hubs:
+17
Comments 29
Comments Comments 29

Articles