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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=5qY2ehbzoYX62JHuNxfEQLZ2V7/bERayLNGl0YP3yLA=; b=hy8tDtwE7BF8R1YBDv3ixUz0SgeEse7kT6HmZG19Iv4dB2Am91xAO7L0tbK6eGvrvX Oq9SmdfZEgCSGDrNrpUAG9xbcemOUztQmCQUmQzLmqzBoB8M/H1lYjrh/UTvLVIUYSkn loOcKn+klvqm2inkjdw9/lj8oicW/2Bd7qby9AnUlyFDi6bFmLGWtgnV6StDkkwT8kKm PGbHKZicp0HQcl7NZQa82FGEAeKgjnkqJsnKCgOI6wYiXcMoZPGAN2Ig29ZL1aBeuSbs DuenujLIBZQVXnQv9GqAR0McCIQDH1+vk+ZgnLvtCyygy9Pt/pi4X4Zo8e0yuyXVRAwO AgrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5qY2ehbzoYX62JHuNxfEQLZ2V7/bERayLNGl0YP3yLA=; b=VAUTyEAulLKcxmWgoCgxqMp5c5HT0vrAs+1aS8b8EiVxqRCdiEak7ECGVElC1IfiXp Csrbp8TU73SpOcYcTfE664XoUQD1Q7TOEkATM8U1Sv6P84/YbRGb19j6lBNSSvTXlqrF Uxc1JDM/M38eHH913QVmL0aIzGBYYqkZ2e0rYjV8zmDf1B6VADftMFF6kGOrxDgU4WBC PqHpn/NjWiUx37UjT+PjBdi9QV8H8h0/oxd1p/mh9/hHT/+ymFcDnRn67XwjOpQwXHsc K3sN2j/tviTEOhIuWzBJ5+CMP8mjjlJdF5E3/x60qv4JFZVdNCcX6XPAVZUyTxQvEbmn CNwQ== X-Gm-Message-State: ANhLgQ3Y2ri8J1/93MhcKIE1ztl1covw1g746C/7suXlfywWxifx4XI4 z7uxi5qIpc/vp5whcT762pw+hl/h X-Google-Smtp-Source: ADFU+vtHEG97qGSp1dvePdu19KWKWwVHEMrwCNWOlnwrK1dJiQF4cu0yfpVFnRL/Nor/ojTa/jJgLw== X-Received: by 2002:a05:6512:145:: with SMTP id m5mr738089lfo.87.1582839085286; Thu, 27 Feb 2020 13:31:25 -0800 (PST) To: make-initrd@lists.altlinux.org References: <20200217104230.m2t7xvp4pv2f2lyq@comp-core-i7-2640m-0182e6> <20200217152312.suvw3d3snuquenfz@comp-core-i7-2640m-0182e6> <20200227201003.mjh46m7ibmk4vkpf@comp-core-i7-2640m-0182e6> From: Leonid Krivoshein Message-ID: <14676039-c12b-489f-2b8f-e9deaaeb5519@gmail.com> Date: Fri, 28 Feb 2020 00:26:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20200227201003.mjh46m7ibmk4vkpf@comp-core-i7-2640m-0182e6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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 21:31:29 -0000 Archived-At: List-Archive: Доброй ночи! 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.