Make-initrd development discussion
 help / color / mirror / Atom feed
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  @ 2020-02-17 11:27   ` Leonid Krivoshein
  2020-02-17 15:23     ` Alexey Gladkov
  0 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-17 11:27 UTC (permalink / raw)
  To: Alexey Gladkov
  Cc: make-initrd, Alexey Shabalin,
	Андрей
	Черепанов

Привет, Алексей, ещё раз! :-)


17.02.2020 13:42, Alexey Gladkov пишет:
> On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> На p8 была попытка исправить проблему загрузки с деградированного массива:
>>
>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>>
>> В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
>> но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
>> лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
>> больше нет, есть только это:
>>
>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
>>
>> Две ситуации исправляются руками тривиально: в случае inactive одного из
>> дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
>> или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
>> mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
>> таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
>> корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
>> но по факту никак не работает. Система не грузится даже с только что
>> созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
>> что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
>> (это уже про ситуацию, когда LVM поверх MD).
>>
>> Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
>> этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
>> не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
>> известно. Есть какие-нибудь идеи, камрады?
> Вы много написали, но я явно не в контекте. Давайте по порядку.
>
> Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
>
> Он решает проблему и не решает какую проблему ?
> Какие ещё проблемы есть ?

Не решает ни одну из двух проблем:

- не "чинит" MD-устройства в состоянии "read-auto", поэтому после 
перехода в stage2 корень на RAID нельзя перемонтировать в режим 
чтения-записи.

- по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с 
MD-RAID, который в состоянии "degraded", хотя для больших дисков это 
норма сразу после инсталляции -- они просто ещё не успели 
до-синхронизироваться. В старой версии отрабатывал troubleshutter by 
mike@, который я перетянул из p7/c7 в p8 и c8/c8.1. Во времена p7 ты 
утянул этот troubleshutter в тогдашний Сизиф, но видимо теперь оно 
совсем нерабочее.

В идеале решать обе проблемы в новом make-initrd2 для любых 
обнаруживаемых блочных дисков, а не только для тех, на которых корень, 
аккуратно пытаться исправить приведёнными командами. Очевидно, обработка 
должна находиться не здесь, а где-то ещё.

Сейчас я воспроизведу на виртуалке и отпишу более детально...


-- 
С уважением,
Леонид Кривошеин.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-17 11:27   ` [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе Leonid Krivoshein
@ 2020-02-17 15:23     ` Alexey Gladkov
  2020-02-17 15:28       ` Michael Shigorin
                         ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-17 15:23 UTC (permalink / raw)
  To: Leonid Krivoshein
  Cc: make-initrd, Alexey Shabalin,
	Андрей
	Черепанов

On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
> Привет, Алексей, ещё раз! :-)
> 
> 
> 17.02.2020 13:42, Alexey Gladkov пишет:
> > On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
> > > Всем привет!
> > > 
> > > 
> > > На p8 была попытка исправить проблему загрузки с деградированного массива:
> > > 
> > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
> > > 
> > > В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
> > > но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
> > > лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
> > > больше нет, есть только это:
> > > 
> > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
> > > 
> > > Две ситуации исправляются руками тривиально: в случае inactive одного из
> > > дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
> > > или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
> > > mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
> > > таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
> > > корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
> > > но по факту никак не работает. Система не грузится даже с только что
> > > созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
> > > что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
> > > (это уже про ситуацию, когда LVM поверх MD).
> > > 
> > > Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
> > > этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
> > > не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
> > > известно. Есть какие-нибудь идеи, камрады?
> > Вы много написали, но я явно не в контекте. Давайте по порядку.
> > 
> > Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
> > 
> > Он решает проблему и не решает какую проблему ?
> > Какие ещё проблемы есть ?
> 
> Не решает ни одну из двух проблем:

ok. Значит он перестал работать совсем.

Нужно будет написать тест про degraded raid. Я примерно понимаю как это
должно выглядеть. А вот с read-auto сложнее. Что это ?

Можно тебя попросить написать тест (я готов ответить на любые вопросы про
новые end-to-end тесты) ?

> - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
> stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
> 
> - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
> MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
> сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
> старой версии отрабатывал troubleshutter by mike@, который я перетянул из
> p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
> тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
> 
> В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
> блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
> исправить приведёнными командами. Очевидно, обработка должна находиться не
> здесь, а где-то ещё.
> 
> Сейчас я воспроизведу на виртуалке и отпишу более детально...

Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
было посмотреть.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  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
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 21+ messages in thread
From: Michael Shigorin @ 2020-02-17 15:28 UTC (permalink / raw)
  To: make-initrd
  Cc: Alexey Shabalin, Leonid Krivoshein,
	Андрей
	Черепанов

On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
> Нужно будет написать тест про degraded raid. Я примерно понимаю
> как это должно выглядеть. А вот с read-auto сложнее. Что это ?

Это делаешь зеркало и выдёргиваешь из него один из дисков
(что выдрав из железки/виртуалки, что сказав нечто вроде
mdadm /dev/md0 --fail /dev/sdb), cat /proc/mdstat и reboot.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-17 15:23     ` Alexey Gladkov
  2020-02-17 15:28       ` Michael Shigorin
@ 2020-02-17 15:59       ` Leonid Krivoshein
  2020-02-17 19:21       ` Leonid Krivoshein
  2020-02-27 20:10       ` Alex Gladkov
  3 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-17 15:59 UTC (permalink / raw)
  To: Michael Shigorin, Alexey Shabalin,
	Андрей
	Черепанов,
	make-initrd


