> Они просто сверхнадежно и свердолго работают в readonly режиме (внезапно да), да
> еще и быстро (потому что чтение происходит с уже сжатых образов
> (xz или zstd с блоком размером 1Мб)) Я на такие btrfs с схемой dup (2 копии блоков на 1 девайсе) кладу. Емкость ополовинивается, зато утечку заряда переживает, а чексуммы позволяют понимать насколько этому пора в мусор - ДО того как развалится. Можно и readonly делать. А можно и read-write. Один флаг на снапшот сменить. Удобно. Поставил апдейты и сделал readonly опять.
Если надо, из оригинала снапшота можно отрастить целое дерево альтернативных вариантов развития системы. Записываемых, или не очень. Сабж к этому и пришел.
> и совершенно плохо работают (может потеряться целый раздел при обычном ребуте кнопкой
> системника) или внезапно дохнут в rw режиме (TLC имеет, насколько помню,
Это если партишн класть в тот же eraseblock что активно ворочаемую файлуху. Лечится отступом от начала девайса на 32-64 мега, чтобы блок с партишном контроллер не трогал при записях. Смотрите как фабричные ФС сделаны до того как сносить, увидите.
> только 1000 циклов перезаписи). А дефолтно настроенная работающая система любит обязательно
> что-то писать + btrfs имеет неразумный write amplification
1. Какой write amplification в readonly варианте?! :)
2. Если надо апдейты накатить, можно временно снять ридонли и порулить как обычно, а не вон те танцы.
3. CoW удобен для хренового FTL в таких флешках - даже если он лажанет, CoW размазывает записи по площади сам, он не протирает одни и те же блоки.
> Так доразвивать ничего вроде и не надо. Это и была изначальная задумка,
> как еще одна реализация docker-подобных технологий.
Докер не про это как таковой. Это ни о чем без эффективного backing storage способного на такую семантику. Без этого операция будет медленной и дорогой, по поводу чего и не использовалось особо. Вы же не будете "честно" копировать инсталл ОС при каждом запуске сервиса и стирать потом? Докер сам по себе с этим ничего не сделает, без CoW очень дорогая операция выходит.
> Там просто, чтобы это взлетело, еще ненаписан модуль systemd-backupd, надо только подождать.
Снапшоты - не бэкапы: всего 1 бэд и вся пачка снапшотов ссылающихся на это место в ауте.
> В следующих версиях Fedora будем весело это испытывать и готовить технологию
> для Enterprize.
Это вы там сами как-нибудь.
> багрепортописатель все равно не получит свой файл диплома, но зато хоть
> какая-то отрада для души будет).
У меня данные не теряются, тьфу-тьфу. Я их даже другим восстанавливаю иногда.
>>> Даже стирание кернела в /boot обыграть можно, однако
> Это прикольно? Или зачем так делать?
Позволяет откатить откровенно фатальную в более примитивных конфигах ситуацию - менеджмент ОС "почти как на виртуалке". В том числе и по возможности передумать и вернуть как было. Мне пригодилось когда в новом снапшоте кернел как оказалось расстыковался с модулями. Кернел при этом был, но радости, если у него модули отавалились? Он даже блочный девайс зацепить не мог и это почти как вон то. Но можно прямо из GRUB зацепить снапшот в котором ЭТОГО еще не было, читанув его initrd и kernel и (если надо) уточнив кернелу что мы хотим как рутфс именно этот снапшот.
