Le point sur Linux et les SSD
Rédigé par antistress le 24 septembre 2011 (mis à jour le 19 juin 2022) - 41 commentaires
Mon nouveau joujou
(crédit photo : Crucial)
Cela fait un moment que j'observe à distance l'actualité des SSD.
À distance, car les prix restent encore élevés, surtout comparé aux disques dur.
Pourtant la tentation est forte : ainsi ce billet de kiddo me trottait dans la tête. Surtout la vidéo impressionnante dont le lien est donné en fin de son billet...
Finalement, je me suis fait plaisir et ai profité d'une (petite) promotion pour acquérir un SSD Crucial M4 de 64 Gio.
Présentation
Pour rappel, avec le SSD, on change complètement de paradigme par rapport au traditionnel disque dur.
À ma gauche : le disque dur magnétique, qui consiste en un ou plusieurs plateaux tournant à grande vitesse (généralement 5 400 ou 7 200 tours/min) parcourus par une ou deux têtes de lecture (une par face utile) chargée de lire la piste magnétique du disque (de densité variable). Tous ces éléments détermineront la capacité, le débit et les temps d'accès du disque.
Vue interne d'un disque dur magnétique
(crédit photo : Samsung)
Cette conception mécanique peut s'avérer fragile (principalement pour un appareil mobile) aussi certains fabricants ont récemment tenté de limiter la complexité du disque pour palier à cet inconvénient. Citons ainsi le Samsung Spinpoint F4 320 Gio conçu pour concurrencer les SSD sur les ordinateurs portables et autres netbooks : un seul plateau, une seule tête de lecture, lecture/écriture sur un demi-plateau seulement afin de réduire les mouvements et les frottements pour une plus grande fiabilité, des performances accrues et une consommation réduite.
À ma droite : le SSD, de conception récente et qui, au contraire, ne comporte aucune pièce mécanique. Il est constitué de mémoire NAND FLASH, c'est à dire de composants électroniques. Aussi, après l'abandon de la disquette et la raréfaction des lecteurs optiques (CD, DVD, B-RD), le disque dur reste parfois le seul composant mécanique d'un PC là où le SSD se fond parfaitement au milieu de tous les autres composants de nature purement électronique : barrette de mémoire vive, microprocesseur, carte mère ou fille :
Vue interne du SSD Crucial M4 64 Gio
(crédit photo : Hardware.fr)
Cette différence de conception confère certains avantages au SSD :
- résistance aux chocs,
- silence de fonctionnement (la rotation ultra-rapide des plateaux d'un disque dur peut laisser entendre un sifflement tandis que l'action des têtes des lectures peut laisser entendre un bruit de grattage) et faible dégagement de chaleur,
- débits rapides (deux à cinq fois ceux d'un disque dur),
- surtout : temps d'accès négligeables (entre 0,05 et 0,1 ms contre une moyenne de 13 ms pour un disque dur).
Mais aussi un inconvénient (habituel s'agissant d'une nouvelle technologie) : les systèmes d'exploitation actuels doivent être mis à jour pour gérer les SSD, l'écriture de données sur un SSD étant physiquement très différente de l'écriture de données sur un disque mécanique (même si le contrôleur du SSD s'emploie à « traduire en langage SSD » les instructions qu'il reçoit).
Signalons enfin que les capacités actuellement disponibles sont un peu plus faibles que pour un disque mécanique, et, surtout, le prix au Gio reste bien plus élevé. Du coup, la plupart du temps, un disque mécanique sera utilisé en complément du SSD.
Passons rapidement sur les caractéristiques du SSD Crucial M4 (puces MLC NAND FLASH Micron de 25nm couplées à un contrôleur Marvell 88SS9174-BKK2, pages de 4 Kio organisées en blocs de 1 Mio, interface SATA 6 Gio/s), pour ne retenir que ceci (opinion forgée d'après les tests publiés sur le Web et les conseils avisés des forumeurs d'Hardware.fr comme d'habitude) :
- la marque jouit d'une bonne réputation de fiabilité,
- ce modèle est reconnu pour ses performances,
- aucun défaut du contrôleur n'a été constaté lors des tests,
- comme tous les SSD récents, il gère la fonction TRIM qui permet d'éviter un effondrement des performances avec le temps (lire ci-après) (à vérifier d'un
hdparm -I /dev/sdX>
où sdX désigne votre SSD).
Configuration
Avant toutes choses, vérifiez que dans l'UEFI de votre carte mère, votre SSD est bien signalé comme tel. Et mettez à jour le firmware de votre SSD le cas échéant.
Au niveau du système d'exploitation maintenant :
Rassurez-vous, aujourd'hui les systèmes d’exploitation sont adaptés pour prendre en charge au mieux les SSD de sorte que les réglages proposés ici sont facultatifs et relèvent de l'optimisation.
La plus importante est sans doute de s'assurer du bon alignement des partitions du SSD.
Vérifier l’alignement des partitions
L'alignement consiste à faire correspondre les blocs logiques des partitions avec les blocs physiques du SSD afin de limiter les opérations de lecture/écriture et ainsi ne pas entraver les performances.
Les SSD actuels travaillent en interne sur des blocs de 1 ou 2 Mio, c'est à dire respectivement 1 048 576 ou 2 097 152 octets. Considérant qu'un secteur stocke 512 octets, il faudra ainsi 2 048 secteurs pour stocker 1 048 576 octets.
Si, traditionnellement, les systèmes d'exploitation faisaient démarrer la première partition au 63è secteur, les dernières versions prennent en compte les contraintes des SSD. Ainsi GNU Parted (libparted) version 2.2 ou supérieure, outil traditionnellement utilisé par les distributions lors de leur installation, aligne automatiquement les début des partitions sur des multiples de 2 048 secteurs.
Pour vous assurer du bon alignement des partitions de votre SSD, entrez la commande suivante avec les privilèges d'administration, et vérifiez que le nombre de secteurs au début de chacune de vos partitions est bien un multiple de 2 048 : fdisk -lu /dev/sdX
(où sdX désigne votre SSD).
Si l'alignement des partitions est automatiquement géré avec les versions récentes de vos logiciels, la fonction TRIM, en revanche, est désactivée par défaut... et nous allons voir que ce n'est pas un hasard.
Activer le TRIMming
Pour comprendre en quoi consiste la commande ATA_TRIM, je vous renvoie à ces explications détaillées données par Marc Prieur sur le site Hardware.fr.
Les bases étant posées, nous allons voir que, sous Linux, il existe deux implémentations alternatives de la commande ATA_TRIM :
TRIM à la volée
La fonction TRIM est disponible pour ext4 depuis la version 2.6.33 du noyau Linux.
Pourtant elle n'est pas active par défaut... Pour y remédier, vous devrez ajouter discard
sur la ligne de votre partition dans le fichier /etc/fstab.
Remplacer :
errors=remount-ro
par :
errors=remount-ro,discard
Précisons que, pour que le TRIMming opère, toute la chaîne doit être compatible : non seulement le SSD et le système d'exploitation, mais aussi le contrôleur ATA. En pratique c'est généralement le cas des contrôleurs Serial ATA supportant la norme AHCI (à activer dans le BIOS). En théorie il suffirait d'un contrôleur ATA gérant le 48-bit LBA addressing pour peu que son pilote supporte le TRIM mais ça ne semble pas être le cas sous Linux si j'en crois mon expérience personnelle (le test du TRIM ayant échoué dans mon cas). NB : Si votre système ne gère pas le TRIM, pensez à laisser un espace non utilisé (sans partition), 4 Go par exemple sur un SSD 64 Go.
TRIM différé
La méthode précédente va exécuter la commande TRIM au coup par coup (on parle alors de on-the-fly trim, online discard ou encore realtime discard), et la plupart du temps au milieu d'une séquence de lecture/écriture, ce qui ne sera malheureusement pas le moment le plus optimal.
Il est toutefois possible de différer l'exécution des commandes TRIM en vue de les traiter en bloc à un moment où le SSD sera moins sollicité (on parle alors de batch discard) : c'est ce que permet la fonction FITRIM qui est disponible pour ext4 à partir de la version 2.6.37 du noyau.
En pratique cette fonction est appelée par le programme /sbin/fstrim (que l'on trouve dans la collection de logiciels util-linux version 2.19 ou supérieure) qui pourra donc être lancé manuellement de temps en temps, un peu comme on défragmente un disque dur.
Vous pouvez plus simplement programmer un lancement régulier : une fois par semaine semble raisonnable pour un usage standard. Pour cela, vous allez créer avec les privilèges d'administration le fichier /etc/cron.weekly/batched_discard.
Copiez-y ce script (pour TRIMmer les répertoires / et /home) :
#!/bin/sh
LOG=/var/log/batched_discard.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG
Et, toujours avec les privilèges d'administration, rendez ce fichier exécutable à l'aide de la commande suivante :
chmod 755 /etc/cron.weekly/batched_discard
(à ce stade vous pouvez tester le script en le lançant à la main, avec les privilèges d'administration : bash /etc/cron.weekly/batched_discard
).
Vous pourrez ensuite consulter le journal des TRIM avec la commande suivante :
tail /var/log/batched_discard.log
(source)
Vous aurez donc intérêt à privilégier cette dernière méthode si vous avez un noyau suffisamment récent.
Puisque nous avons les mains dans le cambouis, profitons-en pour voir quelques réglages « bonus ».
Les choix retenus ci-après vont servir à maximiser les performances et à préserver la durée de vie du du disque en limitant le nombre d'accès disque.
Spécifier l'attribut noatime
ext4 est un système de fichiers journalisé. La journalisation sert à garantir l'intégrité des données en cas d'arrêt brutal du système. Cette importante fonction a toutefois un coût en termes de performances (accroissement des accès disque). Plutôt que de chercher à supprimer la journalisation, nous allons voir comment réduire son impact sur les performances.
Selon Theodore Ts'o (développeur d'ext4), c'est lorsque le système ext4 est utilisé avec l’attribut noatime
que l'on obtient la meilleure combinaison : le surcroit du nombre d'accès disque est alors limité à quelques pourcents (rappelons que l'attribut noatime
sert à désactiver l’enregistrement systématique de la date du dernier accès aux fichiers, chose parfaitement inutile si vous ne stockez pas de secrets d'État pour lesquels vous voudriez vérifier si quelqu'un d'autre y a accédé).
Cela se configure à partir du fichier /etc/fstab, en ajoutant noatime
sur la ligne de votre partition.
Remplacer :
errors=remount-ro
par :
errors=remount-ro,noatime
ou, selon le cas :defaults
par :
defaults,noatime
La commande mount
vous confirmera que la modification a bien été prise en compte.
Augmenter le commit
Le système de fichier ext4 possède un paramètre qui s'appelle commit. C'est le temps maximum qui se passe entre le moment où une application demande à écrire une donnée sur disque et le moment où ext4 ira effectivement l'écrire sur disque. Par défaut, cette valeur est réglée à 5 secondes. ext4 attendra donc au plus 5 secondes avant d'écrire une donnée sur disque.
ext4 possède une relative intelligence: Par exemple si un fichier est créé puis supprimé dans ces 5 secondes, il n'ira faire aucune écriture disque (C'est inutile, puisque le fichier est supprimé). En montant le commit à 60 secondes, on arrive ainsi à éviter des écritures disque.
Dans les options de montage de vos partitions (/etc/fstab), ajoutez simplement l'option commit=60. Exemple:
UUID=4a5773ef-7833-4741-c53f-8de2dd3d7527 / ext4 errors=remount-ro,commit=60 0 1
Notez que régler le commit à 60 secondes veut dire que si votre ordinateur plante, vous risquez de perdre au plus les 60 dernières secondes d'écriture disque (au lieu des 5 secondes par défaut). À vous de voir si vos opérations disque sont critiques à ce point.
Modifier l'ordonnanceur de tâches d'E/S ?
Avant-propos
Le choix d'un ordonnanceur de tâches d'E/S doit être fait disque par disque, en fonction de sa technologie : disque dur mécanique, SSD SATA ou SSD NVMe.
Les ordonnanceurs de tâches d'E/S à file d'attente unique (single-queue schedulers) – à savoir : NOOP, Deadline et CFQ – n'étant plus pris en charge par le noyau depuis sa version 5.0, le choix est à faire parmi les ordonnanceurs de tâches d'E/S à multiples files d'attente (multi-queue schedulers), soit : mq-deadline, Kyber ou BFQ.
Étape préliminaire : vérifier que le SSD est bien reconnu comme tel
La première chose à faire, surtout pour les vieux SSD, est de vérifier qu'ils sont bien reconnus comme tels par le système. Si la commande cat /sys/block/sdX/queue/rotational
(où sdX désigne votre SSD) renvoie la valeur 0 c'est que le SSD est bien reconnu comme tel. Si c'est la valeur 1 qui s'affiche, alors le système croit gérer un disque rotatif et il faut modifier manuellement le paramètre : avec les privilèges d'administration entrer la commande sudo sh -c 'echo 0 > /sys/block/sdX/queue/rotational'
(où sdX désigne votre SSD) et le tour est joué.
Modifier l'ordonnanceur de tâches d'E/S
Ensuite, pour connaître l'ordonnanceur d'un disque :
cat /sys/block/sdX/queue/scheduler
Puisque mq-deadline est le choix par défaut d'un certain nombre de distributions (mais c'est en train de changer), la réponse devrait généralement être (celle-ci figure entre crochets) :
[mq-deadline] none
Pour changer l'ordonnanceur pour BFQ :
echo "bfq" | sudo tee /sys/block/sdX/queue/scheduler
À présent si vous posez la question de ordonnanceur du disque, vous devriez obtenir :
mq-deadline [bfq] none
Idem, pour changer l'ordonnanceur pour Kyber :
echo "kyber" | sudo tee /sys/block/sdX/queue/scheduler
Pour un SSD rapide on pourra laisser le choix par défaut (mq-deadline) ou opter pour Kyber, tandis que pour un SSD lent on pourra préférer BFQ (voir 1, 2).
Pour mon Crucial M4 de 64 Gio j'ai choisi l'ordonnanceur BFQ dans le sillage de Fedora 31 et en suivant les recommandations de son développeur : en effet les performances de ce SSD sont données pour 45 000 IOPS en lecture aléatoire et 20 000 IOPS en écriture aléatoire, bien en dessous des limites de BFQ.
Deux cas où il n'y aura pas vraiment à hésiter : none sera à privilégier pour un SSD NVMe, et BFQ sera à privilégier pour un disque dur mécanique.
Stocker les fichiers temporaires en mémoire vive
Toujours dans le but de minimiser les accès disque, à partir d'1 Gio de RAM on peut concevoir de stocker les fichiers temporaires en mémoire vive plutôt que sur le disque (attention : la mémoire vive étant volatile, les données seront perdues en cas de coupure de courant).
Toujours dans le fichier /etc/fstab, créer un système de fichiers temporaire (temporary file system, ou tmpfs) pour y placer le dossier les fichiers temporaires :
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/lock tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/run tmpfs defaults,noatime,mode=1777 0 0
Même démarche s'agissant de Firefox, mais en utilisant ses propres réglages : dans la barre d'adresse de Firefox, saisir « about:config », puis :
- Réglez la valeur booléenne (la créer si elle n'existe pas déjà)
browser.cache.disk.enable
sur
false
pour désactiver le cache sur le disque. - Réglez la valeur booléenne (la créer si elle n'existe pas déjà)
browser.cache.memory.enable
sur
true
pour activer le cache en mémoire vive. - Réglez le nombre entier (le créer si il n'existe pas déjà)
browser.cache.memory.capacity
sur
-1
pour laisser Firefox décider de la quantité de mémoire vive maximale à utiliser pour son cache (voir le tableau de correspondance).
Désactiver le swap...
Si vous possédez suffisamment de mémoire vive pour votre usage (1-2 Gio pour un usage « classique »), vous pourrez désactiver le swap en commentant la ligne ad hoc dans l'habituel fichier /etc/fstab (=la faire précéder du caractère dièse #
). Et si le besoin s'en fait sentir, vous pourrez le réactiver très facilement par la procédure inverse.
...ou le réduire avec swappiness
Le noyau de Linux possède un paramètre (vm.swappiness) qui indique la propension du système à swapper. Dans la plupart des distributions, ce paramètre est réglé à 60. C'est à dire que quand la mémoire vive sera remplie à 40%, le système va commencer à swapper préventivement des pages mémoire vers le disque (afin de ne pas pénaliser tout lancement éventuel d'une nouvelle application).
On peut sans problème réduire ce paramètre à 10. Ainsi le système ne commencera à swapper que quand 90% de la mémoire sera utilisée.
Avec les privilèges d'administration, ajoutez la ligne vm.swappiness=10 à votre fichier /etc/sysctl.conf à l'aide de la commande suivante :
bash -c 'echo "vm.swappiness=10" >> /etc/sysctl.conf'
Pour la prise en compte de ce paramètre, rebootez ou entrez la commande suivante (toujours avec les privilèges d'administration) :
sysctl -p
La vérification se fait avec la commande suivante (toujours avec les privilèges d'administration) :
sysctl vm.swappiness
Activer zram
zram est un module déjà présent dans le noyau (depuis sa version 3.2), mais pas activé. Il permet de créer des block device en mémoire (donc des zones de mémoire utilisables comme un disque), mais qui ont la particularité d'être compressés et décompressés de manière transparente. Tout ce qui est écrit dedans est compressés, et décompressé à la lecture. L’algorithme de compression utilisé est LZO, extrêmement rapide (capable de compresser plusieurs centaines de méga-octets par seconde).
Une simple commande permet d'activer zram qui va – par défaut – créer un block device compressé pour chaque cœur de votre CPU (afin de paralléliser la compression) et y affecter le swap en priorité sur le swap disque.
Le résultat est que dès que votre système aura besoin de swapper, il va commencer à swapper dans ces blocs mémoire compressés. Et il ne commencera à swapper sur disque que si ces blocs mémoire sont pleins. Et votre CPU est tellement rapide qu'utiliser ces blocs mémoire compressés est beaucoup plus rapide que swapper sur disque. Dans la pratique, l'activation de zram va virtuellement éliminer le swapping sur disque.
Pour un SSD, zram permet donc de réduire l'usure en évitant presque totalement les écritures disque liées au swap, tandis que le CPU consommé par zram est à peine perceptible.
Sachez que même si vous créez un zram de 8 Go, celui-ci ne consommera pas 8 Go de RAM. Il ne consomme de la mémoire que quand on y stocke des données (qui généralement sont réduites à 1/2 à 1/3 de leur taille initiale).
Pour installer zram, tapez la commande suivante avec les privilèges d'administration :
apt install zram-tools
zram est alors immédiatement actif, et votre swap configuré pour pointer dessus !
Pour vérifier que votre swap utilise zram, voici la commande :
cat /proc/swaps
Comme résultat, vous verrez des /dev/zramX (un par cœur) avec une priorité supérieure au swap disque. Vous pouvez voir la taille de chaque bloc de swap (Size) et la quantité de données dans ces blocs (Used).
Pour voir l'utilisation des blocs zram, utilisez la commande (avec les privilèges d'administration) :
zramctl
Vous verrez chacun des blocs zram, leur taille allouée (DISKSIZE), la quantité de données qui y est stockée (DATA) et la place qu'ils occupent réellement en mémoire après compression (COMPR). (zram y stock également 12ko de données de travail, la taille totale est donc TOTAL).
Et le partitionnement, alors ?
Soucieux de ne pas entraver le travail du contrôleur du SSD chargé d'étaler l’usure (en anglais : wear levelling), vous hésitez peut-être à partitionner votre disque (pour isoler le /home du reste du système par exemple). Et bien n'hésitez plus : les partitions n’entravent absolument pas le wear levelling. Comme l'indique Marc Prieur : il n'y a pas de correspondances entre les adresses logiques (LBA) attribuées à une partition et les pages physiques de la Flash derrière. Selon les besoins, le SSD peut très bien utiliser une page auparavant destinée à la partition 2 pour la partition 1, et vice-versa
.
Conclusion
Où la capacité impacte le prix mais aussi les performances et la durée de vie
Si le prix au Gio d'un SSD reste nettement plus élevé que celui d'un disque dur magnétique, on commence à trouver cette année des disques durs à prix abordable (compter 70-100 € pour un SSD de 60-64 Gio) sans parler des promotions ponctuelles (on peut alors trouver des SSD en quantité limitée à 1€ le Gio).
On notera que, de par leur conception, les SSD de capacité supérieure offrent souvent de meilleures performances (compte tenu d'un plus grand nombre de puces travaillant en parallèle. Toutefois cet avantage peut être réduit par l'emploi de pages plus grandes, pénalisantes en cas d'accès à de petits fichiers : par exemple à partir de la version 256 Mo, les SSD Crucial M4 utilisent des pages de 8 Kio organisées en blocs de 2 Mio contre des pages de 4 Kio organisées en blocs de 1 Mio pour les versions inférieures) et toujours une durée de vie plus importante (la technique de répartition de l'usure évoquée ci-dessus profitant du nombre accru de cellules).
Toutefois un SSD de 64 Gio offre aujourd'hui un très bon compromis et cette capacité suffit largement pour un disque système. Un tel disque sera alors la plupart du temps complété par un disque dur magnétique pour le stockage (plus un autre, interne ou externe, pour vos sauvegardes !).
Le confort comme maître-mot
Passée la première impression bluffante de vitesse (c'est le même PC ?!), c'est l'impression de confort qui s'impose : tout est plus réactif.
De même que le passage des écrans cathodiques aux écrans LCD TFT a pu offrir, outre des diagonales démesurées, une image stable pour un meilleur confort de lecture, le passage du disque dur mécanique au SSD réduit les temps morts et rend le quotidien plus confortable. Difficile de revenir en arrière !
Accès rapide :
- Présentation
- Configuration
- Vérifier l’alignement des partitions
- Activer le TRIMming
- Spécifier l'attribut noatime
- Augmenter le commit
- Modifier l'ordonnanceur de tâches d'E/S ?
- Stocker les fichiers temporaires en mémoire vive
- Désactiver le swap...
- ...ou le réduire avec swappiness
- Activer zram
- Et le partitionnement, alors ?
- Conclusion