Systemd-swap: Спящий режим действительно невозможен?

@TeslaBargain , какая-то магия черного вуду.

Конечно, это возможно сделать самостоятельно - так что вы можете сделать это сами.

Для зрама вам нужно сделать все, что происходит до гибернации:

1. Добавить новый файл подкачки
2. Отформатируйте и замените
3. Добавьте всю информацию для доступа к данным в файле подкачки в командную строку ядра (измените конфигурацию grub, или systemd-boot, или lilo, или u-boot и т. Д.?)
4. Заменить зрам
5. Гибернация (я думаю, вы не знаете, сколько времени вы потеряли, прежде чем все это произойдет, чтобы сделать возможной гибернацию)
6. После перезагрузки / выхода из спящего режима вы должны сделать все это в обратном порядке.

И это будет работать только с fs, которые поддерживают такие файлы подкачки, то есть для btrfs это невозможно.

@ Nefelim4ag , спасибо, что

Что, если бы была возможность отформатировать и переставить достаточно файлов подкачки, чтобы система могла перевести всю доступную память в спящий режим при запуске systemd-swap? и выполнить вызовы bootctl или использовать какое-то фиксированное местоположение для проверки информации для доступа к данным в файле подкачки в командную строку ядра в systemctl-boot, rEFInd или grub или что-то еще?

Таким образом, единственное реальное отставание будет заключаться в замене zram, что является неизбежной частью использования zram.

Насколько я понимаю, если вы уже собираетесь заранее выделить своп при запуске , вы также можете выделить достаточно, чтобы быть полезным.

Привет. Я хочу знать, будет ли сценарий, в котором вы определяете раздел подкачки при установке и используете его для гибернации (не уверен, как указать ядру, чтобы использовать его только для спящего режима), а затем использовать zram для остальных операций подкачки (и получить в спектаклях). Стоит ли это учитывать? Есть предположения?

ИЗМЕНИТЬ: это https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
плюс systemd-swap (zram)

Я думаю, что этого можно добиться с помощью переключения приоритетов + хуков для гибернации systemd. Быстрый просмотр различных вопросов stackoverflow не дал ответа на этот вопрос, поэтому мне пришлось бы вручную протестировать его. На самом деле это гораздо более простое исправление, чем то, о котором я думал, и поэтому оно может быть реализовано до версии 5.0 (хотя полное исправление должно быть в 5.0)

IIRC, для гибернации требуется одно устройство подкачки, поэтому оно должно быть достаточно большим, чтобы хранить всю выделенную память в ОЗУ / подкачке в другом месте? (но в этом записанном образе гибернации по умолчанию должно использоваться сжатие с целевым значением около 40%).

Я сам не пробовал делать это, не сохраняет ли спящий режим файлы подкачки на диске или устройства (а) zram в ОЗУ, как если бы они были выделены, как и любое другое программное обеспечение? Вы возобновляете состояние системы, пока память записана в образ гибернации, он должен восстанавливать / возобновлять предыдущие назначенные устройства подкачки вместо того, чтобы инициализировать их, как при новой загрузке? Таким образом, кроме переключения устройства подкачки в спящем режиме, никакой подкачки не требуется?

Я когда-либо впадал в спячку только с одним устройством подкачки (без zswap или zram). Я не уверен, что происходит с подкачкой диска (поскольку существует более одного устройства подкачки) в этом случае (если он должен вписаться в образ гибернации, это может показаться избыточным?), Аналогично я предполагаю, что zram будет выделять память записано в образ гибернации, как и любая другая память, выделенная программным обеспечением, не знаю, как обрабатывается часть подкачки, если в образ спящего режима необходимо записать дополнительные устройства подкачки, тогда я предполагаю, что zram и кеш zswap в ОЗУ будут распаковываться и резюме необходимо повторно сжать.

Я не могу протестировать сценарий, чтобы узнать, что происходит. Наверное, не так уж сложно протестировать через ВМ?

Стоит отметить, что большинство дистрибутивов, использующих systemd, должны отложить гибернацию до systemd-sleep hibernate наши дни afaik? С 2019-2020 (в выпуске v239 +, я думаю?) Есть возможность выйти из спящего режима без необходимости в параметрах ядра указать целевое устройство подкачки (раздел только в этом случае iirc) и будет угадывать, какое устройство подкачки использовать неявно. Если есть только один раздел подкачки, он должен быть надежным без необходимости устанавливать / обновлять параметры загрузки ядра resume (и resume_offset при использовании файла подкачки).

Опять же, я еще не проверял, чтобы проверить.

Проблема отслеживания восходящего потока: https://github.com/systemd/systemd/issues/16708