Make-initrd development discussion
 help / color / mirror / Atom feed
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.



  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