Le stockage SSD fait indéniablement sa place dans le secteur informatique, à la fois chez les particuliers sur leurs ordinateurs familiaux, que sur les serveurs professionnels utilisés dans le cloud. Cette technologie a l’avantage de remplacer les disques durs magnétiques avec une parfaite compatibilité SATA. Sous Linux et selon la distribution utilisée, il y a des réglages à mettre en place pour augmenter leur durée de vie et accélérer les échanges au maximum. Ces réglages prendront tout leur sens sur un serveur professionnel notamment en datacenter.

La commande TRIM

Généralités

TRIM est une commande lancée par le système d’exploitation au contrôleur de SSD, et qui indique que certains blocs de données sont libérés suite à une suppression de fichier, et qu’ils peuvent être effacés.

Cela a pour premier effet d’améliorer les performances d’accès aux disques SSD. En deuxième effet, le contrôleur SSD est capable de lisser l’usure des cellules (wear leveling) en ne réécrivant pas trop de fois au même endroit. La longévité du SSD dépend de cette commande.

Les premiers modèles de SSD apparus autour de 2007 n’implémentaient pas cette commande et ils avaient souvent des problèmes de longévité. Les modèles de SSD récents permettent tous d’utiliser TRIM, ainsi que les cartes SD et microSD sur lesquelles il est fortement recommandé d’utilisé TRIM. Le pense particulièrement aux Raspberry Pi.

Pour vérifier la prise en charge de cette commande, voici la commande hdparm à utiliser (ici sur le disque sda). L’absence de retour indique l’absence de prise en charge.

Il est important de savoir que la commande TRIM est lancée par le système d’exploitation mais elle est également très fortement liée au système de fichiers utilisé. J’imagine que c’est ce dernier qui indique à l’OS la liste des blocs effacés. Les systèmes de fichiers ne permettent pas tous d’utiliser TRIM.

Une conséquence de la commande TRIM est que les fichiers effacés du lecteur seront perdus à jamais et impossible à récupérer comme sur un disque dur à plateaux. Dans les environnements sensibles cela peut être intéressant.

Paramètre discard sur ext4

Le plus souvent sur internet, on trouve un réglage ext4 à inclure dans /etc/fstab qui s’appelle « discard ». Normalement, cet ajout permet d’utiliser la commande TRIM de manière transparente.

Néanmoins, cette commande TRIM fait appel à beaucoup d’éléments différents (OS, système de fichiers, matériel) et il est possible qu’elle échoue sans prévenir pour différentes raisons, par exemple si le noyau inférieur à 2.6.33 ne gère pas la commande.

De plus, cette méthode est de plus en plus déconseillée, par Ubuntu notamment. On va donc s’empresser de l’oublier.

Fstrim avec ext4

En ligne de commande

En complément ou plutôt en remplacement, je vous propose de faire appel à la commande TRIM en mode « batch », c’est à dire une fois de temps en temps sur le disque de A à Z, plutôt qu’en continu de manière transparente.

Cela est possible avec les noyaux Linux ultérieurs à la version 2.6.37, et fait appel à la commande fstrim  du paquet util-linux .

Avec l’option verbose on peut voir l’effet de la commande, et être rassuré sur son bon fonctionnement.

Si jamais le périphérique ne supporte pas TRIM, il le dira tout de suite.

Via script maison

Voici un petit script que je lance personnellement tous les jours grâce au cron pour suivre le bon fonctionnement dans un fichier de log. La sortie standard de fstrim est correctement redirigée.

Avec systemd

Alternativement depuis Debian 8, on peut utiliser les possibilités de systemd pour s’occuper du fstrim périodique grâce à une configuration proposée dans /usr/share/doc.

Certaines distributions intègrent le lancement périodique de la commande fstrim par défaut. Cela vaut la peine de vérifier la configuration de systemd pour savoir si c’est le cas chez vous.

En environnement virtualisé

