Systemd-swap: L'hibernation n'est vraiment pas possible?

@TeslaBargain , une sorte de magie vaudou noire.

Bien sûr, c'est possible de le faire vous-même - afin que vous puissiez le faire vous-même.

Pour zram, vous devez faire en sorte que tout se passe avant la mise en veille prolongée:

1. Ajouter un nouveau fichier d'échange
2. Formater et permuter
3. Ajoutez toutes les informations pour accéder aux données du fichier d'échange à la cmdline du noyau (changez la configuration de grub, ou systemd-boot, ou lilo, ou u-boot & etc?)
4. Remplacer zram
5. Hibernation (je pense que vous ne savez pas combien de temps vous avez perdu avant que tout cela n'arrive, pour rendre l'hibernation possible)
6. Après le redémarrage / la sortie de l'hibernation, vous devez faire tout cela dans l'ordre inverse.

Et cela ne fonctionnera que sur les fs qui supportent ce type de fichiers d'échange, c'est-à-dire pour les btrfs qui ne sont pas possibles.

@ Nefelim4ag , merci de me l'avoir fait savoir, donc globalement trop de travail pour que cela en vaille la peine. Avec une solution prête à l'emploi, je l'utiliserais, mais de cette façon, je m'en tiendrai à ma partition d'échange et à mon utilisation régulière d'échange + hibernation.

Et s'il y avait une option pour formater et échanger suffisamment de fichiers d'échange pour que le système hiberne toute sa mémoire disponible au démarrage de systemd-swap? et effectuer des appels bootctl , ou utilisé une sorte d'emplacement fixe pour tester, pour les informations pour accéder aux données dans le fichier d'échange vers le noyau cmdline dans systemctl-boot ou rEFInd ou grub ou autre?

De cette façon, le seul vrai retard serait de remplacer zram, quelque chose qui est juste une partie inévitable de l'utilisation de zram.

D'après moi, si vous prévoyez déjà de pré-allouer le swap au démarrage , vous pourriez aussi bien en allouer suffisamment pour être utile.

Salut. Je suis prêt à savoir si le scénario dans lequel vous définissez une partition de swap lors de l'installation et utilisez celle-ci pour l'hibernation (je ne sais pas comment indiquer au noyau de l'utiliser uniquement pour la mise en veille prolongée), puis en utilisant zram pour le reste des opérations de swap (et gagner en performances). Est-ce quelque chose à considérer? Des pensées?

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

Je pense que l'on peut y parvenir en échangeant des priorités + des crochets pour l'hibernation systemd. Le fait de parcourir rapidement diverses questions de stackoverflow n'a pas répondu à cela, je devrais donc le tester manuellement. C'est en fait une solution beaucoup plus facile que celle à laquelle je pensais et pourrait donc être implémentée avant la version 5.0 (bien que la correction complète devrait être en 5.0)

IIRC, la mise en veille prolongée nécessite un seul périphérique d'échange, il doit donc être suffisamment grand pour stocker toute la mémoire allouée dans la RAM / swap ailleurs? (mais cette image d'hibernation qui est écrite devrait par défaut utiliser la compression avec une cible d'environ 40%).

Je n'ai pas essayé moi-même, la veille prolongée ne conserve-t-elle pas les fichiers d'échange sur le disque ou le (s) périphérique (s) zram dans la RAM comme si ceux-ci étaient alloués comme n'importe quel autre logiciel? Vous reprenez un état du système, tant que la mémoire est écrite dans l'image d'hibernation, elle devrait restaurer / reprendre les périphériques d'échange attribués précédemment au lieu d'avoir à les initialiser comme le ferait un nouveau démarrage? Ainsi, aucun swap off / on ne devrait être nécessaire au-delà du basculement d'un périphérique d'échange d'hibernation?

Je n'ai jamais hiberné qu'avec un seul périphérique d'échange (pas de zswap ou de zram). Je ne suis pas sûr de ce qui arrive à l'échange de disque (car il existe plus d'un périphérique d'échange) dans ce cas (s'il doit s'intégrer dans l'image d'hibernation, cela semble redondant?), De même, je suppose que zram aurait sa mémoire allouée écrit sur l'image d'hibernation comme toute autre mémoire allouée par le logiciel, je ne sais pas comment la partie d'échange est gérée, si des périphériques d'échange supplémentaires doivent être écrits dans l'image d'hibernation, alors je suppose que zram et le cache de zswap dans la RAM se décompresseraient et après CV doit être recompressé.

Je ne suis pas en mesure de tester le scénario atm pour savoir ce qui se passe. Probablement pas trop difficile à tester via VM?

Il convient de noter que la plupart des distributions qui utilisent systemd devraient reporter l'hibernation à systemd-sleep hibernate ces jours-ci afaik? Depuis 2019-2020 (dans la version v239 + je pense?) A la capacité de reprendre de l'hibernation sans que les paramètres du noyau spécifient le périphérique de swap cible (partition uniquement dans ce cas iirc), et devineront quel périphérique de swap utiliser implicitement. S'il n'y a qu'une seule partition d'échange, cela devrait être fiable sans qu'il soit nécessaire de définir / mettre resume jour les paramètres de démarrage du noyau resume_offset si vous utilisez un fichier d'échange).

Encore une fois, pas quelque chose que j'ai testé pour le moment.

Problème de suivi en amont: https://github.com/systemd/systemd/issues/16708