From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 00:27:37 +0100 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20200227232737.wqerot2yslzd3egz@comp-core-i7-2640m-0182e6> References: <20200217104230.m2t7xvp4pv2f2lyq@comp-core-i7-2640m-0182e6> <20200217152312.suvw3d3snuquenfz@comp-core-i7-2640m-0182e6> <20200227201003.mjh46m7ibmk4vkpf@comp-core-i7-2640m-0182e6> <14676039-c12b-489f-2b8f-e9deaaeb5519@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14676039-c12b-489f-2b8f-e9deaaeb5519@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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 23:27:41 -0000 Archived-At: List-Archive: 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