La commande fstrim peut également être utilisée selon un usage détourné sur une machine virtuelle notamment avec KVM. Cela consiste à lancer la commande sur la machine virtuelle qui sera préalablement équipée d’un BUS de données SCSI, et qui fera remonter l’information des blocs libérés jusqu’à l’hyperviseur en charge de l’image disque. Cela est une manière de réduire la taille effectivement occupée par l’image disque. Voici un article de blog détaillé sur le sujet ; le principe est fort, du hacking de bon niveau.

Over-provisioning

L’over-provisioning consiste à exploiter une capacité utile inférieure à la capacité totale du SSD, et à en faire part au contrôleur SSD afin que celui-ci lisse l’usure en écriture sur les cellule. Lors d’une modification de données, au lieu de lire-modifier-écrire une même zone, le SSD sera capable de lire une zone et d’écrire dans une autre (la destruction de la première zone intervenant simultanément). En clair, l’over-provisioning permet au SSD de ne jamais danser du même pied, ce qui se traduit par une longévité supérieure.

Les constructeurs définissent généralement un réglage par défaut. Samsung conseille d’utiliser entre 7% d’over-provisioning (ordinateur personnel) et 20% (applications datacenter).

L’article suivant explique pas à pas comment paramétrer le contrôleur SSD pour réduire la taille utilisable grâce à hdparm. En théorie, cela permettrait de transformer un SSD de 1To peu endurant en SSD de 500Go très endurant.

L’over-provisioning est très intéressant car il permet de forcer le système à conserver de l’espace libre et donc à préserver ses performances. Mais j’ai tout de même l’impression qu’un overprovisioning de 7% ne vaut pas mieux qu’une partition quotidiennement TRIMée avec 7% d’espace libre.

Limiter les écritures intempestives

Les SSD ont une durée de vie limitée en cycles d’écritures qui s’expriment en TBW (terabytes written) et qui dépend du matériel utilisé. Les gammes les plus chères sont souvent les plus endurantes.

Les premiers SSD à sortir avaient une durée de vie très limitée, et pas forcément de commande TRIM, d’où l’obligation des leur épargner un maximum d’écritures lourdes. J’ai souvenir d’un SSD de 32 Go de marque OCZ que j’ai cramé en quelques mois, cela laisse des traces. Si votre SSD est récent et que vous ne prévoyez pas de dépasser sa valeur TBW, les instructions ci-dessous ne sont pas nécessaires. Par contre la commande TRIM reste recommandée !

Le swap

La première chose à laquelle on pense pour limiter les écritures intempestives qui usent les SSD, c’est de travailler sur le swap. Le swap n’est utilisé que lorsque la mémoire est pleine, donc si vous utilisez le swap souvent vous feriez mieux d’augmenter la mémoire ou d’utiliser zRam pour augmenter l’espace allouable comme je l’explique dans cet article.

Si jamais un swap devait être mis en place, on peut réduire le swappiness à zéro afin de commencer à utiliser l’espace d’échange uniquement lorsque la mémoire est pleine. Dans /etc/sysctl.conf :

Si vous migrez depuis un disque dur magnétique, pas de panique vous pouvez désactiver la partition de swap. Si vous êtes courageux vous pouvez éventuellement la supprimer dans gparted et réinstaller/reconfigurer Grub.

 

Dates de dernier accès des fichiers et répertoires

Par défaut, ext4 écrit la date de dernier accès dans les métadonnées des fichiers et des répertoires. Si vous n’en avez pas directement besoin, vous pouvez arrêter ce comportement. Cela a pour effet de soulager le périphérique et d’améliorer légèrement les performances en lecture puisque plus aucune écriture n’est faite, à la fois sur les disques durs magnétiques et SSD.

Placer le /tmp en mémoire

Certains logiciels utilisent le répertoire /tmp intensivement, et placer ce dossier en mémoire va à la fois soulager le SSD et considérablement accélérer ces traitements. Dans le fichier fstab :

