Make-initrd development discussion
 help / color / mirror / Atom feed
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
Date: Fri, 28 Feb 2020 14:33:37 +0100
Message-ID: <20200228133337.tx6kxq2jdwcb2nxl@comp-core-i7-2640m-0182e6> (raw)
In-Reply-To: <3e3e05f2-0a8b-7885-58e4-2571fad8aaae@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



  reply	other threads:[~2020-02-28 13:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17 11:27   ` Leonid Krivoshein
2020-02-17 15:23     ` Alexey Gladkov
2020-02-17 15:28       ` Michael Shigorin
2020-02-18  0:51         ` Leonid Krivoshein
2020-02-17 15:59       ` Leonid Krivoshein
2020-02-17 19:21       ` Leonid Krivoshein
2020-02-18 20:08           ` Michael Shigorin
2020-02-18 20:42             ` Leonid Krivoshein
2020-02-27 20:10       ` Alex Gladkov
2020-02-27 20:30         ` Michael A. Kangin
2020-02-27 21:35           ` Leonid Krivoshein
2020-02-27 22:05           ` Alexey Gladkov
2020-02-27 22:12             ` Michael A. Kangin
2020-02-27 23:34               ` Alexey Gladkov
2020-03-06 20:32           ` Michael Shigorin
2020-02-27 21:26         ` Leonid Krivoshein
2020-02-27 23:27           ` Alexey Gladkov
2020-02-28  0:17             ` Leonid Krivoshein
2020-02-28 13:33               ` Alexey Gladkov [this message]
2020-02-28 21:43                 ` Leonid Krivoshein
2020-02-28 23:39                   ` Alexey Gladkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200228133337.tx6kxq2jdwcb2nxl@comp-core-i7-2640m-0182e6 \
    --to=gladkov.alexey@gmail.com \
    --cc=make-initrd@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Make-initrd development discussion

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
		make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
	public-inbox-index make-initrd

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.make-initrd


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git