From: Leonid Krivoshein <klark.devel@gmail.com> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе Date: Fri, 28 Feb 2020 03:17:12 +0300 Message-ID: <3e3e05f2-0a8b-7885-58e4-2571fad8aaae@gmail.com> (raw) In-Reply-To: <20200227232737.wqerot2yslzd3egz@comp-core-i7-2640m-0182e6> 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.
next prev parent reply other threads:[~2020-02-28 0:17 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 [this message] 2020-02-28 13:33 ` Alexey Gladkov 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=3e3e05f2-0a8b-7885-58e4-2571fad8aaae@gmail.com \ --to=klark.devel@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