17.02.2020 18:23, Alexey Gladkov пишет:
> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
>> Привет, Алексей, ещё раз! :-)
>>
>>
>> 17.02.2020 13:42, Alexey Gladkov пишет:
>>> On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
>>>> Всем привет!
>>>>
>>>>
>>>> На p8 была попытка исправить проблему загрузки с деградированного массива:
>>>>
>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>>>>
>>>> В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
>>>> но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
>>>> лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
>>>> больше нет, есть только это:
>>>>
>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
>>>>
>>>> Две ситуации исправляются руками тривиально: в случае inactive одного из
>>>> дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
>>>> или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
>>>> mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
>>>> таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
>>>> корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
>>>> но по факту никак не работает. Система не грузится даже с только что
>>>> созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
>>>> что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
>>>> (это уже про ситуацию, когда LVM поверх MD).
>>>>
>>>> Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
>>>> этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
>>>> не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
>>>> известно. Есть какие-нибудь идеи, камрады?
>>> Вы много написали, но я явно не в контекте. Давайте по порядку.
>>>
>>> Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
>>>
>>> Он решает проблему и не решает какую проблему ?
>>> Какие ещё проблемы есть ?
>> Не решает ни одну из двух проблем:
> ok. Значит он перестал работать совсем.

Не уверен. У меня пока не получилось воспроизвести то, что получилось в 
пятницу. Сейчас шаг за шагом проверяю, тут ещё и в грабе обнаружилась 
коряква, просто немного отвлекли...


> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?

После установки машина не грузится, но можно загрузиться в ALT Rescue, 
да посмотреть, как это выглядит и починить:

