Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1

[Leonid Krivoshein <klark.devel@gmail.com>]

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.