From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gladkov.alexey@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 sa.local.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,
 FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no
 version=3.4.1
Date: Fri, 28 Feb 2020 14:33:37 +0100
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: make-initrd@lists.altlinux.org
Message-ID: <20200228133337.tx6kxq2jdwcb2nxl@comp-core-i7-2640m-0182e6>
References: <f25ac057-0b29-b2a4-9bff-bdb94c093f4e@basealt.ru>
 <20200217104230.m2t7xvp4pv2f2lyq@comp-core-i7-2640m-0182e6>
 <b616e663-a19c-2716-707b-277553376b86@basealt.ru>
 <20200217152312.suvw3d3snuquenfz@comp-core-i7-2640m-0182e6>
 <20200227201003.mjh46m7ibmk4vkpf@comp-core-i7-2640m-0182e6>
 <14676039-c12b-489f-2b8f-e9deaaeb5519@gmail.com>
 <20200227232737.wqerot2yslzd3egz@comp-core-i7-2640m-0182e6>
 <3e3e05f2-0a8b-7885-58e4-2571fad8aaae@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3e3e05f2-0a8b-7885-58e4-2571fad8aaae@gmail.com>
Subject: Re: [make-initrd]
 =?utf-8?q?=5Bdegraded_md-raid=5D_make-initrd_=D0=B2?=
 =?utf-8?b?IHA5INC4INCyINCh0LjQt9C40YTQtQ==?=
X-BeenThere: make-initrd@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: make-initrd@lists.altlinux.org
List-Id: <make-initrd.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/make-initrd>
List-Post: <mailto:make-initrd@lists.altlinux.org>
List-Help: <mailto:make-initrd-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/make-initrd>,
 <mailto:make-initrd-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 13:33:41 -0000
Archived-At: <http://lore.altlinux.org/make-initrd/20200228133337.tx6kxq2jdwcb2nxl@comp-core-i7-2640m-0182e6/>
List-Archive: <http://lore.altlinux.org/make-initrd/>

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