Persistence Internals ru

Внутренняя реализация персистентности

На этой странице объясняются perch, perchdir, perchmode, perchsize, perchreserve, perchencrypt, perchcomp, и perchtoram параметры загрузки. Эти параметры определяют, где сохраняются изменения из live-сессии, как создаётся новая сессия и копируется ли поддерживаемое хранилище сессии в RAM. Для обычного использования выберите пункт с персистентностью в загрузочном меню или воспользуйтесь Менеджер сессий MiniOS вместо ручного редактирования параметров.

MiniOS формирует live root из модулей только для чтения и одного верхнего слоя с возможностью записи. initrd определяет, будет ли этот верхний слой пронумерованной персистентной сессией или временным каталогом в RAM. На этой странице описывается, как принимается это решение во время загрузки и как происходит активация. Для пользовательских настроек см. Режимы загрузки и Параметры загрузки.

Простыми словами

Без параметра персистентности MiniOS сохраняет изменения в RAM и удаляет их при завершении работы. Если задан параметр персистентности, MiniOS ищет доступное хранилище, выбирает или создаёт пронумерованную сессию, проверяет совместимость и использует эту сессию как слой для записи.

Запрос персистентности не гарантирует её активацию. Если целевое хранилище доступно только для чтения, заполнено, повреждено или несовместимо, MiniOS может продолжить работу с временным слоем RAM. Перед тем как полагаться на сохранённые изменения, обратите внимание на предупреждение при запуске.

Пояснение параметров

Параметр	Что обозначает MiniOS	Обычный выбор
perchdir=resume	Открывает стандартную совместимую сессию и, при поддерживаемых условиях, создаёт замену, если она недоступна.	Обычная ежедневная работа.
perchdir=setup	Интерактивный выбор хранилища для постоянства и поддерживаемых вариантов шифрования/сжатия, затем создание новой сессии с номером.	Текущий Начать новую сессию элемент загрузочного меню.
perchdir=new	Создать новую сессию с номером напрямую, используя выбранный/стандартный perchmode, шифрование, сжатие и размер, без отображения выбора хранилища.	Скриптовые или экспертные загрузочные записи с уже заданными параметрами хранения.
perchdir=ask	Показать сохранённые сессии и дать выбрать одну. Если в хранилище нет сохранённых сессий, выборщик запускает тот же процесс настройки, что и perchdir=setup.	Несколько рабочих пространств на одном устройстве, включая первое интерактивное создание на пустом хранилище.
perchdir=NUMBER	Запросить определённую сессию с номером.	Стабильная пользовательская загрузочная запись после проверки ID сессии.
perchmode=MODE	Выбрать native, dynfilefs, dynblk, vmdk, raw или squashfs.	Соответствует файловой системе и выбранной модели постоянства.
perchencrypt=luks	Добавить слой LUKS2 при создании сессии Raw, DynFileFS, DynBlk или VMDK.	Зашифровать поддерживаемое хранилище-контейнер.
perchsize=SIZE	Запросить размер новой или увеличиваемой сессии-контейнера.	DynFileFS, DynBlk, VMDK или raw; шифрование не влияет на семантику размера хранилища.
perchcomp=CODEC	Выбрать сжатие бэкенда DynBlk для вновь созданной сессии DynBlk.	none, lz4, lz4hc, lzo, lzo-rle, zstd, deflate или 842; доступность зависит от текущего ядра. Сжатие отключается, если LUKS оборачивает DynBlk.
perchreserve=MB	Вычесть запас при определении размера нового или увеличиваемого контейнера и задать порог предупреждения о нехватке места.	Оставляет рабочее пространство при выделении контейнера; это не ограничение в процессе работы.
perch	Использовать старое поведение восстановления без автоматического создания замены.	Совместимость с существующей пользовательской записью; рекомендуется perchdir=resume для текущих меню.
perchtoram=off, perchtoram=trim, perchtoram=full	Управлять копированием постоянства независимо от системы toram.	off сохраняет исходное хранилище активным; trim копирует только выбранную поддерживаемую сессию; full копирует все поддерживаемые контейнерные/сессии SquashFS.

Если запрошено постоянство, система toram делает perchtoram=trim это значением по умолчанию, если не указан явный режим постоянства RAM. Без системы toram, постоянство по умолчанию сохраняется на хранилище. Скопированная сессия не является надёжной во время работы, но текущий Session Manager может явно сохранить поддерживаемое состояние на базе RAM в исходное хранилище или опубликовать его как новую сессию, если исходное хранилище доступно и совпадает с идентификатором при загрузке.

Устойчивость включается явно

initrd включает обработку устойчивости только если в командной строке ядра присутствует один из этих распознаваемых токенов:

