[make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе

[Alexey Gladkov]

On Fri, Feb 28, 2020 at 12:26:17AM +0300, Leonid Krivoshein wrote:
> > Суть фикса [2] это использовать не фиксированный таймаут для инициализации
> > рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
> > появления последнего raid-member. По умолчанию новый таймаут выставлен в
> > 10 секунд т.е. если через 10 секунд после появления последнего
> > raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.
> 
> Хорошая идея. И задержка разумная. Но по реализации 100-timeout есть
> сомнения: использован RTC вместо твоего же MONOTONIC TIMESTAMP (а время в
> этой стадии точно не может скакануть?)

Время может прыгнуть лишь в виртуалке и с определёнными настройками
виртуалки. touch здесь используется для сериализации смещения таймаута.

> перезатирается $tsfile вторым экземпляром (по идее, надо сначала
> проверять наличие PID-файла)

Кажется ты не понял назначение $tsfile. Его содержимое не важно, кроме
того я его не перезаписываю. Важен его mtime, который меняет touch. Этот
touch не под проверкой на наличие PID-файла, потому что 100-timeout может
выполнятся конкурентно и каждый процесс будет сдвигать таймаут
относительно $now.

Проверка pidfile нужна для того, чтобы запустить проверку таймаута лишь
один раз.

Я понимаю, что в этом коде есть рейс между проверкой и созданием pidfile.
Я думаю это изменить в следующем патче.

> и вот этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась
> ввиду повторная обработка после изменения структуры /sys/block/md*/, то
> её не будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого
> массива, хотя достаточно одного на все).

Да, mdadm нужно выполнять только если что-то из /sys/block/md* изменилось.
Этот патч решал проблему таймаута. Этот код мигрировал из
/lib/uevent/extenders/100-mdstart.

> > Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> > лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> > целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> > не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> > mdadm.conf в такой ситуации у меня нет.
> 
> Виталий там написал, почему идея не очень: действительно имена md будут
> другими.

Я не понял этого аргумента в тогда, так не пониманию сейчас (может ты
объяснишь). Зачем вам стабильные имена этих девайсов ?

> В идеале иметь возможность указывать некий target (чего должен ждать
> init), и чтобы этим target'ом мог бы быть даже некий кастомный скрипт,
> который определяет условие завершения работы.

Это уже есть.

> Тогда можно будет обеспечить выход после обнаружения всех массивов,
> нескольких сетевых карт, итд.

В целом, можно, но это мягко говоря замедлит загрузку. В принципе initrd
уже умеет ждать несколько точек монтирования. Можно попробовать ждать и не
только рутовый девайс.

Меня беспокоит, что в этом случае любая проблема с любым рейдом в системе
может привезти к невозможности загрузки.

> На железе точно нет. А на PVE тот же qemu. Есть ещё VirtualBox.

Ну это не очень интересно.

-- 
Rgrds, legion