[root@localhost ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active (auto-read-only) raid1 sdb3[1] sda3[0]
       2304755704 blocks super 1.0 [2/2] [UU]
           resync=PENDING

md127 : active (auto-read-only) raid1 sdb2[1] sda2[0]
       2097088 blocks [2/2] [UU]

unused devices: <none>
[root@localhost ~]# mdadm -w /dev/md127
[root@localhost ~]# mdadm -w /dev/md126
[root@localhost ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active raid1 sdb3[1] sda3[0]
       2304755704 blocks super 1.0 [2/2] [UU]
       [>....................]  resync =  0.6% (15523904/2304755704) 
finish=340.8min speed=111936K/sec

md127 : active raid1 sdb2[1] sda2[0]
       2097088 blocks [2/2] [UU]

Вуаля. В данном примере обе проблемы на лицо.


> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
> новые end-to-end тесты) ?

Вот тут я не очень понял, но как воспроизвести, и как починить, точно 
могу написать.


>> - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
>> stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
>>
>> - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
>> MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
>> сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
>> старой версии отрабатывал troubleshutter by mike@, который я перетянул из
>> p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
>> тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
>>
>> В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
>> блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
>> исправить приведёнными командами. Очевидно, обработка должна находиться не
>> здесь, а где-то ещё.
>>
>> Сейчас я воспроизведу на виртуалке и отпишу более детально...
> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
> было посмотреть.

Чтобы не успело просинхронизироваться, приходится делать большие 
виртуальные диски (>2Tb каждый), такое нет смысла тащить, а доступ к PVE 
снаружи у нас, к сожалению, прикрыли.


-- 
С уважением,
Леонид Кривошеин.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-17 15:23     ` Alexey Gladkov
  2020-02-17 15:28       ` Michael Shigorin
  2020-02-17 15:59       ` Leonid Krivoshein
@ 2020-02-17 19:21       ` Leonid Krivoshein
    2020-02-27 20:10       ` Alex Gladkov
  3 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-17 19:21 UTC (permalink / raw)
  To: Michael Shigorin, Alexey Shabalin,
	Андрей
	Черепанов,
	make-initrd


17.02.2020 18:23, Alexey Gladkov пишет:
> [...]
> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?

Вот как это выглядит чисто технически:

mdadm --detail /dev/md127
...
State : clean, resyncing (PENDING)
...
cat /sys/block/md127/md/array_state
read-auto

Мне не удалось пока воспроизвести проблему с make-initrd в конфигурации 
с RAID+LVM. Зато по ходу нашёл ещё два бага, один с grub и один 
alterator-vm. make-initrd в обоих случаях совсем не при делах. Поздно 
уже, завтра продолжу...


-- 
С уважением,
Леонид Кривошеин.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-17 15:28       ` Michael Shigorin
@ 2020-02-18  0:51         ` Leonid Krivoshein
  0 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-18  0:51 UTC (permalink / raw)
  To: make-initrd



17.02.2020 18:28, Michael Shigorin пишет:
> On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
>> Нужно будет написать тест про degraded raid. Я примерно понимаю
>> как это должно выглядеть. А вот с read-auto сложнее. Что это ?
> Это делаешь зеркало и выдёргиваешь из него один из дисков
> (что выдрав из железки/виртуалки, что сказав нечто вроде
> mdadm /dev/md0 --fail /dev/sdb), cat /proc/mdstat и reboot.
>

Первое -- ДА. Второе -- похоже на mdadm -o /dev/md0 , но лишь чуточку 
похоже. Руками read-auto вроде как нельзя добиться. Руками получится 
состояние read-only. А read-auto делает само ядро в тех случаях, когда 
массив не был остановлен при выключении/перезагрузке хоста, но при этом 
нет dirty-флага. То есть, это штатная ситуация для корня и свопа на 
рейде или LVM поверх рейда, потому что старт-стоповые скрипты обычно не 
в состоянии корректно остановить такой рейд. И дефолтые правила udev 
должны по идее нормально такой массив собирать при включении, переключая 
его обратно в read-write.

P.S.: Мне кажется, можно попробовать добиться состояния read-auto 
отправкой "u" > /proc/sysrq-trigger , что собственно и делает наш 
инсталлятор с недавних пор, даже если не удастся отмонтировать всё 
корректно и остановить raid перед этим.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  @ 2020-02-18 20:08           ` Michael Shigorin
  2020-02-18 20:42             ` Leonid Krivoshein
  0 siblings, 1 reply; 21+ messages in thread
From: Michael Shigorin @ 2020-02-18 20:08 UTC (permalink / raw)
  To: make-initrd

On Tue, Feb 18, 2020 at 09:38:43PM +0300, Leonid Krivoshein wrote:
> grub не может найти mduuid/<длинный_ID>, возможно нет модуля
> mdraid.  (даже если это норма, то почему разбивалка допускает
> такую конфигурацию!).  При попытке создать VG0 из чистых
> разделов (без томов) => создаётся самый обыкновенный раздел!
> К тому же выловилось куча других багов, явно не связанных
> с make-initrd.

Ну и зачем ты это всё валишь сюда, а не в devel@?
Сам же понимаешь, что к make-initrd не относится.

> Если поставить систему на LVM-том, а SWAP оставить на md-raid,
> то после перезагрузки система загружается нормально, вот только
> md0 в состоянии read-auto. Эту ситуацию можно исправить в make-initrd.

Тут да.

> ИТОГ. Хотя мне не удалось воспроизвести ситуацию с превращением
> машины в кирпич сразу после установки, в новом make-initrd есть
> что подкрутить на предмет автоматики.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-18 20:08           ` Michael Shigorin
@ 2020-02-18 20:42             ` Leonid Krivoshein
  0 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-18 20:42 UTC (permalink / raw)
  To: make-initrd


18.02.2020 23:08, Michael Shigorin пишет:
> On Tue, Feb 18, 2020 at 09:38:43PM +0300, Leonid Krivoshein wrote:
>> grub не может найти mduuid/<длинный_ID>, возможно нет модуля
>> mdraid.  (даже если это норма, то почему разбивалка допускает
>> такую конфигурацию!).  При попытке создать VG0 из чистых
>> разделов (без томов) => создаётся самый обыкновенный раздел!
>> К тому же выловилось куча других багов, явно не связанных
>> с make-initrd.
> Ну и зачем ты это всё валишь сюда, а не в devel@?
> Сам же понимаешь, что к make-initrd не относится.

Извините, виноват, исправлюсь! Столько ситуаций с разными багами, надо 
было куда-то записать и оповестить всех заинтересованных, список-то 
внушительный получился. :) Отдельно хочу извиниться у legion@ -- похоже 
зря шум поднял. Но не понимаю, как один раз получилось, а больше не 
получается повторить. С другой стороны, проведённые эксперименты 
показывают, что часть этих проблем сейчас как раз наоборот исправляется 
правилами udev или чем-то ещё. Если наткнусь опять на эту граблю, всё же 
напишу.


>> Если поставить систему на LVM-том, а SWAP оставить на md-raid,
>> то после перезагрузки система загружается нормально, вот только
>> md0 в состоянии read-auto. Эту ситуацию можно исправить в make-initrd.
> Тут да.
>
>> ИТОГ. Хотя мне не удалось воспроизвести ситуацию с превращением
>> машины в кирпич сразу после установки, в новом make-initrd есть
>> что подкрутить на предмет автоматики.

Вот тут отдельное спасибо за сухой остаток. :)


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-17 15:23     ` Alexey Gladkov
                         ` (2 preceding siblings ...)
  2020-02-17 19:21       ` Leonid Krivoshein
@ 2020-02-27 20:10       ` Alex Gladkov
  2020-02-27 20:30         ` Michael A. Kangin
  2020-02-27 21:26         ` Leonid Krivoshein
  3 siblings, 2 replies; 21+ messages in thread
From: Alex Gladkov @ 2020-02-27 20:10 UTC (permalink / raw)
  To: Leonid Krivoshein, Michael Shigorin, Alexey Shabalin,
	Андрей
	Черепанов,
	make-initrd

On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
> > Привет, Алексей, ещё раз! :-)

Я попытался исправить проблему с таймаутом при медленной инициализации
дисков [1]. Эта проблема может как-то затрагивает и описанное здесь.

Суть фикса [2] это использовать не фиксированный таймаут для инициализации
рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
появления последнего raid-member. По умолчанию новый таймаут выставлен в
10 секунд т.е. если через 10 секунд после появления последнего
raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.

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

Не могли бы заинтересованные люди потестировать фикс [2] на реальном
железе ? У меня есть возможность протестировать в qemu, что не есть айс в
этой ситуации.

[1] https://bugzilla.altlinux.org/show_bug.cgi?id=37737
[2] http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=shortlog;h=refs/heads/fix-mdadm-timeout

> > 
> > 17.02.2020 13:42, Alexey Gladkov пишет:
> > > On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
> > > > Всем привет!
> > > > 
> > > > 
> > > > На p8 была попытка исправить проблему загрузки с деградированного массива:
> > > > 
> > > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
> > > > 
> > > > В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
> > > > но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
> > > > лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
> > > > больше нет, есть только это:
> > > > 
> > > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
> > > > 
> > > > Две ситуации исправляются руками тривиально: в случае inactive одного из
> > > > дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
> > > > или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
> > > > mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
> > > > таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
> > > > корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
> > > > но по факту никак не работает. Система не грузится даже с только что
> > > > созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
> > > > что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
> > > > (это уже про ситуацию, когда LVM поверх MD).
> > > > 
> > > > Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
> > > > этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
> > > > не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
> > > > известно. Есть какие-нибудь идеи, камрады?
> > > Вы много написали, но я явно не в контекте. Давайте по порядку.
> > > 
> > > Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
> > > 
> > > Он решает проблему и не решает какую проблему ?
> > > Какие ещё проблемы есть ?
> > 
> > Не решает ни одну из двух проблем:
> 
> ok. Значит он перестал работать совсем.
> 
> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?
> 
> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
> новые end-to-end тесты) ?
> 
> > - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
> > stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
> > 
> > - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
> > MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
> > сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
> > старой версии отрабатывал troubleshutter by mike@, который я перетянул из
> > p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
> > тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
> > 
> > В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
> > блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
> > исправить приведёнными командами. Очевидно, обработка должна находиться не
> > здесь, а где-то ещё.
> > 
> > Сейчас я воспроизведу на виртуалке и отпишу более детально...
> 
> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
> было посмотреть.
> 
> -- 
> Rgrds, legion
> 
> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd

-- 
Rgrds, agladkov



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 20:10       ` Alex Gladkov
@ 2020-02-27 20:30         ` Michael A. Kangin
  2020-02-27 21:35           ` Leonid Krivoshein
                             ` (2 more replies)
  2020-02-27 21:26         ` Leonid Krivoshein
  1 sibling, 3 replies; 21+ messages in thread
From: Michael A. Kangin @ 2020-02-27 20:30 UTC (permalink / raw)
  To: make-initrd

On 2/27/20 9:10 PM, Alex Gladkov wrote:

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

не знаю, насколько кривенько, но можно распарсить вывод:
lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')

найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 20:10       ` Alex Gladkov
  2020-02-27 20:30         ` Michael A. Kangin
@ 2020-02-27 21:26         ` Leonid Krivoshein
  2020-02-27 23:27           ` Alexey Gladkov
  1 sibling, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 21:26 UTC (permalink / raw)
  To: make-initrd

Доброй ночи!


27.02.2020 23:10, Alex Gladkov пишет:
> On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
>> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
>>> Привет, Алексей, ещё раз! :-)
> Я попытался исправить проблему с таймаутом при медленной инициализации
> дисков [1]. Эта проблема может как-то затрагивает и описанное здесь.

