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

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Fri, Feb 28, 2020 at 03:17:12AM +0300, Leonid Krivoshein wrote:
> > Кажется ты не понял назначение $tsfile. Его содержимое не важно, кроме
> > того я его не перезаписываю. Важен его mtime, который меняет touch. Этот
> > touch не под проверкой на наличие PID-файла, потому что 100-timeout может
> > выполнятся конкурентно и каждый процесс будет сдвигать таймаут
> > относительно $now.
> 
> Видимо я этого не понял, да. Потому что вижу, что конкуренции нет: после
> проверки на существование PID-файла, сразу выход. Но до выхода он успевает
> дотронутся до файла. Так что ли и задумывалось?

Да. В этом месте и предусмотрена конкуренция. Если скрипт будет выполнен
параллельно (одновременно), то они сделают touch now+delay на $tsfile т.е.
mtime этого файла будет сдвинут примерно на одно значение. Блокировки на
изменение mtime будет делать ядро.

> > Да, 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)

Этот код не предлагался для master. Поэтому я его не использовал. Да,
нужно сделать так или даже ещё хитрее.

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

Ну это совсем не аргумент. Эти некоторые должны понимать, что имена могут
меняться. Для этого уже давно есть UUID= и LABEL= для отвязки от имён
девайсов. Если есть вероятность, что имя может измениться (например как в
этом случае), то нужно использовать UUID.

Вспомни про историю с именами сетевых интерфейсов.

> Потом не забывай, что это только у тебя systemd нет, у большинства
> пользователей альта он работает и динамически создаёт девайс-таргеты.

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

> Ну и, может, где ещё ссылки на /dev/mdX есть, не знаю. Многие
> предпочитают /dev/md0 вместо /dev/md127.

Так и делается. Посмотри в /dev/disk/*. Вот их и нужно использовать.

> Но главный аргумент в другом: желательно собрать рейды до перехода в
> корень и сразу починить ситуацию с read-auto. Если этого не сделать, всё
> равно нормально система не загрузится.

Если корень собран, то загрузится. Если в корне лежит не всё, что нужно
для закрузки, то это неправильная конфигурация.

Кстати, make-initrd умеет ждать не только рут, но и другие точки
монтирования. Для этого можно либо добавить точку монтирования в
MOUNTPOINTS, либо добавить x-initrd-mount в опции точки монтирования в
fstab.

> Даже если загрузится, как показали мои предыдущие
> эксперименты, уже не нормально, что SWAP в состоянии read-only и по сути
> отключен. Это значит, что несмотря на удачную загрузку, в каких-то
> конфигурациях прилетит нежданчиик ООМ.

Зачем swap на рейд ?! Не делай так.

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

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

> Рабочий корень это ещё не средство для ремонта.

Ты ошибаешься. Для этого у нас есть деление на /bin, /sbin и /usr .

Только не нужно мне рассказывать о моих коллегах, которые всё
перенесли в /usr.

> Но если уж так совсем боязно, можно
> предусмотреть загрузочную опцию типа NO_REPAIR=1 и писать о ней в конце при
> невозможности авто-ремонта.

Вот подумай, как ты сможешь ввести этот параметр, если ты _уже_ не смог
загрузиться ? Поедешь не площадку к серверу, чтобы этот параметр ввести ?

-- 
Rgrds, legion