[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.