[Sysadmins] P7: Проблема с softRAID при старте системы

[Alex Moskalenko]

09.08.2013 19:57, Alexey Shabalin пишет:
> 9 августа 2013 г., 19:15 пользователь Alex Moskalenko  написал:
>
>     08.08.2013 19:20, Alexey Shabalin пишет:
>>
>>         Похоже, все-таки главный вопрос в том, почему при сборке
>>         массива правилами udev при доступном корне с файлом bitmap и
>>         /etc/mdadm.conf массив собирается как-то неправильно, а при
>>         всех тех же условиях, но с вручную набранными теми же mdadm
>>         --incremental ... -offroot - собирается и стартует корректно....
>>
>>
>>     Могу подозревать, что это связано с тойже проблемой, что и с lvm.
>>     А именно - удаление базы udev в initrd.
>>
>

Вот dmesg в части md и монтирования корневой fs (md0):

[    5.626125] md: Autodetecting RAID arrays.
[    5.630388] md: Scanned 4 and added 4 devices.
[    5.630391] md: autorun ...
[    5.630394] md: considering sdb3 ...
[    5.630400] md:  adding sdb3 ...
[    5.630404] md: sdb2 has different UUID to sdb3
[    5.630409] md:  adding sda3 ...
[    5.630412] md: sda2 has different UUID to sdb3
[    5.630711] md: created md1
[    5.630714] md: bind<sda3>
[    5.630729] md: bind<sdb3>
[    5.630742] md: running: <sdb3><sda3>
[    5.635953] md: raid1 personality registered for level 1
[    5.637357] md/raid1:md1: active with 2 out of 2 mirrors
[    5.637386] md1: detected capacity change from 0 to 494738014208
[    5.637405] md: considering sdb2 ...
[    5.637412] md:  adding sdb2 ...
[    5.637418] md:  adding sda2 ...
[    5.637421] md: created md0
[    5.637423] md: bind<sda2>
[    5.637440] md: bind<sdb2>
[    5.637453] md: running: <sdb2><sda2>
[    5.639309]  md1: unknown partition table
[    5.642515] md/raid1:md0: active with 2 out of 2 mirrors
[    5.642545] md0: detected capacity change from 0 to 4293853184
[    5.642567] md: ... autorun DONE.
[    5.644278]  md0: unknown partition table
[    5.778432] md: Autodetecting RAID arrays.
[    5.778437] md: Scanned 0 and added 0 devices.
[    5.778439] md: autorun ...
[    5.778441] md: ... autorun DONE.
[    5.835439] EXT3-fs (md0): mounted filesystem with journal data mode
[    7.400627] <30>systemd-udevd[506]: starting version 201
[    8.076510] md: bind<sdc1>
[    8.139945] md: bind<sde1>
[    8.149416] md: bind<sdd1>
[    8.163999] md: bind<sdf1>
[    8.685031] EXT3-fs (md0): using internal journal
[  197.968246] md: md10 stopped.
[  197.968280] md: unbind<sdc1>
[  197.971137] md: export_rdev(sdc1)
[  197.971174] md: unbind<sdd1>
[  197.974136] md: export_rdev(sdd1)
[  197.974163] md: unbind<sde1>
[  197.977137] md: export_rdev(sde1)
[  197.977164] md: unbind<sdf1>
[  197.985140] md: export_rdev(sdf1)
[  225.675355] md: bind<sdc1>
[  238.238402] md: bind<sdd1>
[  240.830269] md: bind<sde1>
[  244.092377] md: bind<sdf1>
[  244.099336] md: raid10 personality registered for level 10
[  244.099713] md/raid10:md10: active with 4 out of 4 devices
[  244.119088] created bitmap (450 pages) for device md10
[  244.212238] md10: bitmap initialized from disk: read 29 pages, set 0 
of 921598 bits
[  244.220268] md10: detected capacity change from 0 to 966365151232
[  244.220938]  md10: unknown partition table


Вроде бы компоненты md10 (sd[cdef]1 добавляются в массив после 
монтирования /, но настораживает сообщение
[    8.685031] EXT3-fs (md0): using internal journal, которое одет 
несколько позже и относится также к md0.

Похоже (если я правильно понял логику rc.sysinit), что сначала стартует 
udev и отрабатывают его правила, а затем корень перемонтируется в rw. 
Из-за этого bitmap-файл еще недоступен на запись и массив не стартует. 
Если я угадал, то возникает вопрос - можно ли как-нибудь обойти такое 
поведение, то есть исключить некоторые массивы из обработки правилами 
udev? Если не собирать отдельно взятый массив udev'ом, то в процессе 
загрузки он все равно будет собран и запущен с помощью 
/etc/rc.d/scripts/raidstart.

PS Использовать internal bitmap не хотелось бы, так как проведенные 
ранее тесты показывают ощутимую просадку производительности на запись. 
Совсем отказываться от bitmap тоже не хочется - массив довольно большой 
и синхронизация занимает длительное время.

----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/sysadmins/attachments/20130809/ced1c7d8/attachment-0001.html>