Summary: | Ошибка запуска raid6 в установленной системе | ||||||
---|---|---|---|---|---|---|---|
Product: | ALT Linux Centaurus | Reporter: | Michael A. Kangin <prividen> | ||||
Component: | Установка | Assignee: | Anton V. Boyarshinov <boyarsh> | ||||
Status: | NEW --- | QA Contact: | QA p6 <qa-p6> | ||||
Severity: | normal | ||||||
Priority: | P3 | ||||||
Version: | 7.0 | ||||||
Hardware: | all | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Michael A. Kangin
2013-05-09 22:00:39 MSK
С ядром 3.8.12-std-def-alt1 и udev-201-alt1 все рейды оказываются подняты раньше, чем выполняется /etc/rc.d/scripts/raidstart, который всё равно выполняется. Возможны races, с вываливанием ошибки инициализации рейдов. (В ответ на комментарий №1)
> Возможны races, с вываливанием ошибки инициализации рейдов.
точнее массив не успевает до конца инициализироваться, он поднят, но в состоянии inactive.
И натравливание на него mdadm -As в таком состоянии ведёт к ошибке (кажется, 2), и невозможности дальнейшего поднятия массива через --run.
А у этого свои побочные эффекты - не подцепляются внешние bitmaps.
Если в raidstart в функцию start_raid_using_mdadm добавить диагностику с значительной паузой:
if [ -x "$f" ]; then
echo -n "(using mdadm) "
echo "debug"
cat /proc/mdstat
echo ---------
sleep 10s
cat /proc/mdstat
echo ---------
"$f" --assemble --scan
return $?
fi
то мы увидим картину, как в приложенном скриншоте
Created attachment 5820 [details]
скриншот долгой инициализации массива
милая особенность моей конфигурации: 4 из 8 дисков, входящих в массив, контролируются модулем isci, который отличается долгой инициализацией. Если его не включать в initrd, то нужно делать долгую паузу перед инициализацией массива. Если его включить в initrd, то всё долго тормозит там ("loop: Running md_run handler"). и на ядре std-def-3.8.10 это даже приводило к аварийной консоли из-за (initrd): Stage 'killall' failed |