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=MaNXUJNdQcxm3yPyzlQ2YJBL6uSYTS7ATrcG/j2zZP8=; b=X1MukSqap5Z9w8/bIagydr7DR2ouNYgCX0dKORzXGfHXihmBvwaaNQ89FxyoSTXF+n kX8iey1qCGOfl/QGMu/wOgtu9J2gcUZ2Upipr6GR3/kQ9QYRROrvdzvT+uFUmT6D+tKE 8gt6XMasatX343ZORd+YTj6tnd8M67MAlz2LRH/qYw9K3rILXn91eoX/ydsn8xPc6yzd IjmvTwffwtfK3X7X6lz+TLATjWYfiYO45smAU0oWXEYq+btqektSSw7wjqPinfJXOqZF /l2MwA2jzudLaK880XacZ5+xI1xR1m3QJsMhDDgSl+MCJvCZMbp1DFCR111oopGnvWrQ uOUA== 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=MaNXUJNdQcxm3yPyzlQ2YJBL6uSYTS7ATrcG/j2zZP8=; b=RUCVucYP0DKHCBbHPNgUQRKkkHuJk2pAUdFd5Of8ss+MYM+9GBGy2aHKcf7Jyw+eL7 iFOoHjBJe4H0+jePTdkTWa4YcWcVJsm18EX+YQjVJszk6VRLW6QjoVvvHDNqj2v5jdgG XdwMjkrRs1xxdAsmGMVw6zmqyiLh8bRygznZE5Ka1xP/shf05IoYaAa2mLiBtsoLdfo7 U861QRtpTxXxqn0Njk01EUSKztv9dc4JjaOQwYErt6kFmg0rN/RMqnCFEr3QdWU/vSAx jNRQZ+gVLT6dJ7tse8r+Lokn5T6g9MSdVIOiFfM78z2xfAo+dlBeScNhK2AFtY3eKFVC Yaeg== X-Gm-Message-State: ANhLgQ2GVW5dmo9ycwFXDdjX7d3RGQqpiCGqNI2tM1kS5qGsDpglli5s b/mNMKuxWSK+TH5cK5EtMdSnSO1J X-Google-Smtp-Source: ADFU+vv0hGwiUtmsZadVZnpUe2osuMO9DpTYxhu9CFj70j5I44sdFVqAvQrNXloWiH2glXPmXKHV+A== X-Received: by 2002:a05:6512:68b:: with SMTP id t11mr1038717lfe.214.1582849343063; Thu, 27 Feb 2020 16:22:23 -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> <14676039-c12b-489f-2b8f-e9deaaeb5519@gmail.com> <20200227232737.wqerot2yslzd3egz@comp-core-i7-2640m-0182e6> From: Leonid Krivoshein Message-ID: <3e3e05f2-0a8b-7885-58e4-2571fad8aaae@gmail.com> Date: Fri, 28 Feb 2020 03:17:12 +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: <20200227232737.wqerot2yslzd3egz@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: Fri, 28 Feb 2020 00:22:26 -0000 Archived-At: List-Archive: 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.