• perch
• perchdir=...
• perchmode=...
• perchencrypt=...
• perchsize=...
• perchcomp=...
• perchreserve=...

Если ни один из этих токенов не указан, включая случаи, когда присутствует только нераспознанное perch... имя, MiniOS создаёт новый доступный для записи upper в RAM. Все изменения, внесённые в этом сеансе, будут удалены при завершении работы.

Не все селекторы эквивалентны:

Селектор	Поведение initrd
perch	Пытается восстановить метаданные по умолчанию. Не создаёт сессию автоматически, если ни одна из них не подходит или не проходит проверку совместимости.
perchdir=resume	Пробует метаданные по умолчанию и может автоматически создать новую совместимую замену. Это текущее поведение восстановления из загрузочного меню.
perchdir=setup	Сначала открывает выбор бэкенда, фиксирует выбранные параметры бэкенда/шифрования/сжатия, затем переходит к созданию новой сессии.
perchdir=new	Выделяет каталог с числовым идентификатором, который на единицу больше самого большого существующего ID. Никогда не использует уже существующий каталог и не открывает выбор бэкенда.
perchdir=ask	Предлагает существующие сессии, если они есть; несовместимая сессия требует подтверждения. Если на хранилище нет сессии или значения по умолчанию, переключается на setup чтобы первую сессию можно было создать вручную.
perchdir=NUMBER	Использует этот каталог, если он существует. Если его нет, выбор может вернуться к значению по умолчанию, записанному в метаданных; не резервирует запрошенный номер.

Другие распознаваемые параметры устойчивости без селектора переходят по тому же устаревшему пути восстановления, что и простой perch: они запрашивают устойчивость, но не включают автоматическое создание.perchtoram сам по себе не является запросом на устойчивость. Если выбор или активация не могут создать рабочий upper, загрузка продолжается с RAM upper и выводится предупреждение об ошибке.

Хранилище сессий и его расположение

Обычное хранилище — это каталог changes рядом с данными MiniOS, с пронумерованными каталогами сессий и session.conf или session.json метаданными:

