"mise en veille" sur debian & Xfce

Bonjour,
sur Xfce, j’ai un bouton mise en veille, qui, effectivement fait une mise en veille de ma machine :slight_smile:
Il s’agit de l’hivernation, j’imagine ? Je l’avais utilisée il y a longtemps et j’avais arrêté de m’en servir, je ne sais plus trop pourquoi. Il me semble avoir entendu dire (légende urbaine ?) que l’usage n’était pas conseillé avec un ssd. Je précise que mon système est installé sur un ssd mais le swap est sur un dd traditionnel (8Gb pour 4Gb de RAM).
En gros, y a-t-il une bonne raison de se passer de cette mise en veille, qui est quand même assez pratique ?

C’est hibernation et il s’agit de mettre le contenu de la RAM dans un espace de stockage (typiquement un espace swap de faible priorité) afin de recharger ce contenu dans la RAM au lancement. Si la machine ne s’éteint pas, ce n’est pas de l’hibernation.
Il me semble qu’il existe la mise ne veille hybride qui met le contenu de la RAM dans un espace swap et qui met en veille la machine, ce qui fait que, pour passer de la mise en veille à l’hibernation, il « suffit juste » de couper l’alimentation.

oui pardon, hibernation, je ne sais pas pourquoi j’ai tapé hivernation :wink:
Pas de contre indication à l’utiliser, donc ?

Bonjour

Comme l’hibernation consiste à écrire dans un fichier (swap) sur le disque
et relire ensuite ce fichier à la sortie d’hibernation du système,
je ne vois pas du tout où il pourrait y avoir un problème pour le disque,
qu’il s’agisse d’un SSD ou pas.

S’il était déconseillé de lire ou/et écrire sur un disque, à quoi d’autre pourrait-il bien servir ?

2 J'aime

Il y a plusieurs types de mise en veille. Ne connaissant pas Xfce, j’ignore de laquelle il s’agit.

  • La mise en veille « simple » (suspend to RAM) consiste à arrêter la plupart des composants (processeur, carte graphique, disques…) sauf la RAM.

  • La mise en veille « profonde » ou hibernation (suspend to disk) consiste à enregistrer l’état du système sur disque (généralement en swap) et éteindre complètement la machine.

  • La mise en veille « hybride » combine les deux : l’état du système reste en RAM et est écrit sur le disque. Cela permet une reprise très rapide grâce aux données en RAM mais aussi une reprise en cas de coupure d’alimentation ou d’épuisement de la batterie grâce aux données sur disque.

Sauf utilisation particulière, 8 Go de swap pour 4 Go de RAM est probablement surdimensionné. D’autre part, si ce swap vient à être utilisé pour le fonctionnement normal ou l’hibernation, il serait plus performant sur le SSD.

Apparemment certains croient encore qu’il faut à tout prix éviter d’écrire sur un SSD, et donc qu’il ne doit contenir que des données statiques sous peine de l’user…

Peux-tu préciser cette notion de « swap de faible priorité » ?
D’après mon expérience faite avec systemctl hibernate, l’hibernation utilise systématiquement le swap qui est en première position dans /proc/swaps, quelle que soit sa priorité par rapport aux autres, et quel que soit le swap défini par la variable RESUME dans /etc/initramfs-tools/{initramfs.conf,conf.d/*} ou le paramètre resume du noyau.

Merci à tous pour vos réponses.

Sauf utilisation particulière, 8 Go de swap pour 4 Go de RAM est probablement surdimensionné. D’autre part, si ce swap vient à être utilisé pour le fonctionnement normal ou l’hibernation, il serait plus performant sur le SSD.

en fait jusqu’à récemment, j’avais juste 1Go. Je suis monté à 8 pour cette histoire d’hibernation (« au cas où » le système ait vraiment besoin de beaucoup d’espace dans des cas extrêmes).

Effectivement, il y a le choix :
Capture d’écran_2022-01-23_15-50-54

Je présume que « Mise en veille » est en RAM et « Mise en veille prolongée » est l’hibernation sur disque.

oui, je viens de faire les deux tests et je confirme : c’est bien ça

Certes, pour les données c’est idiot, mais les SSD ont une durée de vie effectivement liée au TBW. mais il faut déjà écrire de gros volumes de données chaque jour pendant 10 ans.

À mon humble avis, je pense que la majorité de ces « légendes urbaines »
concernant le manque de fiabilité des SSD remontent de l’époque des tout premiers SSD
qui étaient effectivement, de par les composants utilisés et la façon dont ils étaient électroniquement gérés beaucoup moins fiables que les SSD fabriqués de nos jours.

Depuis cette époque, la technologie des SSD a considérablement évolué (et ce n’est pas que du « marketing »), tant au niveau des puces mémoire utilisées que des puces contrôleur intégrés dans ces disques.

Mais je ne saurai dire s’ils sont maintenant aussi fiables qu’un disque rotatif.

Ceci dit, on ne peut pas non plus trop généraliser, car il y a des disques rotatifs très fiables, et des SSD de mauvaise qualité et l’inverse est aussi vrai, sans compter que tout dépends aussi des conditions dans lesquelles on les fait fonctionner.

ça ne change rien au fait des cellules et du TBW. les disques sont qualifiés par les constructeurs pour 10 ans au titre d’un certain niveau d’écriture de données dans le temps. le disque peut durer longtemps ou moins longtemps.
A mon boulot on a deux disques SSD IBM iseries/IBMi qui ont duré moins longtemps que la durée prescrite par IBM.

La durée d’un disque vaut par son nombre d’écritures (aussi bien pour les SSD que les non SSD) par rapport au temps.

un disque avec lequel on écrit peu pourra durer plus longtemps, et l’inverse est aussi vrai.

Sur chaque espace de stockage attribué au swap, on peut définir un priorité (aussi appelée « swapiness ») qui consiste à définir si on doit vite mettre le contenu inutilisé de la RAM en swap, lequel ou pas.
Si tu veux utiliser le swap pour l’hibernation, il est conseillé de lui mettre une priorité faible afin qu’il soit entièrement disponible pour cet usage, et non partiellement occupé par des données qui dépassent de la RAM.

Bonjour,

le contenu inutilisé, really ?
Mais à quoi ça servirait d’occuper de l’espace swap par du contenu inutilisé ?
Merci,

Je ne connais qu’un seul paramètre « swappiness » global (vm.swappiness) qui s’applique à tous les swaps, et qui est distinct de la priorité affectée à chaque swap lors de son activation.

Certes c’est souhaitable [1]. Or d’après mon expérience c’est le premier swap activé qui a la plus grande priorité par défaut si on ne la force pas et qui est utilisé pour l’hibernation, donc c’est contradictoire avec l’objectif. Un autre problème potentiel est qu’avec systemd, je ne suis pas certain si les swaps sont activés dans l’ordre dans lequel ils sont listés dans /etc/fstab ou dans l’ordre de leur découverte (qui peut varier).

[1] Note pour les lecteurs : l’hibernation gérée complètement par le noyau ne peut utiliser qu’un seul swap. Il se peut que des systèmes d’hibernation mixte noyau+userland comme uswsusp soient plus souples, je n’ai pas regardé.

Il faut le demander aux applications qui stockent des données en mémoire mais n’y accèdent jamais ensuite.

Un message a été scindé en un nouveau sujet : Hibernation : pm-hibernate ne se termine pas