Ух-ты, не ожидал столь скорых подвижек!


> Суть фикса [2] это использовать не фиксированный таймаут для инициализации
> рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
> появления последнего raid-member. По умолчанию новый таймаут выставлен в
> 10 секунд т.е. если через 10 секунд после появления последнего
> raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.

Хорошая идея. И задержка разумная. Но по реализации 100-timeout есть 
сомнения: использован RTC вместо твоего же MONOTONIC TIMESTAMP (а время 
в этой стадии точно не может скакануть?), перезатирается $tsfile вторым 
экземпляром (по идее, надо сначала проверять наличие PID-файла), и вот 
этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась ввиду 
повторная обработка после изменения структуры /sys/block/md*/, то её не 
будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого 
массива, хотя достаточно одного на все).


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

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


> Не могли бы заинтересованные люди потестировать фикс [2] на реальном
> железе ? У меня есть возможность протестировать в qemu, что не есть айс в
> этой ситуации.
>
> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=37737
> [2] http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=shortlog;h=refs/heads/fix-mdadm-timeout
>

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


>>> 17.02.2020 13:42, Alexey Gladkov пишет:
>>>> On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
>>>>> Всем привет!
>>>>>
>>>>>
>>>>> На p8 была попытка исправить проблему загрузки с деградированного массива:
>>>>>
>>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>>>>>
>>>>> В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
>>>>> но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
>>>>> лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
>>>>> больше нет, есть только это:
>>>>>
>>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
>>>>>
>>>>> Две ситуации исправляются руками тривиально: в случае inactive одного из
>>>>> дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
>>>>> или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
>>>>> mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
>>>>> таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
>>>>> корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
>>>>> но по факту никак не работает. Система не грузится даже с только что
>>>>> созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
>>>>> что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
>>>>> (это уже про ситуацию, когда LVM поверх MD).
>>>>>
>>>>> Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
>>>>> этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
>>>>> не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
>>>>> известно. Есть какие-нибудь идеи, камрады?
>>>> Вы много написали, но я явно не в контекте. Давайте по порядку.
>>>>
>>>> Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
>>>>
>>>> Он решает проблему и не решает какую проблему ?
>>>> Какие ещё проблемы есть ?
>>> Не решает ни одну из двух проблем:
>> ok. Значит он перестал работать совсем.
>>
>> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
>> должно выглядеть. А вот с read-auto сложнее. Что это ?
>>
>> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
>> новые end-to-end тесты) ?
>>
>>> - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
>>> stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
>>>
>>> - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
>>> MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
>>> сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
>>> старой версии отрабатывал troubleshutter by mike@, который я перетянул из
>>> p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
>>> тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
>>>
>>> В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
>>> блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
>>> исправить приведёнными командами. Очевидно, обработка должна находиться не
>>> здесь, а где-то ещё.
>>>
>>> Сейчас я воспроизведу на виртуалке и отпишу более детально...
>> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
>> было посмотреть.
>>
>> -- 
>> Rgrds, legion
>>
>> _______________________________________________
>> Make-initrd mailing list
>> Make-initrd@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/make-initrd

