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

[Leonid Krivoshein]

28.02.2020 2:27, 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.

Видимо я этого не понял, да. Потому что вижу, что конкуренции нет: после 
проверки на существование PID-файла, сразу выход. Но до выхода он 
успевает дотронутся до файла. Так что ли и задумывалось?


> Проверка pidfile нужна для того, чтобы запустить проверку таймаута лишь
> один раз.
>
> Я понимаю, что в этом коде есть рейс между проверкой и созданием pidfile.
> Я думаю это изменить в следующем патче.
>
>> и вот этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась
>> ввиду повторная обработка после изменения структуры /sys/block/md*/, то
>> её не будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого
>> массива, хотя достаточно одного на все).
> Да, mdadm нужно выполнять только если что-то из /sys/block/md* изменилось.
> Этот патч решал проблему таймаута. Этот код мигрировал из
> /lib/uevent/extenders/100-mdstart.
>

Понятно, но я имел ввиду это:

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/initrd/trouble/050-mdstart;h=e594a0663695ac71c19a042c468d3f4339e2aaeb;hb=9f1bee4172c43ae7208855c6cb991e0e415d7f08

(строки #4-13)


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

Некоторые прописывают ноды девайсов в /etc/fstab. Потом не забывай, что 
это только у тебя systemd нет, у большинства пользователей альта он 
работает и динамически создаёт девайс-таргеты. Ну и, может, где ещё 
ссылки на /dev/mdX есть, не знаю. Многие предпочитают /dev/md0 вместо 
/dev/md127. Но главный аргумент в другом: желательно собрать рейды до 
перехода в корень и сразу починить ситуацию с read-auto. Если этого не 
сделать, всё равно нормально система не загрузится. Даже если 
загрузится, как показали мои предыдущие эксперименты, уже не нормально, 
что SWAP в состоянии read-only и по сути отключен. Это значит, что 
несмотря на удачную загрузку, в каких-то конфигурациях прилетит 
нежданчиик ООМ.


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

Отлично!


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

Если ставить целью перейти как можно быстрее в корень, как только для 
этого образуется любая возможность, то да. Но, мне кажется, это неверная 
цель, и не надо беспокоиться о невозможности загрузки рейдов на этой 
стадии. Как раз наоборот. Либо всё починили и грузимся, либо бестолку 
грузиться, поскольку ещё неизвестно, что там поломано и как оно себя 
поведёт. Рабочий корень это ещё не средство для ремонта. Но если уж так 
совсем боязно, можно предусмотреть загрузочную опцию типа NO_REPAIR=1 и 
писать о ней в конце при невозможности авто-ремонта.


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

-- 
Best regards,
Leonid Krivoshein.