From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 7 Apr 2021 14:11:19 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210407121119.zkzgignoarywbhfq@example.org> References: <20210406082842.pg3rejmmnxuxvddf@example.org> <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> <20210406190532.ujqp7edd3niul4n6@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Wed, 07 Apr 2021 12:11:21 -0000 Archived-At: List-Archive: On Wed, Apr 07, 2021 at 02:00:33AM +0300, Leonid Krivoshein wrote: > 06.04.2021 22:05, Alexey Gladkov пишет: > > Если это так бомбит, то можно использовать /run или смонтировать в > > /dev/pipeline ещё одну tmpfs. Хотя это всё та же память и просто > > добавляется точка монтирования. > > Бомбит возможность записывать в /dev большие объёмы данных без ограничений > на их размер и вообще использовать /dev не по назначению. Да, для всех > не-устройств /run более подходящее место, но я не уверен, что для какой-либо > цепочки pipeline вообще нужно что-либо переносить целиком в stage2, кроме > $rootmnt и возможно других одной-пары точек монтирования из initramfs. В > случае пропагатора переносятся только две: /image и /root, остальное > находится в /dev/ramN. Я вижу ты очень любишь /dev/ramN. Есть разница между ramdisk и tmpfs. Помимо этих различий ramN ограниченное количество и их нужно будет соотносить с шагами. tmpfs проще монтировать. > > Вот именно потому что я не могу знать нужны или нет все звенья я их > > переношу в систему. Ты всегда можешь сделать шаг 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,... Плевать, что написано в /proc/mounts. > Что выглядит привычно и интуитивно понятно. В имеющемся это сейчас выглядит > примерно так: > > /dev/pipeline/dst/pipe3/dev /dev/pipeline/dst/pipe5 squashfs ro,.. > > Ну да, здесь по файловой системе ещё можно догадаться. Но если похожих будет > много, это уже начинает приводить в замешательство. Пожалуйста, не надо это приводить в качестве аргумента. /proc/mounts это служебный файл. Там системная информация, а не красивости. А то так мы дойдём до юникодных human-readable названий "чтобы было понятно" или стихов вместо имени устройства. > Что касается монтирования внахлёст, то код: > > mount ... /root > mount ... /root > mount ... /root > > чудесно работает и не вызывает проблем, Ты почему-то игнорируешь юскейс c overlayfs. Расскажи, как просто будет сделать шаг с подобным подходом ? Пожалуйста учитывай, что любые изменения должны покрывать всё то, что уже реализовано. -- Rgrds, legion