Re: [Linux-31] Optimisation de SSD sous GNU/Linux sur PC portable

[Pascal Hambourg <pascal AT plouf.fr.eu.org>]

Le 26/12/2020 à 15:38, Joyce MARKOLL (via linux-31 Mailing List) a écrit :
> Par contre je voudrais un avis sur deux types d'optimisation, que sont le 
> fait de laisser
> de l'espace non formaté à la fin du SSD, et l'activation du cache.

Optimisation selon quel critère ? (Pour rappel, la notion d'optimisation 
n'a de sens que par rapport à un critère défini.)

> Ayant aussi optimisé des SSD sous Windows, avec les outils fournis par les 
> constructeurs,
> j'ai compris ceci : le programme suggère de laisser 10% de l'espace total non 
> formaté.

Une chose est sûre : ça n'optimise pas la capacité utile. Par contre ça 
optimise le coût de fabrication par rapport à augmenter la capacité 
interne du SSD.

> J'ai lu ailleurs que la ligne de commande "sudo hdparm -W1 /dev/sd(x)" (où 
> sd(x) peut
> être sda, sdb etc.) permet d'activer le cache (cache : "on" répond la 
> commande).

Cette commande active le cache *en écriture* du disque. Elle n'est utile 
que si le cache en écriture est désactivé par défaut. Je n'ai pas de 
SSD, mais le cache en écriture est activé par défaut sur tous mes 
disques durs et je n'ai pas de raison de penser qu'il ne l'est pas sur 
les SSD.

> Qu'en pensez-vous ? Hormis créer des partitions séparées pour les répertoires 
> qui usent
> le plus sur un hdd

Si le critère est la durée de vie du SSD, le mieux est encore de ne pas 
l'utiliser du tout et de tout mettre sur un disque dur.
Trève de plaisanterie : un SSD est fait pour être utilisé. 
Eventuellement on peut ne pas y mettre :
- des données volatiles qui peuvent aller dans un tmpfs (pour l'usure et 
la rapidité)
- des données qui font l'objet d'écritures fréquentes ou massives mais 
ne sont jamais ou rarement lues, comme certains logs (pour l'usure)
- des données volumineuses qui ne nécessitent pas un accès rapide, comme 
des fichiers audio ou vidéo (si la capacité est limitée).

> mettre /var/* en tmpfs,

Quelle drôle d'idée. Le contenu de /var n'est pas censé être volatil à 
quelques exceptions près.

> pensez-vous que dédier 10% de l'espace d'un SSD pour le "garbage
> collector" permette effectivement d'allonger la durée de vie des SSD ?

Ça peut y contribuer dans certains cas, en réduisant l'amplification de 
l'écriture, à condition que cet espace non alloué ait été préalablement 
"TRIMé". Ça peut aussi optimiser la vitesse d'écriture soutenue en 
augmentant la quantité de blocs libres pour l'écriture. Mais le gain 
sera négligeable si la quantité de blocs libres est déjà suffisante.

Si on utilise le TRIM pour marquer les blocs libre dans les partitions, 
on dispose déjà d'une réserve équivalente à l'espace libre. Avec 
l'avantage qu'un système de fichiers "respire" d'autant mieux qu'il a de 
l'espace libre. En d'autres termes, il vaut mieux une partition occupant 
100% de l'espace disque et remplie à 90% qu'une partition occupant 90% 
de l'espace disque et remplie à 100%.

Et si on n'utilise pas le TRIM ou si le système de fichiers est plein ? 
Les SSD réservent déjà une partie leur capacité brute. Ce n'est pas un 
hasard si les SSD ont des capacités proches mais inférieures à des 
puissances de 2. Comme la RAM, et contrairement aux disques durs, la 
capacité des puces de mémoire flash est une puissance de 2 pour des 
questions d'adressage physique. Ainsi on trouve chez les SSD des 
capacités de 32 Go, 64 Go, 120-128 Go... mais pas des capacités comme 40 
Go, 160 Go, 320 Go qui étaient courantes chez les disques durs. Le SSD 
se réserve donc déjà la différence entre la capacité affichée et la 
capacité brute (puissance de 2 immédiatement supérieure).

L'écart n'est pas négligeable : par exemple sur un SSD qui affiche une 
capacité utile de 120 Go et qui a une capacité brute de 128 Gio soit 137 
Go, l'espace réservé est de 17 Go, soit 14%. Est-il vraiment utile d'y 
ajouter 10% de plus prélevés sur la capacité utile ?

> Dans le détail, "garbage collector" qu'est-ce au juste ?

Pour le détail, Wikipédia est ton ami. Dans le contexte des supports de 
stockage à mémoire flash, "garbage collector" ("ramasse-miettes" en 
français) désigne le mécanisme qui sert à réutiliser les blocs contenant 
des données partiellement invalides.

Petit rappel sur les spécificités des mémoires flash NAND utilisées dans 
les SSD et différences avec les disques magnétiques :
- une cellule de mémoire flash dans laquelle on a écrit doit être 
effacée avant d'y écrire à nouveau
- l'écriture est plus lente que la lecture
- l'effacement est plus lent que l'écriture
- l'écriture se fait par bloc appelé "page"
- l'effacement se fait par bloc d'effacement (erase block) qui regroupe 
plusieurs pages ; on ne peut pas effacer une page individuellement

Physiquement, une page peut avoir deux états :
- effacée (prête pour l'écriture)
- écrite (impropre pour une nouvelle écriture)

Logiquement, on distingue trois états :
- vide (effacée)
- écrite avec des données valides (ne devant pas être effacées)
- écrite avec des données invalides (pouvant être effacées)

Les données d'une page peuvent devenir invalides de trois façons :
- si elles ont été marquées invalides par le système hôte (TRIM)
- si elles ont été modifiées par le système hôte et écrites dans une 
nouvelle page vide
- si elles ont été réécrites dans une nouvelles page vide d'un autre 
bloc par le garbage collector (voir plus bas)

Les nouvelles données ne sont pas écrites à l'emplacement physique des 
anciennes données qu'elles remplacent car il faudrait l'effacer 
préalablement, ce qui serait beaucoup trop lent et userait prématurément 
les emplacements dans lequels on écrit le plus souvent. Au lieu de cela, 
on écrit simplement les données dans une nouvelle page vide et on marque 
les anciennes données comme invalides.

On comprend donc aisément que pour assurer une vitesse d'écriture 
optimale et le nivellement de l'usure il faut maintenir un stock de 
pages vides suffisant, et donc effacer régulièrement les données 
devenues invalides.

Un bloc est éligible à l'effacement seulement si toutes ses pages sont 
vides ou contiennent des données invalides. Si une page du bloc contient 
des données valides, il faut d'abord la recopier dans une page vide d'un 
autre bloc avant de pouvoir l'effacer. C'est le rôle du garbage collector.

L'opération de déplacement d'une page occasionne une écriture. Il y a 
donc plus d'écritures réelles que celles demandées par le système hôte. 
C'est ce qu'on appelle l'amplification d'écriture, qui participe à 
l'usure du SSD.

Plus il y a de blocs en réserve, plus on peut se permettre d'attendre 
qu'un maximum de pages deviennent invalides avant de déclencher le 
garbage collector. Ainsi il y aura moins de pages à déplacer et moins 
d'usure liée au garbage collector.