[странное] [глобально и надежно] посоветуйте правильную связку технологий

Я надеюсь в твоём понимании ПЗУ /= BIOS ROM?

вряд ли

Нет, в моем понимании это Постоянное Запоминающее Устройство.
Ибо обозвать SSD НЖМД не получится.

ээ.. tmpfs?

собственно такое, например, любят делать с кэшом фокса и хромиума.

При логине в .cache монтируется tmpfs, в него распаковывается сохраненная копия, начинается работа. при логауте кэш копируется на жесткий диск, .cache отмонтируется.

особенно это актуально для ноутбуков, где браузер, как правило, один из самых активных процессов, дергающих диск.

Так вот теперь представь себе извращенца, который хочет проделать это со всей системой, а не только с фф и темпами.

ну так в чем проблема?

делаешь раздел с тмпфс, распаковываешь туда корень, перемонтируешь корень. при логауте пакуешь корень на диск.

Будет дольше включаться и выключаться, но кто вообще выключает компьютер? особенно если в нем вагон и тележка памяти?

SSD задрочится довольно быстро. Мне почему-то казалось, что в зоопарке фс обязательно найдется что-то, что позволит делать инкрементальные апдейты исходных образов, а не копипастить каждый раз все и сразу

Можно сделать оверлей tmpfs, объединив его с обычной файловой системой, смонтированной в read-only, с помощью aufs. Тогда загрузка почти не замедлится ничего заранее в tmpfs не копируется. При выключении вместо halt -f или reboot -f надо делать какой-нибудь chroot в специальную ФС вроде initrd, загруженную в ещё один tmpfs с диска, и из неё взять все файлы из первой tmpfs и скопировать на обычную ФС. Из минусов — нельзя удалять файлы.

Только зачем всё это? ФС, кроме /home и /var, изменяются только при обновлениях. После обновления один фиг надо записывать изменения. Можно просто помонтировать всё в read-only, а при использовании пакетного менеджера перемонтировать в read-write. При таком подходе сделать /var в tmpfs с синхронизацией будет проще.

aufs

http://cmrg.fifthhorseman.net/wiki/debirf

ФС, кроме /home и /var, изменяются только при обновлениях

у меня Arch. :)
Насчет aufs спасибо, почитаю.

YAFFS2/JFFS2?

вся работа системы происходила в рамдиске с каким-либо оверлеем, без обращения к ПЗУ
хочу ПЗУ использовать только для собственно хранения статических данных, не задрачивая медленный девайс не по делу

Казалось бы, кэш файловой системы ровно этим и занимается. Никаких дополнительных извращений не нужно.

- вся работа системы происходила в рамдиске с каким-либо оверлеем, без обращения к ПЗУ
- при завершении работы все это сохранялось в ПЗУ

lvconvert --snapshot / lvconvert --merge не?

squashfs+aufs.

сквош же ридонли?

ээ.. tmpfs?
собственно такое, например, любят делать с кэшом фокса и хромиума.

Вопрос знатокам: не проще ли в подобных случаях вообще выключать дисковый кэш, выкрутив, сколько надо, «оперативного»? Зачем такие приложения будут морочить системе голову с записью в файлы, для которых она должна будет эмулировать харддиск в оперативке? Лишние же сущности...

Кстати, да, тоже интересный аспект. Этим блочным девайсам, которые будут в раме, кэширование же не нужно.

Купи себе что-то типа такого и воткни в него свои планки памяти. Зачем лишний раз городить костыли под линуксом?