Systemd-swap: ¿Realmente no es posible la hibernación?

@TeslaBargain , una especie de magia vudú negra.

Por supuesto que es posible hacerlo por su cuenta, para que pueda hacerlo usted mismo.

Para zram, necesita hacer que todas las cosas sucedan antes de la hibernación:

1. Agregar nuevo archivo de intercambio
2. Formatee y cambie
3. Agregue toda la información para acceder a los datos en el archivo de intercambio a la cmdline del kernel (¿cambiar la configuración de grub, o systemd-boot, o lilo, o u-boot & etc?)
4. Swapout zram
5. Hibernar (creo que no sabes cuánto tiempo perdiste antes de que suceda todo eso, para hacer posible la hibernación)
6. Después de reiniciar / salir de la hibernación, debe hacer todas esas cosas en orden inverso.

Y eso solo funcionará en fs que admitan ese tipo de archivos de intercambio, es decir, para btrfs que no es posible.

@ Nefelim4ag , gracias por

¿Qué pasaría si hubiera una opción para formatear e intercambiar suficientes archivos de intercambio para que el sistema hiberne toda su memoria disponible cuando se inicie systemd-swap? y realizar llamadas bootctl , o usar algún tipo de ubicación fija para probar, para obtener información para acceder a los datos en el archivo de intercambio al kernel cmdline en systemctl-boot o rEFInd o grub o lo que sea?

De esa manera, el único retraso real sería cambiar zram, algo que es solo una parte inevitable del uso de zram.

De la forma en que lo imagino, si ya va a preasignar el intercambio al inicio , también podría asignar lo suficiente para que sea útil.

Hola. Estoy dispuesto a saber si el escenario en el que define una partición de intercambio en la instalación y la usa para la hibernación (no estoy seguro de cómo indicar que el kernel lo use solo para hibernación) y luego usa zram para el resto de las operaciones de intercambio (y gana en actuaciones). ¿Es algo a considerar? ¿Alguna idea?

EDITAR: esto https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
más systemd-swap (zram)

Creo que se puede lograr esto mediante intercambio de prioridades + ganchos para hibernación de systemd. Examinar rápidamente varias preguntas de stackoverflow no respondió esto, así que tendría que probarlo manualmente. En realidad, esta es una solución mucho más fácil que la que estaba pensando y, por lo tanto, podría implementarse antes de 5.0 (aunque la solución completa debería estar en 5.0)

IIRC, la hibernación requiere un solo dispositivo de intercambio, por lo que debe ser lo suficientemente grande para almacenar toda la memoria asignada en la RAM / intercambio en otro lugar. (pero esta imagen de hibernación que está escrita debería usar compresión por defecto con un objetivo de alrededor del 40%).

No lo he intentado yo mismo, ¿la hibernación no retiene los archivos de intercambio en el disco o los dispositivos zram en la RAM como si estuvieran asignados como cualquier otro software? ¿Está reanudando un estado del sistema, siempre que la memoria esté escrita en la imagen de hibernación, debería restaurar / reanudar los dispositivos de intercambio asignados anteriormente en lugar de tener que inicializarlos como lo haría un arranque nuevo? Por lo tanto, no se debería requerir ningún intercambio de encendido / apagado más allá de alternar un dispositivo de intercambio de hibernación.

Solo he hibernado con un solo dispositivo de intercambio (sin zswap o zram). No estoy seguro de qué sucede con el intercambio de disco (ya que existe más de un dispositivo de intercambio) en ese caso (si necesita encajar en la imagen de hibernación, ¿parecería redundante?), De la misma manera, supongo que zram tendría su memoria asignada. escrito en la imagen de hibernación como cualquier otra memoria asignada por software, no estoy seguro de cómo se maneja la parte de intercambio, si es necesario escribir dispositivos de intercambio adicionales en la imagen de hibernación, entonces supongo que zram y el caché de zswap en RAM se descomprimirían y luego reanudar necesita ser recomprimido.

No puedo probar el cajero automático del escenario para saber qué sucede. ¿Probablemente no sea demasiado difícil de probar a través de VM?

Vale la pena señalar que la mayoría de las distribuciones que usan systemd deberían posponer la hibernación a systemd-sleep hibernate estos días, ¿afaik? Desde 2019-2020 (en la versión v239 +, ¿creo?) Tiene la capacidad de reanudarse desde la hibernación sin requerir que los parámetros del kernel especifiquen el dispositivo de intercambio de destino (partición solo en este caso, iirc), y adivinará qué dispositivo de intercambio usar implícitamente. Si solo hay una partición de intercambio, entonces debería ser confiable sin necesidad de configurar / actualizar los parámetros de arranque del kernel resume (y resume_offset si se usa un archivo de intercambio).

Una vez más, no es algo que haya probado todavía para verificar.

Problema de seguimiento ascendente: https://github.com/systemd/systemd/issues/16708