-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 20:30         ` Michael A. Kangin
@ 2020-02-27 21:35           ` Leonid Krivoshein
  2020-02-27 22:05           ` Alexey Gladkov
  2020-03-06 20:32           ` Michael Shigorin
  2 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 21:35 UTC (permalink / raw)
  To: make-initrd


27.02.2020 23:30, Michael A. Kangin пишет:
> On 2/27/20 9:10 PM, Alex Gladkov wrote:
>
>> Также бага [1] открыла ещё одну проблему, которую не очень понятно как
>> лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
>> целый букет разных рейдов, то все они попадут в initrd, но при этом 
>> initrd
>> не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
>> mdadm.conf в такой ситуации у меня нет.
>
> не знаю, насколько кривенько, но можно распарсить вывод:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')
>
> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
>

Мне кажется, все рейды должны быть собраны и починены полностью до 
перехода в stage2.
Забыл ещё сказать, что именно перед переходом в stage2, когда они 
наконец собрались, можно попробовать полечить состояние read-auto.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  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-03-06 20:32           ` Michael Shigorin
  2 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 22:05 UTC (permalink / raw)
  To: make-initrd

On Thu, Feb 27, 2020 at 09:30:53PM +0100, Michael A. Kangin wrote:
> On 2/27/20 9:10 PM, Alex Gladkov wrote:
> 
> > Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> > лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> > целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> > не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> > mdadm.conf в такой ситуации у меня нет.
> 
> не знаю, насколько кривенько, но можно распарсить вывод:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')

Нет проблем найти имя рутового устройства и определить, что это рейд.

> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf

mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
рутового устройства.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 22:05           ` Alexey Gladkov
@ 2020-02-27 22:12             ` Michael A. Kangin
  2020-02-27 23:34               ` Alexey Gladkov
  0 siblings, 1 reply; 21+ messages in thread
