=== Гибернация (приостановка с сохранением состояния на диск)

Ссылки: +
link:https://github.com/OlCe2/freebsd-src/tree/oc-hibernate[Код начального прототипа для сохранения образа системы] URL: https://github.com/OlCe2/freebsd-src/tree/oc-hibernate +
link:https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=[Дизайн-документ о загрузочной части процесса восстановления] URL: https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=

Контакт: Olivier Certner <olce@FreeBSD.org> +
Контакт: Konstantin Belousov <kib@FreeBSD.org>

Ведётся работа по обеспечению поддержки гибернации (приостановки с сохранением состояния на диск) во FreeBSD без помощи BIOS/прошивки для сохранения текущего состояния машины для `amd64`-машин, загружаемых через UEFI.

Первым этапом было создание прототипа, который сохраняет образ системы, пока откладывая вопросы согласованности, чтобы можно было начать параллельную работу над EFI-приложением, предназначенным для восстановления и загрузки сохранённого образа (Константин Белоусов работает над этой частью).
Этот этап был завершён в марте.
Прежде чем этот экспериментальный код может быть зафиксирован, необходимо провести значительный рефакторинг, в частности нижележащей инфраструктуры дампов.

Следующий основной этап — обеспечение согласованности сохранённого образа системы, чтобы система была работоспособна после восстановления.
Если кратко, самое большое ограничение здесь заключается в том, что мы должны гарантировать отсутствие незавершённого ввода-вывода по нескольким причинам, что состоит в том, чтобы сначала гарантировать, что больше не могут создаваться запросы ввода-вывода, а затем опустошить существующие запросы.
В частности, текущие DMA-доступы могут изменять память в то время, как она сохраняется, что приводит к устаревшему кэшированию в сохранённом образе.
Кроме того, если восстановление не удаётся (например, из-за какой-либо проблемы согласованности оборудования), ввод-вывод, который не достиг устойчивого хранилища, будет потерян, в то время как прикладной код или код файловой системы ожидали бы его фиксации (потеря согласованности).
Мы начали идентифицировать подсистемы, требующие внимания, и анализировать, какие изменения в них необходимы (например, шина, GEOM, драйверы дисков).

Следующий этап — определить, как окончательно сохранить образ системы, не нарушая согласованности, поскольку сама эта операция изменяет память ядра.
Первая высокоуровневая возможность — сделать снимок (snapshot) памяти после обеспечения стабильности, а затем возобновить нормальную работу, чтобы сохранить страницы в том состоянии, в котором они были на момент создания снимка.
Существует несколько возможных уточнений, таких как упреждающее или ленивое копирование, с разными стратегиями реализации, а следовательно, характеристиками и требованиями.
Преимущества создания снимка включают возможность использования обычного кода ядра для сохранения образа со всей поддержкой доступных преобразований.
Недостатки — более высокое потребление памяти, хотя это сильно зависит от выбранной стратегии реализации и, по-видимому, в значительной степени смягчается, а также возможные некоторые сложности на очень низких уровнях ядра.
Альтернатива, которая изучается, — не делать снимок, а вместо этого гарантировать, что отправка образа на диск изменяет только то состояние, которое будет эффективно сброшено при восстановлении.
Эта альтернатива требует реализации выборочной приостановки (selective suspend), но в остальном мы ожидаем, что большая часть существующего кода дампа при панике (dump-on-panic) будет пригодна для повторного использования.
В настоящее время мы изучаем различные варианты, чтобы лучше понять их осуществимость и связанные с ними компромиссы.

Спонсор: Фонд FreeBSD

//
// The FreeBSD Russian Documentation Project
//
// Original EN revision (18.04.2026): 3eec3239b03e88a505c6129dcdd47211c3bb5050
//