SSD : TRIMming > Libération des blocs par Système de fichiers

[dezix]

Bonjour,

Voici quelque-chose de nouveau pour moi
et possiblement pour vous aussi.

J'écris ces lignes pour quelles soient validées et/ou corrigées/complétées par plus qualifié que moi ... ce n'est pas la Bible :((

Si l'usage d'un SSD est une nouveauté (ou pas)
vous êtes peut-être passé à côté d'un problème qui affecte les SSD
et qui n'existait pas pour les HDD.

Il s'agit d'une dégradation (rapide) des performances pour des raisons de "rétro-compatibilité"
Lire larticle : Dégradation & TRIM, la théorie - SSD, TRIM et IOMeter - HardWare.fr

Pour résumer grossièrement, le matériel actuel est conçu pour les HDD,
du coup les SSD embarque de l'électronique
pour convertir les commandes d'écriture de HDD en SSD
utilisables pour la mémoire Flash.

Dans ce processus d'écriture le SSD n'est pas informé des suppressions de fichiers.
Il ne libère pas les espaces mémoires correspondants.

Tant que le SSD n'a pas utilisé une 1ère fois toutes ces "cases mémoires" (disque neuf),
il conserve d'excellentes performances.

Mais ensuite ça se dégrade,
car il doit faire face à une sorte de fragmentation.

Le système de fichier ext4 est adapté à l'usage des SSD,
c'est donc celui qu'il faudrait utiliser.

Pour remédier (partiellement) à la fragmentation qui vient d'être décrite,
le système de fichiers (ext4) doit informer le SSD des modifications qu'il a subit,
de manière à ce qu'il sache quelles zones sont de nouveau disponibles dans sa mémoire Flash.

Cette opération est le TRIMming (Ajustement)

Le TRIMming (et le bon fonctionnement du SSD en général)
est conditionné par plusieurs choses :

1. Le SSD doit supporter TRIM qui n'est pas supporté par tous les SSD (voir la doc du matériel)
2. Le SSD doit être reconnu comme tel dans le BIOS ou l'UEFI selon la carte-mère
3. Toujours dans le BIOS, AHCI doit être activé
4. Système de fichiers compatible SSD (ext4 ; Brtfs ; ...???)
5. L'OS doit reconnaître un SSD (statique) vérifiable avec la commande : $ cat /sys/block/sdx/queue/rotational qui doit renvoyer " 0 " (zéro) pour un SSD
6. TRIM doit être activé dans /etc/fstab dans les options de montage de chaque partition par l'ajout de l'argument discard

La commande sftrim permet de réaliser un TRIM manuel ou via un script pouvant être exécuté périodiquement (cron)


Ceci est à peu près tout ce que j'ai pu apprendre sur le sujet pour le moment.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

J'utilise depuis un an un SSD (c'est mon premier)
je suppose donc que j'aurais du mettre en place un TRIMming régulier dès son installation.

Comme toute nouveauté, ça me fait un peu angoisser quand au potentiel désastre si ça se passait mal la 1ère fois.

Dois-je faire après sauvegarde TOTALE :

# fstrim -a

Sachant que je n'ai qu'un SSD
avec :

Code : Tout sélectionner

# fdisk -l
Disque /dev/sda : 232,91 GiB, 250059350016 octets, 488397168 secteurs
Modèle de disque : CT250MX500SSD1  
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 3650E02E-8AD0-454E-9AC3-676930641AC1

Périphérique    Début       Fin  Secteurs Taille Type
/dev/sda1       12288    206847    194560    95M Système EFI
/dev/sda2      206848  16588799  16381952   7,8G Partition d'échange Linux
/dev/sda3    16590848  71903231  55312384  26,4G Système de fichiers Linux
/dev/sda4    71903232  92383231  20480000   9,8G Système de fichiers Linux
/dev/sda5    92383232 488396799 396013568 188,9G Système de fichiers Linux

et

Code : Tout sélectionner

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

#Entry for /dev/sda1 :
UUID=C5EB-019F	/boot/efi	vfat	umask=0077	0	1

#Entry for /dev/sda2 :
UUID=454bf535-16d9-4e05-809a-0afd4fd00c1e	none	swap	sw	0	0

#Entry for /dev/sda3 :
UUID=f117ebb0-c5a1-4138-9c57-4d983c0d8ba5	/	ext4	errors=remount-ro	0	1

#Entry for /dev/sda4 :
UUID=50705585-e448-4a76-96a7-ed2d113ac435	/home	ext4	defaults	0	2

#Entry for /dev/sda5 :
UUID=5fca7092-7dbd-4509-8774-fd341600ef76	/home/data	ext4	defaults	0	2

Si j'ajoute l'option discard pour toutes les partitions,
le PC étant rédémarré au moins une fois par 24h,
cela ne risque-t-il pas d'écourter la durée de vie du SSD ?



Le résultat de cette discussion fera l'objet d'une nouvelle page du Wiki,
Merci pour votre aide.

[piratebab]

J'utilise des SSD depuis 2 ou 3 ans, sans constater le phénoméne indiqué.

[dezix]

J'ai peut-être noté un ralentissement mais sans mesure ça reste très subjectif,
on s'habitue vite à la nouvelle vitesse qui du coup paraît moindre.

C'est cette réponse de PascalHambourg qui m'a mis sur cette piste.

C'est peut-être aussi beaucoup plus sensible sur les disques petits ou avec un fort taux de remplissage/réécritures.

[PascalHambourg]

Sans être faux, certains des faits que tu énonces sont obsolètes et concernent surtout les anciennes generations de SSD.

Pour résumer grossièrement, le matériel actuel est conçu pour les HDD,
du coup les SSD embarque de l'électronique
pour convertir les commandes d'écriture de HDD en SSD
utilisables pour la mémoire Flash.

C'est exactement pareil avec les disques durs. Dans les deux cas, l'ordinateur envoie des commandes comme "lire le secteur n° X" ou "écrire le secteur n° Y" sans se préoccuper de la physique du support de stockage, et c'est le contrôleur intégré à ce dernier qui convertit les commandes en opérations sur le support physique.

Dans ce processus d'écriture le SSD n'est pas informé des suppressions de fichiers.
Il ne libère pas les espaces mémoires correspondants.

La suppression d'un fichier est une opération purement logicielle qui n'a rien à voir avec le matériel.

Tant que le SSD n'a pas utilisé une 1ère fois toutes ces "cases mémoires" (disque neuf),
il conserve d'excellentes performances.
Mais ensuite ça se dégrade,
car il doit faire face à une sorte de fragmentation

Ce n'est pas vraiment une fragmentation (même si elle existe et aggrave le phénomène). Avant d'être réécrit, un bloc de mémoire flash doit d'abord être effacé, contrairement à un secteur de disque dur où on peut écrire par dessus les données précédentes. Or l'effacement d'un bloc de mémoire flash est une opération beaucoup plus lente que l'écriture. Le TRIM ou discard permet de signaler au contrôleur du SSD que les données d'un bloc peuvent être effacées bien avant d'avoir besoin d'écrire dedans, faisant gagner du temps.

Même sans TRIM, les SSD utilisent une autre technique pour maintenir des blocs effaces d'avance prêts pour l'écriture : l'overprovisioning, qui consiste à réserver une partie de la mémoire flash qui n'est pas comptée dans la capacité utilisable. Les blocs qui font partie de l'overprovisioning peuvent être effacés par anticipation puisqu'ils ne sont pas visibles de l'extérieur. On peut aussi faire de l'overprovisioning manuel en n'utilisant jamais une partie de la capacité utile.

1. Le SSD doit supporter TRIM qui n'est pas supporté par tous les SSD (voir la doc du matériel)

Il ne doit plus y avoir beaucoup de SSD qui ne supportent pas le TRIM. Par contre le noyau Linux désactive le TRIM avec certains modèles dont l'implémentation par le firmware du SSD est connue pour être défectueuse et provoquer des corruptions de données. Il y a aussi deux formes de TRIM en SATA : la plus ancienne qui peut fortement impacter les performances lors de son exécution, et une nouvelle qui est censée corriger ce problème, mais qui est plus susceptible de provoquer des corruptions de données lorsqu'elle est mal implémentée.

2. Le SSD doit être reconnu comme tel dans le BIOS ou l'UEFI selon la carte-mère

Pas du tout.

3. Toujours dans le BIOS, AHCI doit être activé

TRIM est une commande ATA, je ne vois pas pourquoi on ne pourrait pas l'utiliser avec un contrôleur SATA en mode standard.

A noter que certains SSD utilisent une nouvelle interface NVMe basée sur le bus PCI-Express et optimisée pour les SSD au lieu de l'interface SATA.

6. TRIM doit être activé dans /etc/fstab dans les options de montage de chaque partition par l'ajout de l'argument discard

.
Ce n'est qu'une des façons possibles d'activer le TRIM, et elle n'est plus recommandée car avec les implémentations défaillantes du TRIM par les firmwares des SSD, elle peut provoquer une chute de performance et une usure prématurée du SSD plus ou moins marquées. On recommande plutôt l'utilisation périodique de fstrim (une fois par semaine) à un moment de faible activité (la nuit) via une tâche cron ou un timer systemd (fourni en standard, il n'y a qu'à l'activer).

[vv222]

Version courte

Code : Tout sélectionner

# systemctl enable fstrim.timer

---

Version longue

Comme cette discussion m’a rendu curieux, et que j’ai tendance à privilégier les outils fournis par ma distribution, je me suis penché sur ce timer systemd.

Pour contrôler s’il est actif :

Code : Tout sélectionner

$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● fstrim.service
       Docs: man:fstrim

Ici, on voit qu’il ne l’est pas :

Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: enabled)

Je l’active donc :

Code : Tout sélectionner

# systemctl enable fstrim.timer
Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /lib/systemd/system/fstrim.timer.

Et je vérifie que ça a bien fonctionné :

Code : Tout sélectionner

$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● fstrim.service
       Docs: man:fstrim

Cette fois-ci le timer est bien en place :

Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)

[dezix]

Merci pour ces contributions, il va y avoir de quoi alimenter le Wiki.