Systemd-swap: Winterschlaf wirklich nicht möglich?

@ TeslaBargain , eine Art schwarze Voodoo-Magie.

Natürlich ist es möglich, es selbst zu schaffen - damit Sie es selbst tun können.

Für zram müssen Sie all diese Dinge vor dem Winterschlaf geschehen lassen:

1. Neue Auslagerungsdatei hinzufügen
2. Formatieren & Swapon
3. Fügen Sie alle Informationen hinzu, um auf Daten in der Auslagerungsdatei in die Kernel-Cmdline zuzugreifen (ändern Sie die Grub-Konfiguration oder den Systemd-Boot oder den Lilo oder den U-Boot & etc?).
4. Swapout zram
5. Ruhezustand (ich glaube, Sie wissen nicht, wie viel Zeit Sie verloren haben, bevor all dies passiert, um den Winterschlaf zu ermöglichen)
6. Nach dem Neustart / Beenden des Ruhezustands müssen Sie all diese Dinge in umgekehrter Reihenfolge ausführen.

Und das funktioniert nur bei fs, die diese Art von Auslagerungsdateien unterstützen, dh bei btrfs, die nicht möglich sind.

@ Nefelim4ag , danke, dass du mich informiert hast, also insgesamt zu viel Arbeit, um es wert zu machen. Mit einer Out-of-the-Box-Lösung würde ich sie verwenden, aber auf diese Weise bleibe ich einfach bei meiner Swap-Partition und der regelmäßigen Verwendung von Swap + Hibernation.

Was wäre, wenn es eine Option gäbe, genügend Auslagerungsdateien zu formatieren und auszutauschen, damit das System beim Start von systemd-swap den gesamten verfügbaren Speicher in den Ruhezustand versetzen kann? und führen Sie bootctl -Aufrufe durch oder verwenden Sie einen festen Speicherort zum Testen, um Informationen für den Zugriff auf Daten in der Auslagerungsdatei in den Kernel cmdline in systemctl-boot oder rEFInd oder grub oder was auch immer zu erhalten?

Auf diese Weise besteht die einzige wirkliche Verzögerung darin, Zram auszutauschen, was nur ein unvermeidlicher Teil der Verwendung von Zram ist.

So wie ich es mir vorstelle, können Sie, wenn Sie Swap bereits beim Start vorab zuweisen , genauso gut genug zuweisen, um nützlich zu sein.

Hallo. Ich bin bereit zu wissen, ob das Szenario, in dem Sie bei der Installation eine Swap-Partition definieren und diese für den Ruhezustand verwenden (nicht sicher, wie der Kernel angegeben werden soll, um diese nur für den Ruhezustand zu verwenden) und dann zram für den Rest der Swap-Operationen (und Gain) verwendet in Aufführungen). Ist es etwas zu beachten? Irgendwelche Gedanken?

BEARBEITEN: diese https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
plus systemd-swap (zram)

Ich denke, man kann dies durch Swap-Prioritäten + Hooks für den System-Ruhezustand erreichen. Das schnelle Durchsuchen verschiedener Stackoverflow-Fragen beantwortete dies nicht, sodass ich es manuell testen musste. Dies ist tatsächlich eine viel einfachere Lösung als die, für die ich gedacht habe, und wird daher möglicherweise vor 5.0 implementiert (obwohl die vollständige Korrektur in 5.0 sein sollte).

IIRC, Ruhezustand erfordert ein einzelnes Auslagerungsgerät, also muss es groß genug sein, um den gesamten zugewiesenen Speicher im RAM / Auslagerungsort an anderer Stelle zu speichern? (Dieses Ruhezustand-Image, das geschrieben wird, sollte standardmäßig eine Komprimierung mit einem Ziel von etwa 40% verwenden.)

Ich habe es selbst nicht versucht. Behält der Ruhezustand die Auslagerungsdateien auf der Festplatte oder den zram-Geräten nicht im RAM bei, als ob diese wie jede andere Software zugewiesen worden wären? Sie nehmen einen Systemstatus wieder auf, solange der Speicher in das Ruhezustand-Image geschrieben ist, sollten die zuvor zugewiesenen Swap-Geräte wiederhergestellt / fortgesetzt werden, anstatt sie wie bei einem Neustart initialisieren zu müssen. Daher sollte kein Aus- und Einschalten erforderlich sein, außer das Umschalten eines Swap-Geräts für den Ruhezustand?

Ich habe immer nur mit einem einzigen Swap-Gerät (kein Zswap oder Zram) den Winterschlaf gehalten. Ich bin mir nicht sicher, was in diesem Fall mit dem Festplattenaustausch passiert (da in mehr als einem Auslagerungsgerät vorhanden ist) (wenn es in das Ruhezustand-Image passen muss, scheint dies redundant zu sein?), Ebenso gehe ich davon aus, dass zram den zugewiesenen Speicher haben würde Wie jeder andere von der Software zugewiesene Speicher in das Ruhezustand-Image geschrieben, nicht sicher, wie der Swap-Teil behandelt wird. Wenn zusätzliche Swap-Geräte in das Hibernation-Image geschrieben werden müssen, werden zram und der Cache von zswap im RAM wahrscheinlich dekomprimiert und weiter Lebenslauf muss erneut komprimiert werden.

Ich kann das Szenario atm nicht testen, um zu wissen, was passiert. Wahrscheinlich nicht zu schwer über VM zu testen?

Es ist erwähnenswert, dass die meisten Distributionen, die systemd verwenden, den Ruhezustand heutzutage auf systemd-sleep hibernate verschieben sollten. Seit 2019-2020 (in Version 239 +, glaube ich?) Kann der Ruhezustand fortgesetzt werden, ohne dass Kernelparameter das Ziel-Swap-Gerät angeben müssen (Partition nur in diesem Fall iirc), und erraten, welches Swap-Gerät implizit verwendet werden soll. Wenn es nur eine Swap-Partition gibt, sollte diese zuverlässig sein, ohne dass resume (und resume_offset bei Verwendung der Swap-Datei) Kernel-Boot-Parameter festgelegt / aktualisiert werden müssen.

Auch hier habe ich noch nichts getestet, um dies zu überprüfen.

Upstream-Tracking-Problem: https://github.com/systemd/systemd/issues/16708