From: Leonid Krivoshein <klark.devel@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 02:00:33 +0300 Message-ID: <fc081e31-fdfb-9385-44df-3d03633c5162@gmail.com> (raw) In-Reply-To: <20210406190532.ujqp7edd3niul4n6@example.org> 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.
next prev parent reply other threads:[~2021-04-06 23:00 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 [this message] 2021-04-07 12:11 ` Alexey Gladkov 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=fc081e31-fdfb-9385-44df-3d03633c5162@gmail.com \ --to=klark.devel@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