Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 23-11-2016 18:41:51

papy-tux
Membre
Distrib. : Debian Jessie
Noyau : Linux 4.7.0-0.bpo.1-amd64
(G)UI : xfwm4
Inscription : 22-05-2014

Rognage de la partition swap sur un SSD - Résolu

Bonjour,

J'ai remplacé, il y a plusieurs semaines, le disque dur de mon pc par un disque ssd. Sur le disque, trois partitions : /, /home et swap.

* Concernant le "rognage" des partitions / et /home, j'ai suivi les recommandations du wiki debian avec un fstrim hebdomadaire et pas de problème à signaler pour l'instant.

* Par contre, pour le swap, je ne sais pas quoi faire :
** Est-ce que le fameux rognage est nécessaire ? (pour récupérer la place occupée lors des précédentes hibernations)
** Si oui, comment faut-il le faire (la commande strim demande un système de fichier monté ...)

Merci de votre aide

Dernière modification par papy-tux (24-11-2016 12:33:33)

Hors ligne

#2 23-11-2016 19:50:46

raleur
Membre
Inscription : 03-10-2014

Re : Rognage de la partition swap sur un SSD - Résolu

Un swap supporte l'option "discard". Cf. "man swapon".

Hors ligne

#3 24-11-2016 12:33:04

papy-tux
Membre
Distrib. : Debian Jessie
Noyau : Linux 4.7.0-0.bpo.1-amd64
(G)UI : xfwm4
Inscription : 22-05-2014

Re : Rognage de la partition swap sur un SSD - Résolu

Bonjour,

Merci raleur pour ta réponse.

D'après le man swapon, il est clair que swapon accepte l'option discard et que cela peut parfois apporter une amélioration des performances. Je n'ai remarqué de problème pour l'instant, mais je vais ajouter l'option discard dans fstab au cas où cela serait mieux sur le long terme.

Je marque le sujet comme résolu.

Hors ligne

#4 24-11-2016 15:59:47

raleur
Membre
Inscription : 03-10-2014

Re : Rognage de la partition swap sur un SSD - Résolu

Il a été rapporté que le "online TRIM" activé par l'option "discard" de fstab pour un système de fichiers pouvait pénaliser les accès au SSD, notamment lorsque ce dernier ne supporte que la variante "non-queued" (bloquante) de la commande TRIM, ou bien lorsqu'il figure sur la liste noire incluse dans le noyau des modèles pour lesquels la variante "queued" (non bloquante) est connue comme non fiable et pouvant entraîner des pertes de données. Pour cette raison certains lui préfèrent le "batch TRIM" effectué périodiquement à une heure creuse avec la commande fstrim.

Le man swapon indique que l'option "discard" peut appliquer deux politiques :
- discard=pages active le "online TRIM" pour marquer les blocs comme libres au fur et à mesure lorsqu'ils ne contiennent plus de données utiles (par exemple lorsqu'un processus qui avait des pages mémoire swappées se termine ou lorsqu'une page en swapcache est modifiée en mémoire), ce qui peut pénaliser l'accès au SSD à ce moment ;
- discard=once effectue un "batch TRIM" pour marquer tous les blocs de la zone de swap comme libres lors de l'activation du swap, ce qui peut pénaliser l'accès au SSD au démarrage.

L'option "discard" seule sans aragument active les deux politiques.

"discard=once" semble intéressant pour marquer comme libres les blocs qui ont servi pour l'hibernation. Néanmoins je ne sais pas si lors de la reprise après hibernation le swap est activé à nouveau avec swapon et effectue le TRIM ou si le noyau ne fait que restaurer son état antérieur dans lequel le swap était activé, sans passer par swapon ni effectuer le TRIM. Dans le second cas, je ne suis même pas sûr qu'avec "discard=pages" le noyau effectue le TRIM sur les blocs ayant servi à l'hibernation.

Dans le pire des cas, il faudrait faire un redémarrage normal avec discard=once pour que le swap soit TRIMé après une hibernation.

Hors ligne

Pied de page des forums