From: Michael A. Kangin @ 2020-02-27 22:12 UTC (permalink / raw)
  To: make-initrd

On 2/27/20 11:05 PM, Alexey Gladkov wrote:

> Нет проблем найти имя рутового устройства и определить, что это рейд.

рейд на зашифрованном разделе поверх lvm поверх bcache поверх md - норм? ;)

>> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
> 
> mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
> нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
> рутового устройства.

А будет проблемой, если попадёт лишнее, но кроме ARRAY?
типа,
grep -v "^ARRAY" /etc/mdadm.conf
grep "^ARRAY $MY_MD_DEVICE" /etc/mdadm.conf


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 21:26         ` Leonid Krivoshein
@ 2020-02-27 23:27           ` Alexey Gladkov
  2020-02-28  0:17             ` Leonid Krivoshein
  0 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 23:27 UTC (permalink / raw)
  To: make-initrd

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



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 22:12             ` Michael A. Kangin
@ 2020-02-27 23:34               ` Alexey Gladkov
  0 siblings, 0 replies; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 23:34 UTC (permalink / raw)
  To: make-initrd

On Thu, Feb 27, 2020 at 11:12:28PM +0100, Michael A. Kangin wrote:
> On 2/27/20 11:05 PM, Alexey Gladkov wrote:
> 
> > Нет проблем найти имя рутового устройства и определить, что это рейд.
> 
> рейд на зашифрованном разделе поверх lvm поверх bcache поверх md - норм? ;)

bcache не поддерживается [1]. А usb->raid->lvm->luks->... да, норм.
Вы, видимо, не знаете как работает make-initrd.

[1] https://bugzilla.altlinux.org/show_bug.cgi?id=29561

> > > найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
> > 
> > mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
> > нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
> > рутового устройства.
> 
> А будет проблемой, если попадёт лишнее, но кроме ARRAY?
> типа,
> grep -v "^ARRAY" /etc/mdadm.conf
> grep "^ARRAY $MY_MD_DEVICE" /etc/mdadm.conf

Я об этом и писал. Да, я боюсь это будет проблемой. Если я ошибаюсь, это
нужно проверять.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 23:27           ` Alexey Gladkov
@ 2020-02-28  0:17             ` Leonid Krivoshein
  2020-02-28 13:33               ` Alexey Gladkov
  0 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-28  0:17 UTC (permalink / raw)
  To: make-initrd


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.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-28  0:17             ` Leonid Krivoshein
@ 2020-02-28 13:33               ` Alexey Gladkov
  2020-02-28 21:43                 ` Leonid Krivoshein
  0 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-28 13:33 UTC (permalink / raw)
  To: 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



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-28 13:33               ` Alexey Gladkov
@ 2020-02-28 21:43                 ` Leonid Krivoshein
  2020-02-28 23:39                   ` Alexey Gladkov
  0 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-28 21:43 UTC (permalink / raw)
  To: make-initrd



