From: Alexey Gladkov <gladkov.alexey@gmail.com> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 Date: Wed, 7 Apr 2021 14:11:19 +0200 Message-ID: <20210407121119.zkzgignoarywbhfq@example.org> (raw) In-Reply-To: <fc081e31-fdfb-9385-44df-3d03633c5162@gmail.com> 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
next prev parent reply other threads:[~2021-04-07 12:11 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-05 20:33 ` Leonid Krivoshein 2021-04-05 22:51 ` Leonid Krivoshein 2021-04-06 8:44 ` Alexey Gladkov 2021-04-06 17:38 ` Leonid Krivoshein 2021-04-07 13:13 ` Alexey Gladkov 2021-04-06 8:28 ` Alexey Gladkov 2021-04-06 16:38 ` Leonid Krivoshein 2021-04-06 19:05 ` Alexey Gladkov 2021-04-06 19:30 ` Alexey Gladkov 2021-04-06 23:13 ` Leonid Krivoshein 2021-04-07 12:28 ` Alexey Gladkov 2021-04-06 23:00 ` Leonid Krivoshein 2021-04-07 12:11 ` Alexey Gladkov [this message] 2021-04-06 23:59 ` Leonid Krivoshein 2021-04-07 1:51 ` Leonid Krivoshein 2021-04-07 12:57 ` Alexey Gladkov 2021-04-07 18:29 ` Leonid Krivoshein 2021-05-26 15:05 ` Leonid Krivoshein 2021-05-26 18:12 ` Alexey Gladkov 2021-05-26 19:25 ` Leonid Krivoshein 2021-05-27 8:37 ` Alexey Gladkov 2021-05-27 12:29 ` Leonid Krivoshein 2021-05-27 13:53 ` Alexey Gladkov 2021-05-27 15:10 ` Leonid Krivoshein 2021-05-27 17:04 ` Alexey Gladkov 2021-05-27 17:11 ` Leonid Krivoshein 2021-05-30 20:34 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210407121119.zkzgignoarywbhfq@example.org \ --to=gladkov.alexey@gmail.com \ --cc=make-initrd@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git