On peut spécifier la taille souhaitée, et par défaut la taille est de la moitié de la RAM. A noter que tmpfs ne consomme la mémoire RAM que quand le système de fichiers se remplit, à l’inverse de ramfs.

Logiciels et utilisations à limiter

Vous l’aurez compris, tous les SSD ne sont pas égaux en endurance. Sur les modèles grand public qui ne sont pas dotés d’un over-provisioning important, les utilisations intensives en écritures sont à limiter. Pour cela, on peut déplacer les répertoires concernés dans des systèmes de fichiers mémoire ou bien sur des disques durs magnétiques.

• Les logs dans /var/log peuvent vite user un SSD si vous avez beaucoup d’activité sur certains daemons. Personnellement je conserve mes logs sur un SSD pro.
• Les clients email comme Thunderbird devraient être configurés pour ne pas stocker les messages sur le SSD, ou au moins limiter le stockage aux quelques derniers jours.
• Cache des navigateurs internet à place en mémoire et non pas en disque dur, comme par exemple Chrome ou Firefox.

Ordonnanceur IO

L’ordonnanceur (ou scheduler) est le composant logiciel du noyau chargé de traiter la file d’attente des opérations IO sur les disques durs ou autres ressources matérielles.

Sur les SSD c’est deadline qui est le plus rapide comme on peut le voir sur les benchmarks réalisés par Phoronix.

Pour vérifier que cet ordonnanceur est bien utilisé :

Pour modifier l’ordonnanceur, commande à ajouter au rc.local pour un lancement automatique à chaque démarrage.

 

Alignement des partitions

L’alignement des partitions sur les blocs matériels du disque dur ou du SSD a longtemps été une étape pénible nécessitant des calculs. Maintenant la majorité des logiciels de partitionnement alignent automatiquement les partitions comme fdisk, cfdisk ou parted.

Voici comment vérifier que votre partition est correctement alignée, comme ici avec les deux périphériques sda (clé USB) et mmcblk0 (carte SD).

 

Quel SSD choisir ?

Cette question en relève pas exclusivement du SSD sous Linux mais de mon coté mon choix est fait. Par le passé j’ai déjà rencontré des problèmes avec des SSD de marque OCZ d’ancienne génération. Dorénavant je ne fais confiance aux SSD Samsung de la gamme PRO pour leur très grande longévité comme cela est détaillé sur ce benchmark complet. Chez Techreport, les SSD Samsung Pro on en effet eu besoin de 2,4 Po (péta-octets) de données dans la figure pour lâcher. C’est plus que je n’en aurai jamais besoin. Le constructeur s’assure en annonçant une endurance officielle autour de 100 To.

 

De plus, ces SSD en particuliers sont capables de nous indiquer de leur état d’usure dans les attributs SMART, sur une échelle de 0 à quelques centaines. Disons qu’en dessous de 50 on est larges.

Dans la gamme SATA, sur Amazon (Avril 2010) le modèle 128 Go est à 89 €, le modèle 256 Go à 119 € et le modèle 512 Go à 229 €. Depuis peu on trouve du 1 To autour de 500 €. C’est plus cher que d’autres modèles grand public, mais pour un SSD garanti 10 ans, et donc utilisable dans plusieurs générations de serveurs, c’est à mon avis justifié. Rares sont les appareils technologiques à être aussi pérennes.

Coté SSD M.2 (compatible PCIe via un adaptateur M.2 vers PCIe) le Samsung 950 PRO (200€ pour 256 Go ou 400€ pour 512Go) a une réputation de performances extrêmes pour les stations de travail. De mon coté j’ai choisi le Samsung SM951 de la gamme serveur et interface NVMe, monté sur une carte Asus M.2 vers PCie. L’ensemble a une bonne durabilité et des performances excellentes.

 

Autres ressources intéressantes

• ssd_solid_state_drive, Ubuntu-fr
• Solid State Drives, Arch.fr
• SSDOptimization, Debian.org