28.02.2020 16:33, Alexey Gladkov пишет:
> On Fri, Feb 28, 2020 at 03:17:12AM +0300, Leonid Krivoshein wrote:
>>> [...]
>> Но главный аргумент в другом: желательно собрать рейды до перехода в
>> корень и сразу починить ситуацию с read-auto. Если этого не сделать, всё
>> равно нормально система не загрузится.
> Если корень собран, то загрузится. Если в корне лежит не всё, что нужно
> для закрузки, то это неправильная конфигурация.

В корне есть всё, чтобы начать процесс загрузки. ELF, которому ты 
передаёшь управления по выходу из stage1 (ну хорошо, ядро передаёт) -- 
это пресловутый systemd, а о том, что в конфигурации что-то не так, 
админ узнает только когда отъедет рейд. И не факт, что к этому моменту 
будет сеть или запущен ssh. Я это частенько вижу -- есть только 
локальный рутовый доступ и страшная сага о невозможности запуска 
некоторой службы.


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

Отлично, уже хлеб!


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

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


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

Так а по факту сейчас получается наоборот. Бери в расчёт не стадию 
выхода из stage1, а хотя бы ту стадию, когда будет доступен вход снаружи 
по ssh. Это ещё не конец загрузки, но при отъезде рейдов, и до неё можно 
не дотянуть.


> Ты, видимо, никогда не чинил сервера удалённо через суппорт сервис ...

Слава богу! Но в данном случае лучше попробовать починить сборку рейдов 
в stage1, чем застрять в самом начале stage2. Иначе шансы иметь дело с 
удалённым саппортом будут намного выше.


>> Рабочий корень это ещё не средство для ремонта.
> Ты ошибаешься. Для этого у нас есть деление на /bin, /sbin и /usr .

Я имел ввиду, что рабочий корень ещё не панацея, с него нельзя починить 
все мыслимые поломки в дисковой подсистеме. Для удалённых ремонтов 
сейчас есть IPMI, BMC, iLO и прочие приблуды, в конце концов.


> Только не нужно мне рассказывать о моих коллегах, которые всё
> перенесли в /usr.
>
>> Но если уж так совсем боязно, можно
>> предусмотреть загрузочную опцию типа NO_REPAIR=1 и писать о ней в конце при
>> невозможности авто-ремонта.
> Вот подумай, как ты сможешь ввести этот параметр, если ты _уже_ не смог
> загрузиться ? Поедешь не площадку к серверу, чтобы этот параметр ввести ?