minios/changes/
|-- session.conf
|-- session.json
|-- 1/
`-- 2/

Вместо этого хранилище может быть выбрано как устройство с необязательным путём. Допустимые варианты включают прямой путь /dev/... , /dev/disk/by-label/LABEL/..., /dev/mapper/..., label:LABEL/..., askdisk и askdisk:custom:path. Двоеточие в конце становится путём внутри выбранного устройства; если использовать слэш после askdisk , этот пользовательский путь будет проигнорирован. Выбранный подкаталог монтируется как хранилище сессий через bind-mount. MiniOS также может обнаружить раздел персистентности на том же диске и поддерживаемое хранилище персистентности Ventoy.

Перед выбором сессии initrd должен смонтировать место для записи и убедиться, что может создать и удалить маркер в хранилище. Блочное устройство, которое нельзя открыть для записи, монтирование только для чтения, недоступный путь или неудачная попытка записи — всё это приведёт к отказу в использовании персистентности при данной загрузке. Существующие сессии не считаются доверенными только потому, что их файлы доступны для чтения.

Выбор и совместимость

Метаданные сессии фиксируют режим хранения и могут содержать версию MiniOS, редакцию, union filesystem и размер контейнера. При возобновлении работы происходит сравнение сохранённых режима, версии, редакции и union с запрошенными параметрами и текущей системой. Отсутствие устаревших полей совместимости не считается несовпадением.

Буквальное perchdir=resume создаёт новую сессию с номером, если её значение по умолчанию отсутствует или если зафиксированные режим, версия, редакция или union не соответствуют требованиям и делают это значение по умолчанию неподходящим. Просто perch, прямой числовой выбор и другие устаревшие запросы на возобновление работы не допускают автоматическую замену и продолжают выполнение в RAM после неудачного выбора.perchdir=ask отображает информацию о совместимости и позволяет явно переопределить выбор. Новая сессия по умолчанию использует native, если не был запрошен другой режим.

Режим хранения входит в параметры совместимости. Если выбор доходит до диспетчера backend, неизвестный запрошенный режим переключается на native, при этом проверка может выбрать DynBlk или DynFileFS при неподходящем хранилище. Если в существующей сессии зафиксирован другой режим, то проверка совместимости может завершиться неудачей раньше; в этом случае устаревший запрос на возобновление работы продолжится в RAM, не доходя до этого переключения.

Сброс несовместимой сессии

В интерактивном режиме можно выбрать Сброс с сохранением настроек или Сброс с сохранением данных, а также вернуться к списку или явно продолжить без сброса. Сброс выполняется до активации объединения. При этом удаляются системные каталоги программ/библиотек, состояние системного пакетного менеджера, системные приложения Flatpak/Snap и кэши. Списки файлов пакетов помогают определить установленное ПО в других местах; неучтённые файлы сохраняются максимально осторожно.

В обоих режимах сохраняются /home и /root, включая скрытые настройки, кэши, профили браузеров и программы, установленные в домашней директории. Также сохраняются учётные записи, сопоставления UID/GID, пароли, SSH host-ключи, приватные TLS-ключи и данные вне домашней директории. В режиме сохранения настроек остаются обычные /etc и конфигурация пакетов; в режиме только с данными эти системные настройки сбрасываются, но личные параметры в домашней директории сохраняются. Это не позволяет определить все программы, установленные вручную в произвольных местах.

Новая верхняя часть создаётся рядом с исходной, для этого требуется свободное место для второй копии сохраняемых данных. При неудачном копировании или замене происходит откат; прерванные операции восстанавливаются при следующем подключении. Сброс SquashFS изменяет только восстановленную верхнюю часть RAM: старая снапшот и метаданные совместимости остаются основными до успешного сохранения этой верхней части после сброса. Сброс нативной сессии отключает perchtoram для этой загрузки, чтобы не заменить сохранённые данные пустым контейнером RAM. Автоматическое восстановление никогда не сбрасывает сессию без уведомления.

Резерв пространства и размеры

MiniOS использует 256 МиБ как стандартный запас по выделению и порог предупреждения о нехватке места. Расчёт производится с использованием файловых блоков по 1024 байта. perchreserve принимает неотрицательное целое число без единицы измерения, ограничено максимумом 4096, а при отсутствии или ошибке возвращается к значению 256. Запас уменьшает объём пространства, доступного для нового или увеличивающегося контейнера. Это не квота: нативная сессия или последующие записи всё равно могут использовать оставшееся место на файловой системе. При запуске появляется предупреждение, если свободное место равно или ниже порога.

Размеры контейнеров задаются целыми числами, которые выделяются в МиБ:

• Число без единицы, M, или MB означает МиБ.
• G или GB умножает число на 1000 МиБ.
• T или TB умножает число на 1 000 000 МиБ.
• Raw-контейнеры ограничены 1 000 000 МиБ и доступным пространством после резерва. DynFileFS имеет отдельное ограничение с учётом RAM и жёсткий потолок в 2 000 000 МиБ. DynBlk получает ограничение по геометрии в нативном формате из dynblk limits --format dynblk; MiniOS не накладывает отдельного потолка в 512 ГиБ.
• Raw — это один файл-хранилище, поэтому FAT32 ограничивает его до 4000 МиБ в MiniOS. Такое же ограничение действует, если Raw обёрнут в LUKS2.
• Новая сессия Raw по умолчанию создаётся с размером 4000 МиБ. Шифрование не задаёт отдельную политику размера LUKS: зашифрованный Raw, DynFileFS, DynBlk или VMDK-сессия используют правила размера своего базового хранилища.
• Новая сессия DynFileFS, созданная через initrd, без perchsize использует до 16 ГиБ логической ёмкости. Если хранилище не может вместить столько после perchreserve и накладных расходов индекса DynFileFS, по умолчанию используется доступная ёмкость. Индекс формата-400 занимает примерно 2 МиБ RAM и около 2 МиБ хранилища на каждый ГиБ объявленной логической ёмкости, даже если полезная нагрузка пуста. Поэтому MiniOS также ограничивает ёмкость DynFileFS по физическому объёму RAM и проверенному жёсткому потолку в 2 000 000 МиБ.
• Новая сессия DynBlk без perchsize также использует автоматический потолок 16 ГиБ и уменьшается, если после perchreserve. Явно заданный размер DynBlk — это запрос на тонкое выделение, который проверяется по лимиту установленного бэкенда. Метаданные для объявленных разделов создаются сразу, а пространство под данные выделяется по мере необходимости. DynBlk использует ограниченный кэш метаданных, не зависящий от заполнения полезной нагрузкой.

Рост контейнера выполняется по возможности, уменьшение размера не поддерживается. perchsize не задаёт размер для нативных или SquashFS сессий. Менеджер сессий MiniOS по умолчанию устанавливает вручную созданные Raw- и DynFileFS-контейнеры на 4000 МиБ, а контейнеры DynBlk/VMDK — на 16 ГиБ; для зашифрованных вариантов применяются те же значения по умолчанию бэкенда. Подробнее см. Управление сессиями.

Активация хранилища

Все успешные бэкенды должны предоставлять доступную для записи верхнюю директорию, ожидаемую выбранной объединённой файловой системой. Монтирование бэкенда само по себе не гарантирует активность постоянного хранения. Native, DynFileFS, DynBlk, VMDK и raw могут обновлять метаданные постоянной сессии до проверки объединения; SquashFS откладывает фиксацию этих метаданных. Raw, DynFileFS, DynBlk и VMDK дополнительно поддерживают шифрование LUKS2. Защищённое состояние текущей загрузки публикуется только после подтверждения использования ожидаемой верхней директории в финальном корневом объединении.

Бэкенд	Постоянное представление	Модель ёмкости	Требования к хранилищу	MiniOS слой LUKS2
native	Файлы и каталоги непосредственно в пронумерованной директории сессии	Использует пространство базовой файловой системы напрямую; perchsize не применяется	Файловая система с возможностью записи, проходящая проверку поведения POSIX	Нет
dynfilefs	Формат-400 changes.dat плюс сегментные файлы, предоставляющие ext4 virtual.dat	Тонкий контейнер с плотным индексом по размеру ёмкости	Записываемое хранилище с поддержкой POSIX, FAT32, NTFS или exFAT	Да
dynblk	Формат-1 volumeNNN.db файлы с доступом к /dev/dynblkN, с ext4 поверх	Тонкое виртуальное блочное устройство с дисковыми отображениями и ограниченным кэшем	Файловая система, поддерживаемая ядром бэкенда DynBlk, и достаточные ресурсы бэкенда	Да
vmdk	volume.vmdk плюс разделённые разрежённые volume-sNNN.vmdk экстенты, предоставляемые драйвером DynBlk, с ext4 поверх	Тонкое разрежённое виртуальное блочное устройство	Файловая система, поддерживаемая бэкендом VMDK DynBlk, и vmdk-session-v1 поддержка	Да
raw	Один файл фиксированного размера changes.img с ext4 внутри	Файл создаётся с запрошенным логическим размером; только увеличение	Записываемая файловая система, способная хранить образ; для FAT32 ограничение — 4000 МиБ	Да
squashfs	Сжатый changes.sb снимок; рабочая writable upper воссоздаётся в RAM	Размер снимка соответствует зафиксированным изменениям; perchsize не применяется	Существующие снимки можно читать с поддерживаемых записываемых носителей; для точного сохранения требуется подходящее хранилище с поддержкой POSIX	Нет

Нативный

В нативном режиме изменяемое содержимое union сохраняется напрямую в каталог сессии с номером. В этом режиме не используется внутренний образ, loop-устройство, FUSE-контейнер или отдельная блочная файловая система, поэтому доступное пространство определяется только свободным местом на основной файловой системе, и perchsize это ограничение не применяется. Такой подход минимизирует накладные расходы контейнера и обеспечивает стандартную видимость файлов для восстановления и резервного копирования.

MiniOS сначала исключает известные не-POSIX файловые системы, такие как FAT, exFAT и NTFS. Затем происходит проверка поведения реальной файловой системы путём создания файла и символической ссылки, а также проверки изменения режима на исполняемый. Если проверка проходит успешно, каталог сессии с номером монтируется напрямую как область для записи. При неподходящем хранилище или неудачной проверке нативное создание предпочитает DynBlk, если его CLI доступен и Secure Boot это разрешает, иначе используется DynFileFS. Этот начальный откат не гарантирует, что выбранный драйвер сможет подключиться или что любая основная файловая система будет поддерживаться. В случае сбоя после активации нативного режима изменения отменяются; новый пустой кандидат удаляется, если это возможно сделать безопасно.

Слой персистентности LUKS2 MiniOS не применяется к нативному режиму, так как в нём отсутствует контейнер или блочное устройство, которые можно было бы зашифровать. Тем не менее, нативная персистентность может размещаться на хранилище, зашифрованном вне этого слоя.

DynFileFS

DynFileFS — это бэкенд контейнера формата-400 на основе FUSE. Он предоставляет один логический virtual.dat образ, при этом данные хранятся в changes.dat плюс пронумерованные сегментные файлы. Вспомогательный модуль должен успешно смонтироваться и предоставить virtual.dat; в противном случае активация завершится с ошибкой, чтобы не создать файл только для RAM с именем, похожим на постоянный.

Его индекс отображения плотный относительно объявленной логической ёмкости: на каждый 4-КиБ логический блок приходится один 8-байтный оффсет. Это примерно 2 МБ индекса RAM на 1 ГиБ виртуальной ёмкости, и примерно столько же хранится в индексах сегментов до записи полезных данных. Выделение полезных данных остаётся динамическим. Поскольку статический бинарный initrd — i686, MiniOS также применяет ограничение по логическому размеру с учётом RAM и жёсткий предел в 2 000 000 МБ, что ниже проверенной точки сбоя адресного пространства.

Логический образ содержит ext4. Существующие образы проверяются перед монтированием в режиме записи; если результат проверки файловой системы выше статуса «исправленные ошибки», сессия отклоняется и не монтируется для записи. Изменение размера возможно только в сторону увеличения, при этом внутренняя файловая система ext4 расширяется, когда это возможно. Для диагностики, ориентированной на пользователя, см. Устранение неполадок.

DynBlk

Режим dynblk использует блочное устройство ядра, отдельное от DynFileFS. Каждая сессия с номером владеет volume000.db и всеми её однотипными сёстрами (volume001.db, ..., volume1000.db, и далее). Нативная разметка — DBSPRS01, формат диска 1. Неподдерживаемые разметки отклоняются, а не конвертируются автоматически. Следите, чтобы версии CLI и модуля были одинаковыми.

MiniOS создаёт ext4 на всём диске, который возвращает /dev/dynblk-control, например, /dev/dynblk3; не предполагается, что dynblk0 свободен. Существующий ext4 проверяется перед записью. Защищённая запись состояния загрузки фиксирует именно это устройство, чтобы при завершении работы отсоединение происходило только после закрытия всех пользователей и верхнего файлового уровня. Возможно одновременное использование нескольких независимых устройств.

Session Manager, установщик и initramfs запрашивают dynblk limits --format dynblk для получения ограничения геометрии установленного backend. Текущий ограничитель ресурсов допускает 65536 частей: стандартные логические блоки по 1 ГиБ позволяют до 64 ТиБ. Меньшие физические ограничения частей уменьшают виртуальный предел. Это потолок по геометрии, а не гарантия, что хост сможет открыть столько файлов или имеет достаточно RAM/места для хранения. Поддерживается увеличение; уменьшение не поддерживается.

Таблицы отображения хранятся на диске. --map-memory-mb управляет кэшем метаданных для каждого устройства (по умолчанию 1 МБ, диапазон 1..64 МБ), больше не в процентах от RAM и не ограничивает объём отображаемых данных. Описания экстентов, векторы открытых файлов и небольшие каталоги увеличиваются в зависимости от заявленной геометрии, а не от заполнения данными. При подключении сканируется только метаданные отображения и временно восстанавливается состояние выделения по одной части; полезная нагрузка не читается полностью. Полная dynblk check читает полезные данные. engine_memory_bytes не включает кэш страниц файловой системы, внутренние ресурсы кодека и другие выделения ядра.

Файлы метаданных для всех объявленных частей инициализируются при создании/расширении; сами данные остаются тонкими. Размер части ограничен 4000 МБ. Рекомендуется делать резервную копию всей отсоединённой области имён, не полагаясь на трёхзначные номера или фиксированную последнюю часть. Для нового тома можно выбрать сжатие через perchcomp; при последующих загрузках используется сохранённый кодек. LUKS2 выше DynBlk принудительно включает сжатие none. Частичные записи в сжатые данные сейчас приводят к повторному сжатию соответствующего 64-КиБ блока. При нехватке места или ресурсов запись может завершиться неудачей; верхний файловый уровень должен быть размонтирован перед отсоединением.

Сессии VMDK

Режим vmdk сессии использует тот же драйвер, что и для реальных twoGbMaxExtentSparse образов. Основной формат — volume.vmdk, с volume-s001.vmdk и последующими частями; каждая часть покрывает до 2 ГиБ логического пространства. Дескриптор ограничен размером менее 1 МиБ, поэтому длина имени файла и количество экстентов ограничивают ёмкость. Session Manager, Installer и initramfs запрашивают dynblk limits --format vmdk. Нативный формат DynBlk продолжает использовать volume000.db; ни один из форматов не интерпретирует файлы другого. Управляемые сессии не импортируют произвольно разбитый внешний VMDK в качестве метаданных сессии.

Поддержка сессий VMDK объявляется через vmdk-session-v1 в /etc/minios-initramfs-dynblk внутри initrd. Текущее окружение и каждый исходный initrd, скопированный Installer, должны поддерживать этот режим. В VMDK отсутствует собственное сжатие; perchcompон игнорируется с предупреждением при загрузке, а Session Manager отклоняет не-none VMDK кодек. LUKS2 остаётся отдельным дополнительным уровнем шифрования. Оба режима публикуют фактический режим сессии и владеющее dynblk_deviceустройство в защищённом состоянии загрузки, и обе реализации завершения работы закрывают это устройство после выхода всех пользователей.

Оба формата драйвера поддерживают writeback, writethrough, none, directsync и явные политики unsafeподключения. Для прямых режимов требуется ext2/ext4 в качестве базовой файловой системы. mount -t dynblk /path/to/image /mnt -o inner-fstype=ext4,cache=writebackподключает существующую файловую систему; umountосвобождает устройство, принадлежащее вспомогательному процессу, после закрытия последним пользователем. Ручной режим dynblk loadимеет явное время жизни. Этот процесс не создаёт файловую систему и не разблокирует LUKS.

Поддержка tmpfs в качестве хранилища реализована для обоих форматов с помощью writeback, writethrough, и unsafe; режимы с прямым вводом-выводом отклоняются, а не переключаются автоматически. Порядок сброса не делает сессию на базе tmpfs устойчивой к завершению работы. Эта поддержка лежит в основе сессий DynBlk/VMDK RAM, изменения в которых должны явно сохраняться в исходное хранилище.

Raw

Режим Raw использует один changes.img файл с ext4. Длина файла устанавливается в соответствии с запрошенной логической ёмкостью при создании, поэтому, в отличие от динамических бэкендов, сама ёмкость остаётся фиксированной до явного увеличения. Нижележащая файловая система может хранить незаписанные области разреженно, но MiniOS всё равно рассматривает Raw как хранилище с фиксированной ёмкостью и проверяет наличие свободного пространства перед созданием или увеличением. Поскольку всё содержится в одном файле хоста, для FAT32 действует ограничение в 4000 Миб.

Существующие образы Raw проверяются с помощью e2fsck перед монтированием в режиме записи. При увеличении сначала расширяется changes.img, затем ext4 увеличивается с помощью resize2fs; уменьшение не поддерживается. При неудачной проверке или монтировании образ сохраняется для восстановления, а загрузка продолжается в RAM. В Raw нет демона FUSE или собственной метаинформации блочного хранилища, что упрощает восстановление, но отсутствует поддержка тонких томов, как у DynFileFS и DynBlk.

Слой шифрования LUKS

LUKS2 — это опциональный слой шифрования, который выбирается с помощью perchencrypt=luks при создании сессии Raw, DynFileFS, DynBlk или VMDK. Для существующих сессий состояние шифрования определяется метаданными сессии; указание perchencrypt позднее не изменяет и не конвертирует уже существующую незашифрованную сессию.

Граница шифрования зависит от выбранного бэкенда: Raw подключает changes.img через loop-устройство и размещает LUKS2 внутри этого файла; DynFileFS подключает свой открытый virtual.dat через loop-устройство и шифрует этот логический образ; DynBlk использует выделенный /dev/dynblkN блочный девайс напрямую; VMDK использует блочный девайс, предоставляемый тем же драйвером DynBlk для своего разделённого разреженного образа. Во всех четырёх случаях MiniOS создаёт ext4 внутри /dev/mapper/..., поэтому содержимое файловой системы и метаданные внутри маппера зашифрованы на диске. Метаданные бэкенда вне границы LUKS, дескрипторы VMDK, загрузочные файлы, метаданные сессии и другие файлы на носителе остаются незашифрованными.

Значения по умолчанию для размера, ограничения на рост, ограничения FAT32 и поведение тонкого/фиксированного выделения относятся к базовому бэкенду. initrd выполняет аутентификацию перед расширением существующего зашифрованного бэкенда, закрывает маппер до увеличения бэкенда, затем повторно открывает его, проверяет ext4 и расширяет файловую систему перед монтированием. Для зашифрованных DynBlk сжатие бэкенда принудительно устанавливается в none.

При создании парольная фраза запрашивается дважды. В существующих зашифрованных сессиях на консоли загрузки разрешено три попытки ввода пароля. Три неверных попытки приводят к фатальному сценарию загрузки: MiniOS не продолжает работу в RAM, не интерпретирует ту же сессию как незашифрованную, не выбирает другой бэкенд и не создаёт замену. Другие ошибки при создании, проверке, изменении размера или монтировании обрабатываются по стандартным сценариям восстановления для конкретного бэкенда без перехода к незашифрованному режиму. Парольные фразы не сохраняются в метаданных сессии и не передаются как аргументы команд. При логическом экспорте сессии содержат расшифрованные файлы, а не образ зашифрованного бэкенда.

Подробнее см. в разделе Безопасность по вопросам границ защиты и резервного копирования.

SquashFS

Обычно initrd активирует существующую сессию SquashFS. Интерактивная настройка создает метаданные нулевого поколения с включённым сохранением при завершении работы, но не создаёт changes.sb; изменяемый верхний слой существует только в RAM до тех пор, пока работающая система не выполнит первое сохранение по требованию или при завершении работы. Сессия нулевого поколения считается действительной только если поля артефакта снимка и changes.sb отсутствуют. Для последующих поколений активация проверяет строгие, однозначные метаданные снимка, включая его дайджест, сжатые и несжатые размеры, количество записей, тип union и политику сохранения. Также проверяются тип файла и точный размер, доступные RAM и swap, дайджест SHA-256 до и после извлечения, а также совместимость текущего union.

Снимок извлекается с жёсткой обработкой ошибок и xattr во временный ограниченный образ ext4 в RAM. Для OverlayFS этот образ содержит отдельные changes и workdir директории; для AUFS его корень является изменяемой веткой. Некорректные метаданные, недостаточно памяти, изменение дайджеста, ошибки извлечения или неверная политика приводят к сбою активации и оставляют загрузку на обычном верхнем слое RAM.

Сессия с пометкой dirty означает, что предыдущая загрузка не завершила переход к чистому завершению работы. Тогда SquashFS предупреждает и восстанавливает последний успешно сохранённый changes.sb; несохранённые изменения из прерванной загрузки не считаются вторым поколением для отката.

Менеджер сессий MiniOS и бэкенд сохранения системы создают и атомарно заменяют снимки SquashFS с точным захватом состояния. При активации загрузки существующий снимок может быть прочитан с изменяемого хранилища FAT, exFAT или NTFS, так как извлечение происходит во временном верхнем слое ext4. Создание и точное сохранение по-прежнему зависят от файловой системы: хранилище сессий должно поддерживать создание приватного рабочего пространства, Linux-метаданные и надёжную публикацию на подходящей POSIX-совместимой файловой системе.

Во время сохранения бэкенд сначала фиксирует стабильное дерево файлов в приватном хранилище памяти, принадлежащем root, если initrd предоставляет доверенный tmpfs с достаточным запасом. Когда RAM недостаточно, это дерево использует предыдущее дисковое рабочее пространство. Компрессор записывает данные напрямую в одну приватную директорию с режимом 0700 на файловой системе сессии, а не в дополнительный образ RAM с последующим копированием на диск. MiniOS проверяет сжатый результат и его идентичность, синхронизирует его, перемещает под приватное имя-кандидат, затем повторно валидирует кандидат перед атомарной заменой активного changes.sb. Неудачные копирования или сжатие не заменяют последний успешный снимок.

При корректной и надёжной сессии /var/log/minios и /var/log/live примонтированы в режиме bind из boot-logs/ внутри пронумерованной сессии. Эти диагностические данные запуска записываются независимо от верхнего слоя RAM и снимка при завершении работы. Загрузка, для которой хранилище постоянства не было надёжно активировано, не может гарантировать сохранность этих логов после перезапуска. Обычные логи и кэши можно настраивать отдельно; см. Производительность.

SquashFS не имеет perchsize: его сохранённый размер соответствует сжатым зафиксированным изменениям, а объём памяти во время работы определяется извлечённым изменяемым верхом. Слой LUKS-постоянства MiniOS не оборачивает changes.sb; если требуется конфиденциальность снимка, базовое хранилище должно быть зашифровано вне этого слоя. См. Управление сессиями.

Граница активации и восстановления объединённой файловой системы

Для AUFS активированный корень изменений становится первой (нулевой) записываемой веткой. Для OverlayFS initrd формирует upperdir и workdir под активированным корнем изменений и монтирует модули только для чтения как нижние директории. Затем initrd проверяет активную ветку AUFS или OverlayFS upperdir перед публикацией постоянного состояния как активного.

Если бэкенд постоянства, обновление метаданных или эта проверка завершаются неудачей, монтирования откатываются, где это возможно, успешное состояние постоянства не публикуется, и загрузка с возможностью записи продолжается в RAM. Если не удаётся сформировать объединённый корень, система переходит в критическую оболочку initramfs. Выход из этой оболочки может позволить продолжить настройку с некорректным корнем; это не восстановление и не безопасный режим. AUFS сохраняет попытки добавления веток модулей по возможности, но неполная объединённая файловая система пересекает границу восстановления: MiniOS не отмечает постоянство как активное.

При сбоях проверки контейнера подозрительная сессия преднамеренно не монтируется в режиме записи. Не заменяйте и не пересоздавайте файлы сессии во время загрузки. Сначала сохраните затронутое хранилище; см. Резервное копирование MiniOS и Устранение неполадок.

Ventoy Плагин постоянства

Бэкенд, выбранный через плагин постоянства Ventoy, минует обнаружение сессий с номерами. MiniOS обрабатывает Ventoyvtoy_persistent отображение устройства, требует ext4-образ с возможностью записи и использует changes/ каталог как верхний слой AUFS или changes/ плюс workdir/ для OverlayFS. Он не создает minios/changes/, session.conf, либо сессии с номерами внутри этого образа. Для постоянства все равно требуется распознанный запрос на постоянство; Запустить без сохранения остается временным.

При первом использовании формат union записывается в .minios-union. Если выбран другой union-бэкенд, отсутствует устройство, неверная файловая система, образ только для чтения или не удалось активировать union, появится предупреждение и будет создан новый верхний слой RAM. Никогда не будет подставлен другой образ только из-за совпадения метки файловой системы.

perchdir выбор сессии и perchtoram игнорируются для выбранного образа плагина; изменения сохраняются на этом образе даже при toram. Session Manager и minios-session отклоняют операции, включая пользовательские каталоги сессий. Чтобы сменить окружение, выберите другой образ в Ventoy. Без выбранного бэкенда плагина обычные загрузки Ventoy используют стандартную модель сессий с номерами MiniOS. Подробнее см.Ventoy.

Активное, работающее и текущее состояние загрузки

В метаданных долговременной сессии default= — это активная сессия, выбранная для следующего возобновления, а running= — это сессия, зафиксированная как обеспечивающая текущую загрузку. При активации оба поля записываются, и эта сессия помечается как dirty. После того как точки монтирования с постоянными данными исчезают при корректном завершении работы, MiniOS удаляет running= и помечает сессию как clean.

Эти поля метаданных могут устареть после сбоя, неудачной записи метаданных, неудачного построения объединения, копирования хранилища или прерванного завершения работы. Компоненты среды выполнения, которые позволяют сохранять, не доверяют только running= этому полю. Они используют защищённое состояние текущей загрузки из initrd, связанное с идентификатором загрузки, номером сессии, режимом, фактическим идентификатором хранилища, возможностью записи, долговечностью, подтверждённым активным поколением и, для DynBlk, точным подключённым /dev/dynblkN устройством. Если запись о текущей загрузке отсутствует или повреждена, постоянное хранилище не должно использоваться как разрешённая цель для сохранения.

С помощью perchtoram=trim или full поддерживаемые контейнеры сессий копируются в отдельный tmpfs перед активацией. Копирование допускается только при наличии достаточного объёма оперативной памяти и свободного места в tmpfs для хранения исходных файлов плюс резерв; при неудаче работа продолжается с хранилища с предупреждением. Скопированная сессия может использоваться как верхний слой для записи, но защищённое состояние текущей загрузки помечает её как недолговечную и фиксирует отдельную ram-origin идентичность для исходного хранилища. trim копирует только выбранную поддерживаемую сессию и соответствующие метаданные; full копирует все поддерживаемые Raw, DynFileFS, DynBlk, VMDK или SquashFS сессии в хранилище. Данные в нативном каталоге не копируются: успешный нативный запрос RAM создаёт новый пустой контейнер DynBlk или DynFileFS, кроме случаев сброса, когда копирование отключено. Текущий Session Manager определяет исходное хранилище по UUID файловой системы и может явно сохранить сессию на основе RAM обратно или как новую сессию с номером. Несохранённые изменения RAM теряются, если не происходит успешной обратной записи.

Для получения дополнительных рекомендаций по работе смотрите разделы Режимы загрузки, Параметры загрузки, Сессии и постоянство, Резервное копирование MiniOS, Безопасность, и Устранение неполадок.

Освобождение пространства с учетом сессии

minios-session reclaim ID поддерживает DynFileFS, DynBlk и VMDK-сессии. Для сессии в виде открытого текста выполняется FITRIM на внутренней ext4-файловой системе, но никогда не на объединённом корне AUFS/OverlayFS, после чего вызывается операция освобождения пространства в используемом хранилище. Для освобождения пространства в DynFileFS требуется DynFileFS версии 4.6.0 или новее.

Для работающей сессии DynFileFS Session Manager входит в отдельное приватное пространство монтирования, чтобы получить доступ к virtual.dat под активным ext4-овермаунтом, не прерывая работу системного демона, loop-устройства или объединённых точек монтирования. Для работающих устройств DynBlk/VMDK выполняется проверка на соответствие текущему защищённому состоянию загрузки. Неактивные сессии временно подключаются и монтируются; если сессия уже смонтирована Session Manager, используется существующее подключение. Если файловая система занята, размонтирование останавливает завершение работы, не отключая хранилище под живой файловой системой.

Ни при загрузке, ни при завершении работы автоматическое уплотнение не выполняется. --compact — это явный выбор пользователя в CLI или неотмеченный параметр в диалоговом окне Session Manager; операция может перемещать активные данные, увеличивая количество записей во флеш-память. Без этого действия бэкенды освобождают только то пространство, которое можно вернуть без перемещения активных данных, например, диапазоны с возможностью "hole punching" или полностью свободные хвосты файлов; на файловых системах, таких как exFAT, освобождённые внутренние диапазоны могут быть повторно использованы внутри контейнера, даже если их нельзя вернуть в файловую систему хоста. Для зашифрованных сессий освобождается только пространство, уже известное бэкенду, и функция discard через dm-crypt не включается автоматически.