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

[Alexey Gladkov]

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