Нужна рабочая консоль. Хоть локальная, хоть удалённая. На современных 
серверах этого добра хватает.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-28 21:43                 ` Leonid Krivoshein
@ 2020-02-28 23:39                   ` Alexey Gladkov
  0 siblings, 0 replies; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-28 23:39 UTC (permalink / raw)
  To: make-initrd

On Sat, Feb 29, 2020 at 12:43:37AM +0300, Leonid Krivoshein wrote:
> В корне есть всё, чтобы начать процесс загрузки. ELF, которому ты передаёшь
> управления по выходу из stage1 (ну хорошо, ядро передаёт) -- это пресловутый
> systemd, а о том, что в конфигурации что-то не так, админ узнает только
> когда отъедет рейд. И не факт, что к этому моменту будет сеть или запущен
> ssh. Я это частенько вижу -- есть только локальный рутовый доступ и страшная
> сага о невозможности запуска некоторой службы.

Не нужно ждать пока отъедет рейд. Для этого есть инструменты.

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

Не нужно реплицировать страницы памяти по дискам. Я убеждён, что тот кто
так делает явно не понимает что такое swap.

> > Рейд как раз и нужен для того чтобы загрузится если диск вылетел.
> 
> Так а по факту сейчас получается наоборот. Бери в расчёт не стадию выхода из
> stage1, а хотя бы ту стадию, когда будет доступен вход снаружи по ssh. Это
> ещё не конец загрузки, но при отъезде рейдов, и до неё можно не дотянуть.

Смотри, есть разделение стадий загрузки. Обычно initrd нужен для того
чтобы использовать расширенные схемы загрузки корня. Все же помнят, что он
опционален. Initrd перестаёт существовать перед передачей управления
системному init.

Чтобы было ясно: я не против выполнения дополнительной функциональности в
момент выполнения initrd, но не нужно на этот _хэлпер_ перекладывать
ответственность за остальную систему. Я готов добавить фичи, которые
приведут к тому поведению, которое ты описываешь, но это не будет
поведением по умолчанию.

Ты мне говоришь, что кто-то делает конфигурации, которые не жизнеспособны
без внешней помощи. Я готов допустить, что есть такие сумрачные гении,
которые вынесли важную часть загрузки из рута с полным набором системных
утилит в initrd, где нет всех инструментов. Это ответственность этих
гениев. Я не хочу им мешать.

> > Ты, видимо, никогда не чинил сервера удалённо через суппорт сервис ...
> 
> Слава богу! Но в данном случае лучше попробовать починить сборку рейдов в
> stage1, чем застрять в самом начале stage2. Иначе шансы иметь дело с
> удалённым саппортом будут намного выше.

Я не хочу тебе мешать. Я уже сказал, что есть опция для ожидания
нескольких точек монтирования. Возможно нужны будут ещё какие-нибудь
опции.

> Я имел ввиду, что рабочий корень ещё не панацея, с него нельзя починить все
> мыслимые поломки в дисковой подсистеме.

В initrd их ещё меньше.

> Для удалённых ремонтов сейчас есть IPMI, BMC, iLO и прочие приблуды, в
> конце концов.

Я пользовался ими. Больше не хочу испытывать этот чудесный опыт.

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

Ты можешь указать raid-member-delay=0 при загрузке, чтобы выключить
mdadm -IRs (пока я не изучал вопрос с read-auto и не рассматриваю эту
проблему тут). В этом случае ты будешь ждать rootdelay= время пока
появятся все диски и соберутся все рейды из MOUNTPOINTS.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
  2020-02-27 20:30         ` Michael A. Kangin
  2020-02-27 21:35           ` Leonid Krivoshein
  2020-02-27 22:05           ` Alexey Gladkov
@ 2020-03-06 20:32           ` Michael Shigorin
  2 siblings, 0 replies; 21+ messages in thread
From: Michael Shigorin @ 2020-03-06 20:32 UTC (permalink / raw)
  To: make-initrd

On Thu, Feb 27, 2020 at 09:30:53PM +0100, Michael A. Kangin wrote:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')

В подобных случаях порой разбираю вывод чего-то вроде df / :)
Ну и вместо mount| скорее смотрю в /proc/mounts, если уж.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2020-03-06 20:32 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-17 11:27   ` [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе 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
2020-02-28 21:43                 ` Leonid Krivoshein
2020-02-28 23:39                   ` Alexey Gladkov

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