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=fZazCDSq2g45XgcrfE1o73COXxmasvPSL3GR5xpd4gc=; b=mfXltyfWjI7w6zT+/W3EYdJu2AI7oKrV/mADIDAshyPnXJ0qD5+uRaYRVbCk7EBAsA Zr7Ci9FfhjtAT8Cv8XHeCG5Lc1hJr8cvd+QRuOm/sO7HO+QsXmsUxUhN9BSsrtuMUNs2 vxGYaASQF4bUCLmOFRy0eKlFt4obaICEmlCVYuTVJCycz6zNx7KU3DrcMc4actbO9rRn f6IQXseirJgnbbIDkgNtyS7MB3DGfuUK8L5oI969v1KX33rUSDgd6fGAyJRE5qZLioPZ t1GNHr5UzCCTgkR4OD3O9x3qSexCLzn3pJ1WA3MGGh/fqSDLJ3CHAa6kpw4e+QzT9IMk aUaA== 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=fZazCDSq2g45XgcrfE1o73COXxmasvPSL3GR5xpd4gc=; b=t8QDTzTYjR2PC+D6iV74qy2IUDXZKzYk2JFmpvgIi/STE/prII+Qwz3f+DutMXXpKM wMBEJtL5ZxN2wWMXB3QsFAEyJWSG3olcgpu6KZrhgceKe5g7/adDnzEnt166QbV4CMSR KFPkRRuZ/RdQ8quvZnFJAXHTCcxiWBsD8H373L6TeiuLUgbnMxjWRQxJvLTueN3xeKA9 vGFzvyC2/KxGkj4EJoOsoPMaooDXoKuP74+i7qq17v3m8qzEINxxZ2s0PEIhy9vkRJ9M TYtzHv33IzIFMgO7oo7T//C5TiP+/csbunTAKvZuDtuXCVagibzhDsdwrdFt6KdtMfra pfYQ== X-Gm-Message-State: AOAM532Hk6Frg26vwkYmxghHwznFD5YTdvlGa+kNHnV9HwYNiIrdzNWJ FVjkkm9k+I09GK32I/TXUJUA0/0mPM0= X-Google-Smtp-Source: ABdhPJyRHWnvryGEb8I7U4EBlz3XV8+7hrVgcDXF1bC4Ld7t33DLFvnaG2anDb5RLK9JSLtlSgLddg== X-Received: by 2002:a05:6512:3b98:: with SMTP id g24mr325580lfv.103.1617750034824; Tue, 06 Apr 2021 16:00:34 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20210406082842.pg3rejmmnxuxvddf@example.org> <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> <20210406190532.ujqp7edd3niul4n6@example.org> From: Leonid Krivoshein Message-ID: Date: Wed, 7 Apr 2021 02:00:33 +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: <20210406190532.ujqp7edd3niul4n6@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 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: Tue, 06 Apr 2021 23:00:38 -0000 Archived-At: List-Archive: 06.04.2021 22:05, Alexey Gladkov пишет: > [...] > Если это так бомбит, то можно использовать /run или смонтировать в > /dev/pipeline ещё одну tmpfs. Хотя это всё та же память и просто > добавляется точка монтирования. Бомбит возможность записывать в /dev большие объёмы данных без ограничений на их размер и вообще использовать /dev не по назначению. Да, для всех не-устройств /run более подходящее место, но я не уверен, что для какой-либо цепочки pipeline вообще нужно что-либо переносить целиком в stage2, кроме $rootmnt и возможно других одной-пары точек монтирования из initramfs. В случае пропагатора переносятся только две: /image и /root, остальное находится в /dev/ramN. > [...] >> оставлять что-либо в /dev/pipeline или /dev/.initrd (как раньше) -- нет, >> только что-то совсем небольшое и лучше в /run. Говорю как пользователь >> твоего продукта, как следует его "пощупав". )) > Вот бы вы "щупали" не спустя год после создания фичи )) Неужели уже год прошёл!? Ну, прости, был сильно занят! :-) А ещё я обещал с документированием подсобить, и тоже руки не дошли. Но это и хорошо, сначала надо самому как следует разобраться. > [...] > В пропагаторе всё делалось внахлёст, потому что это монолитный скрипт. Думаю, что нет, попробую по другому объяснить (ниже). >>> Затруднительно >>> даже поменять порядок внутри уже реализованного. >> Если реализуется отдельными шагами, как сейчас, не вижу проблем. > Я вижу :) > >>> В такой парадигме только >>> такой же монолит будет работать также. >> В рамках pipeline не выйдет реализовать монолит, я пытался. > Я старался, чтобы не получилось (шучу). > >> А вот разбить на части удалось. Их можно переставлять, перемешивать с >> нативными. > Я как раз и надеялся, что будет произведена декомпозиция пропагатора. Да, > это непростая работа. Мне эта идея с декомпозицией как раз нравится. >> Основное: я считаю, что шаг может использовать каталоги, предоставляемые >> pipeline, но не обязан этого делать, он с тем же успехом может делать нужное >> в initramfs. > Да. Именно так. Отлично! Именно так сейчас и реализованы шаги замены пропагатора с монтированием внахлёст. >> Потому что задача initramfs -- добраться до корня и >> самоуничтожиться, а задача pipeline -- предоставить шагам логичный интерфейс >> для этого. Конечный результат переносится в $rootmnt, нынешняя реализация >> заставляет тянуть в будущий корень промежуточные звенья всей pipeline, а они >> там могут быть совсем не нужны, по крайней мере, заранее ты этого не можешь >> знать. > Вот именно потому что я не могу знать нужны или нет все звенья я их > переношу в систему. Ты всегда можешь сделать шаг prune и параметром (или > ещё как-нибудь) указать ему какие стадии удалить. Какой подход к проблеме не выбери, задача цепочки -- собрать нужное и перетащить в stage2. Шагом rootfs ты сейчас говоришь, что из цепочки надо перетащить в /root для stage2, остальное перетащится вообще всё. При текущем подходе по умолчанию перетаскивается всё, включая ненужное, и надо сделать prune для очистки. В предлагаемом подходе потребуется альтернатива переноса только нужного. Например, это может быть шаг rootfs. Между подходами почти нет разницы, кроме одного: строителю цепочки видней, что надо перетаскивать, поэтому не стоит перетаскивать всё по умолчанию. Можно пойти и другим путём: использовать /{dev,run}/pipeline/ для размещения там только того, что действительно должно попасть в stage2. Я бы размещал на "входе" devname, вместо самих устройств и симлинки на каталоги, чтобы избавиться от длинных путей в mtab. Для наглядности. Вот этот код будет работать при обеих подходах: mount -t nfs -o ro,soft,nolock IP:/path/to/images /root mount -t iso9660 -o ro,loop /root/path/to/ISO /image dd if=/image/rescue of=/dev/ram3 bs=32 umount /image /root mount /dev/ram3 /root Для реализации текущим способом придётся делать prune, иначе всё это (ненужное) попадёт в stage2. А нужен здесь только результат последнего шага. В предлагаемом подходе при переходе в stage2 ненужное отмонтируется, а всё лишнее из initramfs вычистится автоматом. Разница в подходах будет также видна в путях как к устройствам, так и к смонтированным каталогам. В предлагаемом подходе последняя строчка /proc/mounts: /dev/ram3 /root squashfs ro,... Что выглядит привычно и интуитивно понятно. В имеющемся это сейчас выглядит примерно так: /dev/pipeline/dst/pipe3/dev /dev/pipeline/dst/pipe5 squashfs ro,.. Ну да, здесь по файловой системе ещё можно догадаться. Но если похожих будет много, это уже начинает приводить в замешательство. Что касается монтирования внахлёст, то код: mount ... /root mount ... /root mount ... /root чудесно работает и не вызывает проблем, если по сути нужен результат только предыдущего шага, а результаты предыдущих шагов в конечном итоге не потребуются в stage2. Так что подходы вполне можно комбинировать, но предпочтительно использовать симлинки и передавать названия устройств вместо создания самих устройств. Да и просто симлинками можно решить все проблемы этого интерфейса. -- Best regards, Leonid Krivoshein.