Ldfa Posté(e) le 30 décembre 2019 Partager Posté(e) le 30 décembre 2019 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. 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. root@ordinateur:~# hdparm -I /dev/sda |grep TRIM * Data Set Management TRIM supported (limit 8 blocks) root@ordinateur:~# hdparm -I /dev/sda |grep TRIM * Data Set Management TRIM supported (limit 8 blocks) 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. # / was on /dev/sda3 during installation UUID=614af9d4-e0d7-4b38-b6f7-06397514b5ee / ext4 errors=remount-ro,discard 0 1 # / was on /dev/sda3 during installation UUID=614af9d4-e0d7-4b38-b6f7-06397514b5ee / ext4 errors=remount-ro,discard 0 1 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 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. root@ordinateur:~# fstrim -v / /: 260951162880 bytes were trimmed root@ordinateur:~# fstrim -v / /: 260951162880 bytes were trimmed Si jamais le périphérique ne supporte pas TRIM, il le dira tout de suite. root@ordinateur:~# fstrim -v /tmp fstrim: /tmp: FITRIM ioctl failed: Ioctl() inappropré pour un périphérique root@ordinateur:~# fstrim -v /tmp fstrim: /tmp: FITRIM ioctl failed: Ioctl() inappropré pour un périphérique root@ordinateur ~ # fstrim / fstrim: /: the discard operation is not supported root@ordinateur ~ # fstrim / fstrim: /: the discard operation is not supported 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. #!/bin/bash echo "$(/bin/date +%Y%m%d-%H%M%S) $(/sbin/fstrim -v /)" >> /var/log/fstrim.log #!/bin/bash echo "$(/bin/date +%Y%m%d-%H%M%S) $(/sbin/fstrim -v /)" >> /var/log/fstrim.log 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 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. Personnellement je recommande de ne jamais dédier une partition de swap sur un SSD. Vu le prix du SSD au Go c’est selon moi une perte inutile. De plus, 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 : vm.swappiness=0 vm.swappiness=0 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. # / was on /dev/sda3 during installation UUID=614af9d4-e0d7-4b38-b6f7-06397514b5ee / ext4 errors=remount-ro,noatime,nodiratime 0 1 # / was on /dev/sda3 during installation UUID=614af9d4-e0d7-4b38-b6f7-06397514b5ee / ext4 errors=remount-ro,noatime,nodiratime 0 1 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 : tmpfs /tmp tmpfs defaults,size=4g 0 0 tmpfs /tmp tmpfs defaults,size=4g 0 0 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 à éviter Toutes les utilisations intensives en écritures sont à limiter voire proscrire. Si vous en avez réellement besoin, le mieux est de 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. 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é : root@ordinateur:~# cat /sys/block/sda/queue/scheduler noop [deadline] cfq root@ordinateur:~# cat /sys/block/sda/queue/scheduler noop [deadline] cfq Pour modifier l’ordonnanceur, commande à ajouter au rc.local pour un lancement automatique à chaque démarrage. root@ordinateur:~# echo deadline > /sys/block/sda/queue/scheduler root@ordinateur:~# echo deadline > /sys/block/sda/queue/scheduler 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). root@ordinateur ~ # parted /dev/sda GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) align-check optimal 1 1 aligned (parted) quit root@ordinateur ~ # parted /dev/mmcblk0 GNU Parted 3.2 Using /dev/mmcblk0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) align-check optimal 1 1 aligned (parted) quit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 root@ordinateur ~ # parted /dev/sda GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) align-check optimal 1 1 aligned (parted) quit root@ordinateur ~ # parted /dev/mmcblk0 GNU Parted 3.2 Using /dev/mmcblk0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) align-check optimal 1 1 aligned (parted) quit Quel SSD choisir ? Cette question en relève pas exclusivement du SSD sous Linux mais de mon coté ma religion est faite. 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 plus confiance qu’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. SSD Samsung PRO 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. root@ordinateur:~# smartctl -a /dev/sda |grep Wear 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 2 root@ordinateur:~# smartctl -a /dev/sda |grep Wear 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 2 Sur Amazon, dans la gamme SATA, le modèle 128 Go est à 89€, le modèle 256 Go à 119€ et le modèle 512 Go à 229€. 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, qui a une bonne durabilité et des performances tout aussi bonnes. Autres ressources intéressantes Afficher l’article complet Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.