Ubuntu 24.04 : performances SSD/NVMe qui se dégradent avec le temps : prouvez que c’est le TRIM/GC et réparez-le

décembre 26, 2025 • février 3, 2026 • Lecture : 30 min • Views: 7

Cet article vous a aidé ?

Vous redémarrez la machine et tout redevient rapide. Deux semaines plus tard, c’est reparti : les écritures se bloquent, la latence explose, des bases de données commencent à « mystérieusement » expirer et vos tableaux de bord ressemblent à un sismographe. Le disque est « sain », le CPU s’ennuie et l’équipe applicative est convaincue que vous avez changé quelque chose. Ce n’est pas vous. C’est le SSD.

Ce mode de défaillance est courant sur les serveurs Ubuntu 24.04 : les performances SSD/NVMe se dégradent lentement à mesure que la carte d’espace libre du disque devient désordonnée, la garbage collection (GC) travaille davantage, et TRIM/discard n’a soit pas lieu soit n’atteint pas le périphérique physique. La bonne nouvelle : vous pouvez le prouver avec des données solides, et corriger le problème de manière vérifiable.

À quoi ressemble le ralentissement dans des systèmes réels

Tous les rapports de « NVMe lent » ne sont pas dus au TRIM/GC. Mais le motif « se dégrade avec le temps » est révélateur. Voici à quoi cela ressemble typiquement quand discard/TRIM n’est pas efficace :

La latence d’écriture augmente progressivement sous charge soutenue, en particulier pour les écritures aléatoires et les mélanges lecture/écriture.
Pics de latence périodiques (des centaines de millisecondes à plusieurs secondes) même quand l’application n’utilise pas toute la bande passante.
Un redémarrage ou un long repos améliore temporairement les performances. (Certains disques effectuent la GC en arrière-plan plus agressivement quand ils sont inactifs ; un redémarrage peut aussi changer les motifs de charge et donner du temps d’inactivité.)
L’espace libre sur le système de fichiers semble correct, mais le périphérique se comporte comme s’il était plein. C’est le point : la notion de « libre » du SSD n’est pas celle du système de fichiers sauf si TRIM le lui indique.
L’iowait n’est pas nécessairement élevé. Quelques threads bloqués sur le stockage peuvent suffire à faire fondre vos SLO.

La plupart des équipes découvrent cela de la même manière : un système en production qui était « correct » au lancement devient un générateur d’incidents au ralenti. Votre premier réflexe est d’incriminer la base de données, puis le noyau, puis le cloud, puis le stagiaire. Ne le faites pas. Commencez par vérifier si le SSD est informé des blocs qui ne sont plus utilisés.

Faits intéressants et contexte historique (court et utile)

Les premiers SSD grand public pouvaient perdre énormément en performances après avoir été remplis une fois, car ils avaient peu de surprovisionnement et une GC rudimentaire.
TRIM a été introduit pour aligner la vue du système de fichiers sur celle du SSD. Sans lui, le SSD doit supposer que chaque bloc écrit compte encore.
La « garbage collection » n’est pas optionnelle sur la flash : on peut lire et écrire des pages, mais l’effacement se fait par blocs d’effacement plus grands, donc la réécriture nécessite des mouvements de données.
L’amplification d’écriture est l’ennemi invisible : une petite écriture hôte peut provoquer de nombreuses écritures internes quand le SSD doit consolider des pages valides.
NVMe a amélioré latence et parallélisme, mais il n’a pas annulé la physique. La GC existe toujours ; elle se produit juste à des IOPS plus élevés et parfois avec des chutes plus nettes.
Linux supporte TRIM depuis longtemps, mais « supporter » ne signifie pas « activé de bout en bout ». LUKS, LVM, dm-crypt, device-mapper et les couches virtualisées peuvent bloquer les discards si mal configurés.
Monter avec l’option discard a été controversé historiquement car cela peut ajouter des frais et de la fragmentation ; fstrim périodique est devenu le défaut simple et efficace dans de nombreuses distributions.
Certaines baies de stockage et certains blocs cloud ignorent les discards ou les traduisent d’une manière qui ne libère pas réellement l’espace physique. L’OS invité pense avoir aidé ; le backend s’en moque.

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Ceci est la version « on vous appelle en urgence ». L’objectif n’est pas une analyse parfaite ; c’est trouver le goulet d’étranglement en quelques minutes et décider si vous poursuivez TRIM/GC ou autre chose.

Premier : confirmez que c’est la latence du stockage, pas CPU/mémoire

Vérifiez iostat pour la latence du périphérique (await) et l’utilisation.
Vérifiez l’IO par processus avec pidstat ou les métriques applicatives.
Cherchez un motif : latence qui monte sur des jours/semaines, pas un changement brutal après un déploiement.

Second : confirmez que le chemin TRIM existe de bout en bout

Le fstrim.timer est-il activé et réussit-il ?
Le système de fichiers supporte-t-il discard ? La couche bloc accepte-t-elle les discards ?
Êtes-vous sur LUKS/LVM/MD RAID où les discards peuvent être désactivés ou bloqués ?

Troisième : reproduisez et mesurez avec une charge contrôlée

Utilisez fio pour lancer un test d’écriture aléatoire consistant (avec précaution, sur une cible non production ou une partition de secours).
Exécutez fstrim, puis répétez le test et comparez la distribution de latence, pas seulement la moyenne en MB/s.

Si l’exécution post-TRIM améliore sensiblement les p95/p99/p99.9 ou soutient les IOPS plus longtemps avant la chute, vous avez votre coupable : le disque manquait de blocs propres.

Prouvez que c’est TRIM/GC : mesures qui résistent aux débats

Les débats sur TRIM et la garbage collection attirent les gesticulations. N’y participez pas. Produisez des preuves qui répondent à une question : est-ce qu’informer le périphérique des blocs libérés réduit les symptômes d’amplification d’écriture et la latence ?

Deux choses comptent :

La distribution de latence (p95/p99/p99.9), pas seulement le débit moyen. La douleur de la GC apparaît souvent sous forme de pics.
Avant/après un événement de discard (fstrim manuel ou charge contrôlée avec discard), en gardant le même profil de charge.

Gardez aussi à l’esprit ce que TRIM n’est pas :

Ce n’est pas une « défragmentation » magique pour SSD.
Il n’efface pas instantanément les cellules ; il marque les pages comme invalides pour que le SSD puisse effacer les blocs efficacement plus tard.
Il ne répare pas un disque qui meurt, un contrôleur saturé ou un système de file d’attente cassé.

Une citation à garder :

« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Maintenant, passons à l’action : tâches concrètes avec commandes, sorties et décision suivante.

Tâches pratiques : commandes, sorties attendues et décision à prendre

Ordonnées à peu près comme je les exécuterais sur un serveur Ubuntu 24.04 suspecté de « SSD qui se dégrade avec le temps ». Les commandes sont réelles et exécutables. Les sorties sont représentatives ; vos noms de périphériques seront différents.

Tâche 1 : Identifier le(s) périphérique(s) bloc réel(s)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,ROTA,DISC-MAX,DISC-GRAN
NAME        TYPE  SIZE FSTYPE MOUNTPOINTS MODEL               ROTA DISC-MAX DISC-GRAN
nvme0n1     disk  1.8T        /dev/nvme0n1                     0    2G       4K
├─nvme0n1p1 part  512M vfat   /boot/efi
└─nvme0n1p2 part  1.8T crypto
  └─vg0-root lvm   300G ext4  /

Ce que cela signifie : Vous êtes sur NVMe (ROTA=0), et la pile inclut LUKS crypto + LVM. C’est précisément l’endroit où les discards meurent souvent en silence.

Décision : Vous devez vérifier le support des discards à travers dm-crypt et LVM, pas seulement au niveau du système de fichiers.

Tâche 2 : Vérifier le type de système de fichiers et les options de montage (discard vs périodique)

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro

Ce que cela signifie : Pas d’option discard au montage. Ce n’est pas automatiquement une erreur ; Ubuntu s’appuie souvent sur le fstrim périodique.

Décision : N’ajoutez pas discard à la hâte. Vérifiez d’abord si le TRIM périodique est activé et fonctionne.

Tâche 3 : Le timer TRIM hebdomadaire est-il activé ?

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2025-12-22 00:12:01 UTC; 1 weeks 1 days ago
    Trigger: Mon 2025-12-29 00:28:14 UTC; 1 days ago
   Triggers: ● fstrim.service

Ce que cela signifie : Le timer est activé et programmé. C’est nécessaire, pas suffisant.

Décision : Vérifiez le résultat de la dernière exécution. Un timer peut être activé et échouer à chaque fois.

Tâche 4 : Est-ce que fstrim a vraiment réussi lors de la dernière exécution ?

cr0x@server:~$ journalctl -u fstrim.service -n 50 --no-pager
Dec 29 00:28:14 server systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Dec 29 00:28:14 server fstrim[32107]: /: 0 B (0 bytes) trimmed on /dev/mapper/vg0-root
Dec 29 00:28:14 server systemd[1]: fstrim.service: Deactivated successfully.
Dec 29 00:28:14 server systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.

Ce que cela signifie : Trimmed 0 B. Cela peut signifier « rien à trimmer » ou « le discard ne transite pas », ou « le système de fichiers pense qu’il n’y a rien de libre », ou « vous êtes sur un bloc virtuel qui l’ignore ». Sur un système occupé, 0 B semaine après semaine est suspect.

Décision : Validez le support des discards au niveau bloc et via dm-crypt/LVM. Exécutez aussi un fstrim manuel et voyez s’il rapporte quelque chose.

Tâche 5 : Vérifier que le périphérique annonce la capacité de discard

cr0x@server:~$ cat /sys/block/nvme0n1/queue/discard_max_bytes
2147483648

Ce que cela signifie : Le NVMe brut accepte des discards jusqu’à 2 GiB par commande. Bien.

Décision : Si vous ne trimez pas, ce n’est pas parce que le NVMe ne peut pas. C’est parce que votre pile logicielle n’émet pas de discards ou ne les transmet pas.

Tâche 6 : Vérifier si le périphérique mappé supporte le discard (couche dm)

cr0x@server:~$ cat /sys/block/dm-0/queue/discard_max_bytes
0

Ce que cela signifie : Votre périphérique dm (probablement un LV LVM ou un mapping dm-crypt) n’annonce pas le discard. C’est pourquoi fstrim rapporte 0 octet : le discard est bloqué au-dessus du NVMe.

Décision : Inspectez la configuration dm-crypt et LVM. Vous devez probablement activer les discards pour LUKS (allow-discards) et vous assurer que LVM ne les empêche pas.

Tâche 7 : Confirmer le réglage dm-crypt discard

cr0x@server:~$ sudo cryptsetup status nvme0n1p2
/dev/mapper/nvme0n1p2 is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/nvme0n1p2
  sector size:  512
  offset:  32768 sectors
  size:    3906250000 sectors
  mode:    read/write
  flags:

Ce que cela signifie : Aucun flag affiché. Si allow-discards était activé, vous le verriez généralement dans flags.

Décision : Prévoyez un changement contrôlé pour activer les discards dans crypttab (ou rouvrir le mapping avec discards) et validez que dm annonce ensuite le discard.

Tâche 8 : Vérifier la configuration /etc/crypttab

cr0x@server:~$ sudo cat /etc/crypttab
nvme0n1p2 UUID=9f3d7b2a-2c42-4e47-b2c6-7d92a4e5a8a1 none luks,discard

Ce que cela signifie : Cet exemple montre discard déjà défini. Si le vôtre ne le contient pas, les discards sont bloqués par dm-crypt par conception.

Décision : Si absent, ajoutez discard (ou allow-discards selon les outils) et planifiez un reboot ou l’opération de réouverture des mappings pendant une fenêtre de maintenance.

Tâche 9 : Valider que LVM n’est pas le goulot de discard

cr0x@server:~$ sudo lvs -o lv_name,vg_name,lv_attr,segtype,devices
  LV   VG  Attr       Type   Devices
  root vg0 -wi-ao---- linear /dev/mapper/nvme0n1p2(0)

Ce que cela signifie : Un LV linéaire est correct. Les thin pools et snapshots compliquent la sémantique des discards.

Décision : Si vous voyez thin-pool ou un usage intensif de snapshots, vérifiez le support de discard/sparse dans cette configuration et envisagez fstrim périodique dans l’invité plus un passage correct des discards sur l’hôte.

Tâche 10 : Exécuter un fstrim manuel et l’interpréter

cr0x@server:~$ sudo fstrim -av
/boot/efi: 256.4 MiB (268783616 bytes) trimmed on /dev/nvme0n1p1
/: 112.7 GiB (121011388416 bytes) trimmed on /dev/mapper/vg0-root

Ce que cela signifie : Voilà à quoi ressemble un trim qui fonctionne : des octets non nuls sont libérés, surtout sur le système root. Si votre journal plus tôt montrait 0 B et que vous voyez maintenant de gros trims, vous venez de trouver un planning cassé ou un chemin précédemment bloqué que vous avez réparé.

Décision : Si le trim fonctionne maintenant, passez à la preuve d’amélioration des performances (fio + iostat). Si fstrim affiche encore 0 B alors que vous savez supprimer des données, continuez à creuser : le chemin discard est toujours cassé, ou votre charge ne libère pas d’extents détectables par trim.

Tâche 11 : Observer la latence et l’utilisation pendant une période lente

cr0x@server:~$ iostat -x 1 10
Linux 6.8.0-41-generic (server)  12/30/2025  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.45    2.10    0.00   93.33

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1          5.00    220.0     0.00   0.00    2.40    44.00   310.00  18432.0   120.00  27.91   38.50    59.46   12.40  98.00

Ce que cela signifie : %util proche de 98% avec w_await ≈ 38 ms indique que le périphérique est saturé et que les écritures attendent. Si cela augmente avec le temps sous la même charge, la pression GC est un suspect sérieux.

Décision : Capturez cette base « mauvaise », puis comparez immédiatement après un fstrim réussi et une courte fenêtre d’inactivité.

Tâche 12 : Vérifier NVMe SMART / santé pour exclure un problème matériel évident

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 43 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 3%
data_units_read                     : 123,456,789
data_units_written                  : 98,765,432
host_read_commands                  : 3,210,987,654
host_write_commands                 : 2,109,876,543
controller_busy_time                : 9,812
power_cycles                        : 27
power_on_hours                      : 2,144
unsafe_shutdowns                    : 1
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : Pas d’avertissement critique, faible usure (percentage_used). Cela renforce l’idée que le disque ne meurt pas ; il souffre de maintenance interne sous charge.

Décision : Si vous voyez des media errors, des avertissements critiques ou un percentage_used élevé, traitez d’abord comme un problème matériel potentiel. TRIM ne sauvera pas un SSD qui meurt.

Tâche 13 : Mesurer les performances avec un job fio contrôlé (avant TRIM)

Faites cela uniquement sur une cible sûre (un LV de test, une partition de secours ou un fichier dédié sur un FS non critique). Si vous lancez fio sur des données de production sans réfléchir, vous n’êtes pas un SRE ; vous êtes une anecdote de prudence.

cr0x@server:~$ sudo fio --name=randwrite --filename=/var/tmp/fio.test --size=8G --direct=1 --ioengine=libaio --bs=4k --rw=randwrite --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
randwrite: (groupid=0, jobs=1): err= 0: pid=4123: Tue Dec 30 11:12:01 2025
  write: IOPS=18.2k, BW=71.2MiB/s (74.7MB/s)(4272MiB/60001msec); 0 zone resets
    slat (nsec): min=1500, max=180512, avg=6210.3, stdev=3341.2
    clat (usec): min=80, max=215000, avg=1732.4, stdev=8200.7
     lat (usec): min=90, max=215020, avg=1738.8, stdev=8201.1
    clat percentiles (usec):
     |  1.00th=[  120],  5.00th=[  150], 10.00th=[  170], 50.00th=[  320],
     | 90.00th=[ 1400], 95.00th=[ 3800], 99.00th=[20000], 99.90th=[120000]
  cpu          : usr=3.10%, sys=12.40%, ctx=1123456, majf=0, minf=12
  IO depths    : 1=0.1%, 2=0.2%, 4=0.5%, 8=1.2%, 16=7.0%, 32=91.0%, >=64=0.0%

Ce que cela signifie : La latence moyenne semble « acceptable », mais p99 et p99.9 sont déplorables. Ces longues queues sont ce qui pénalise les bases de données et les SLO d’API. Ce motif correspond à des stalls de GC.

Décision : Lancez fstrim (si possible), laissez éventuellement le disque idle quelques minutes, puis relancez le même job fio et comparez les percentiles.

Tâche 14 : Trimmer, puis relancer fio (après TRIM)

cr0x@server:~$ sudo fstrim -v /
/: 112.7 GiB (121011388416 bytes) trimmed on /dev/mapper/vg0-root

cr0x@server:~$ sudo fio --name=randwrite --filename=/var/tmp/fio.test --size=8G --direct=1 --ioengine=libaio --bs=4k --rw=randwrite --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
randwrite: (groupid=0, jobs=1): err= 0: pid=4188: Tue Dec 30 11:16:01 2025
  write: IOPS=28.9k, BW=113MiB/s (118MB/s)(6780MiB/60001msec); 0 zone resets
    slat (nsec): min=1500, max=110220, avg=5901.1, stdev=2987.4
    clat (usec): min=70, max=42000, avg=980.2, stdev=1400.3
     lat (usec): min=78, max=42012, avg=986.1, stdev=1400.5
    clat percentiles (usec):
     |  1.00th=[  110],  5.00th=[  140], 10.00th=[  160], 50.00th=[  280],
     | 90.00th=[  980], 95.00th=[ 1700], 99.00th=[ 5200], 99.90th=[16000]

Ce que cela signifie : La latence tail s’est nettement améliorée. Le disque passe moins de temps à déplacer des pages valides pendant les écritures parce qu’il dispose de plus de blocs pré-effacés pour travailler.

Décision : Vous avez maintenant « prouvé » l’hypothèse : l’état TRIM/GC affecte les performances. Passez aux corrections permanentes : assurez la fiabilité des discards, et adoptez des pratiques opérationnelles qui évitent aux disques de tourner à 95% d’occupation.

Tâche 15 : Confirmer que le discard continu n’est pas déjà activé (et décider si vous le voulez)

cr0x@server:~$ mount | grep ' on / '
/dev/mapper/vg0-root on / type ext4 (rw,relatime,errors=remount-ro)

Ce que cela signifie : Pas d’option discard au montage. C’est acceptable si le trim périodique fonctionne.

Décision : Préférez fstrim périodique pour les serveurs généraux. N’utilisez le discard continu que pour des workloads spécifiques où vous avez mesuré le bénéfice et que le surcoût est acceptable.

Tâche 16 : Vérifier l’espace libre et le risque de saturation

cr0x@server:~$ df -hT /
Filesystem              Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root    ext4  295G  271G   10G  97% /

Ce que cela signifie : 97% utilisé. C’est une zone critique de performance pour beaucoup de SSD, même avec TRIM, car le disque dispose de moins d’espace pour le wear leveling et la GC.

Décision : L’espace libre est une fonctionnalité de performance. Visez 70–85% d’utilisation pour les systèmes à forte écriture, ou ajoutez de la capacité. Si la finance grogne, appelez ça « assurance latence ».

Blague #1 : Faire tourner des SSD à 97% d’occupation, c’est comme prévoir votre exercice d’incendie pendant un vrai feu—techniquement un exercice, pratiquement une mauvaise journée.

Corrections qui fonctionnent (et pourquoi)

Il y a trois catégories de corrections, et il vous en faut généralement au moins deux :

Faire en sorte que TRIM se produise réellement (périodiquement ou en continu), de bout en bout à travers votre pile.
Donner de l’air au SSD (éviter d’être proche de 100% d’occupation ; réduire le churn sur les volumes chauds).
Arrêter de rendre la GC plus difficile qu’elle ne doit l’être (choix workload et système de fichiers, sanity des files d’attente, éviter des couches pathologiques).

Correction 1 : Activer et vérifier fstrim périodique (le défaut souhaitable)

Sur Ubuntu 24.04, le TRIM périodique est généralement assuré via fstrim.timer. Vous voulez qu’il soit activé, et qu’il rapporte des trims non nuls au fil du temps sur les systèmes qui suppriment/écrasent des données.

cr0x@server:~$ sudo systemctl enable --now fstrim.timer
Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /usr/lib/systemd/system/fstrim.timer.

Vérifiez qu’il s’exécute :

cr0x@server:~$ systemctl list-timers --all | grep fstrim
Mon 2026-01-05 00:28:14 UTC  5 days left Mon 2025-12-29 00:28:14 UTC  1 day ago fstrim.timer  fstrim.service

Puis vérifiez la sortie :

cr0x@server:~$ sudo journalctl -u fstrim.service --since "14 days ago" --no-pager | tail -n 20
Dec 29 00:28:14 server fstrim[32107]: /: 112.7 GiB (121011388416 bytes) trimmed on /dev/mapper/vg0-root

Si ça trimme toujours 0 B, ne vous félicitez pas. Vous trimez de l’air.

Correction 2 : Assurer le passage des discards via dm-crypt (LUKS) si vous utilisez le chiffrement

dm-crypt bloque les discards par défaut pour de bonnes raisons : les discards peuvent fuir des informations sur quels blocs sont utilisés. Beaucoup d’environnements de production acceptent ce compromis parce que la performance et la latence prévisible comptent plus que cacher les motifs d’allocation.

Que faire : Ajoutez discard dans /etc/crypttab (ou assurez-vous qu’il est présent), puis redémarrez ou rouvrez les mappings pendant une fenêtre de maintenance. Ensuite, confirmez que /sys/block/dm-*/queue/discard_max_bytes est non nul.

La vérification est non négociable : si dm annonce encore 0, le SSD ne vous entend toujours pas.

Correction 3 : Préférer fstrim périodique à l’option de montage discard (la plupart du temps)

L’option de montage discard envoie des discards continus au fur et à mesure que des blocs sont libérés. Cela peut être utile pour certains workloads en churn constant, mais cela peut aussi ajouter un surcoût, surtout sur des systèmes de fichiers avec beaucoup de petites suppressions, et interagir mal avec certaines implémentations de périphériques.

Mon choix par défaut et argumenté :

Utilisez fstrim périodique pour ext4/xfs sur les serveurs.
Considérez le discard continu seulement si :
- vous avez mesuré que le trim périodique n’est pas suffisant, et
- votre workload a un churn constant et des SLO de latence stricts, et
- vous avez validé le surcoût sous charge.

Correction 4 : Arrêtez de faire tourner les SSD « presque pleins »

Cela ressemble à un problème budgétaire, mais c’est un problème d’ingénierie déguisé en budget.

Sur des volumes fortement écrits, visez 15–30% d’espace libre comme tampon opérationnel.
Évitez les gros volumes racine monolithiques qui accumulent tout. Séparez les chemins d’écriture chauds sur des volumes dédiés où vous pouvez gérer l’espace et le comportement de trim.
Si vous utilisez la thin provisioning, surveillez l’utilisation du pool comme si c’était une rotation d’astreinte—parce que ça l’est.

Correction 5 : Laissez le disque s’inactiver de temps en temps (oui, vraiment)

Beaucoup de SSD effectuent une GC en arrière-plan plus efficace quand ils ont du temps d’inactivité. Ce n’est pas un substitut à TRIM, mais ça peut réduire la sévérité des pics de latence.

Si votre serveur est saturé 24/7 d’écritures constantes, vous forcez la GC à se produire en premier plan. Vous pouvez atténuer cela en lissant les pics d’écriture (batching applicatif, mise en file), ou en scale-out pour que chaque disque ait du temps de respiration.

Correction 6 : Aligner systèmes de fichiers et piles sur la sémantique discard

Certaines configurations compliquent les discards :

Thin pools LVM : les discards peuvent nécessiter un support explicite. La thin provisioning plus churn élevé est un classique « semble correct jusqu’à ce que ça casse ».
Snapshots partout : les snapshots conservent des blocs anciens, donc vos suppressions ne libèrent pas réellement l’espace vu par la couche inférieure. Trim peut ne pas refléter l’espace réellement récupérable.
Disques virtualisés : les discards peuvent être ignorés ou différés. Votre invité peut tout faire correctement et ne pas influer sur le média physique.

Blague #2 : Les piles de stockage sont comme les lasagnes—chaque couche rend le plat plus savoureux jusqu’à ce que vous réalisiez que vous déboguez du fromage.

Trois mini-récits d’entreprise (anonymisés, plausibles et techniquement exacts)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré une flotte de serveurs Ubuntu de SSD SATA vers de brillants NVMe. La migration s’est bien passée, et les premières semaines furent glorieuses. La latence a chuté, les tableaux de bord étaient calmes, et tout le monde s’est congratulé dans le canal de chat dédié aux auto-congratulations.

Six semaines plus tard, les alertes ont commencé : latence d’écriture p99 de la base de données qui partait en flèche pendant les heures de pointe. L’astreinte a fait la danse habituelle—vérifié CPU, mémoire, réseau, insulté l’ORM, puis regardé iostat comme si ça allait avouer. Les NVMe montraient une forte utilisation et de longs awaits d’écriture, mais rien de « cassé ». SMART était propre. Ils ont donc monté les instances. Ça a aidé un temps, puis c’est revenu.

L’hypothèse erronée était subtile : « NVMe est rapide, donc la maintenance du stockage n’aura pas d’importance. ». Ils n’avaient pas réalisé que la nouvelle infra utilisait le chiffrement LUKS avec les réglages par défaut et que les discards étaient bloqués. fstrim tournait chaque semaine et rapportait un succès, mais trimmed 0 bytes à chaque fois. Personne n’a remarqué parce que « Finished successfully » est une ligne que les humains apprennent à mal lire.

Une fois qu’ils ont activé les discards via dm-crypt et vérifié /sys/block/dm-*/queue/discard_max_bytes non nul, le trim hebdomadaire a commencé à libérer de l’espace réel. La période de pointe suivante avait toujours de la charge, mais la chute de latence avait disparu. L’action post-mortem n’était pas « acheter des disques plus rapides », mais « tester le passage des discards bout en bout dans l’image golden ».

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation avait un pipeline d’ingestion de logs qui écrivait en continu : petits fichiers, suppressions constantes, beaucoup de churn metadata. Ils ont lu quelque part que monter avec discard gardait les SSD heureux. Ils ont donc poussé un changement pour monter le volume de logs avec discard continu. Ils n’ont pas fait de benchmark parce que, et je cite l’ambiance, « c’est juste discard ».

En quelques jours, le débit d’ingestion a chuté et le temps CPU système a grimpé. Le disque ne semblait pas saturé en bande passante, mais la latence est devenue plus bruyante. Ils avaient en fait déplacé le travail de discard dans le hot path : discards minuscules constants, commandes supplémentaires constantes, et plus de surcoût par suppression. Le SSD était informé poliment de l’espace libre des milliers de fois par seconde, comme un collègue qui narre chaque frappe.

Ils ont rollbacké vers fstrim périodique et programmé le trim hors pic. Le débit est revenu, le CPU a retrouvé son calme, et le SSD recevait toujours les informations nécessaires—mais par lots où le surcoût était amorti.

Leçon : le discard continu n’est pas maléfique, mais c’est un réglage dépendant du workload. L’activer partout par politique, ce n’est pas du tuning ; c’est de l’espoir.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe paiements avait une habitude peu glamour : chaque changement lié au stockage nécessitait une checklist « prouvez-le ». Pas un document pour les auditeurs—un rituel d’ingénierie réel. Ils mesuraient la latence écriture p95/p99 avec un profil fio synthétique correspondant à leur base de données. Ils l’enregistraient avant les changements, après les changements, et de nouveau deux semaines plus tard.

Quand ils sont passés à Ubuntu 24.04, les chiffres semblaient corrects le premier jour. Deux semaines après, le benchmark programmé montrait la latence tail qui montait. Pas catastrophique encore, mais en mauvaise tendance. Parce que cela a été détecté par une mesure de routine, ils ont eu le temps d’enquêter sans incident actif.

Ils ont découvert qu’une nouvelle disposition LVM en thin provisioning était utilisée par commodité. Les discards du système de fichiers ne libéraient pas d’espace dans le thin pool comme attendu, et le pool chauffait. Ils ont ajusté la disposition (simplifié pour le volume de base de données), assuré le trim périodique, et appliqué un budget d’espace libre. Pas d’héroïsme, pas de pages à minuit.

Rien dans cette histoire n’est excitant. C’est le point. La pratique ennuyeuse—mesurer maintenant, mesurer plus tard—a sauvé la mise.

Erreurs courantes : symptôme → cause racine → correction

Cette section est la cicatrice accumulée. Faites correspondre votre symptôme à une cause probable, puis vérifiez avec les tâches ci-dessus.

1) fstrim s’exécute « avec succès » mais trimme toujours 0 octet

Symptôme : le journal montre /: 0 B trimmed semaine après semaine.
Cause racine : Discards bloqués par dm-crypt, LVM, réglages thin pool, ou le périphérique backend ignore les discards.
Correction : Vérifiez /sys/block/*/queue/discard_max_bytes pour le périphérique source réel. Activez les discards dans crypttab, confirmez que dm annonce discard, relancez un fstrim -av manuel.

2) Les performances s’améliorent après un reboot, puis déclinent

Symptôme : folklore « reboot règle le problème », répété toutes les quelques semaines.
Cause racine : Le disque a eu du temps d’inactivité ou les conditions de queue ont changé ; le problème sous-jacent est le manque de TRIM ou un état chronique proche du plein entraînant la GC en charge.
Correction : Prouvez avec fio avant/après trim manuel ; activez le trim périodique ; maintenez de l’espace libre.

3) NVMe semble sain, mais p99 d’écriture est terrible

Symptôme : SMART OK, pas d’erreurs média, mais pics de latence longue queue.
Cause racine : GC en premier plan faute de blocs propres ; amplification d’écriture ; périphérique à forte utilisation avec workload mixte.
Correction : Assurez un TRIM effectif ; réduisez le niveau de remplissage ; envisagez de séparer workloads (logs vs DB) ; vérifiez file d’attente et scheduler.

4) Discard continu activé et les performances se sont dégradées

Symptôme : temps CPU system augmente, débit baisse, latence plus bruyante sous workload à suppressions lourdes.
Cause racine : surcharge due aux discards dans le hot path ; trop de petits discards.
Correction : Retirez l’option de montage discard ; utilisez fstrim.timer périodique ; programmez les trims hors-peak.

5) TRIM fonctionne sur bare metal, pas dans les VMs

Symptôme : l’invité exécute fstrim et rapporte des trims, mais les performances de l’hôte se dégradent ; ou l’invité trimme 0 octet.
Cause racine : L’hyperviseur/le stockage de backing ne propage pas les discards ; le type de disque virtuel ne les supporte pas ; comportement du fournisseur cloud.
Correction : Vérifiez le support des discards à la couche de virtualisation. Si les discards ne se propagent pas, utilisez des mécanismes de reclaim côté hôte ou acceptez d’avoir de la capacité tampon et de re-provisionner périodiquement.

6) La thin provisioning atteint sa limite

Symptôme : le thin pool ou le périphérique backing se remplit, les performances chutent, les trims semblent ne pas libérer d’espace.
Cause racine : Discards non passés dans le thin pool, snapshots qui pinent des blocs, ou pool sur-engagé et sous-surveillé.
Correction : Validez les réglages de discard du thin ; réduisez la rétention des snapshots ; surveillez data% du pool comme un SLO de première classe ; gardez de l’espace libre.

Checklists / plan pas à pas

Voici le plan opérationnel que vous pouvez confier à une rotation d’astreinte sans lui donner aussi le numéro de votre thérapeute.

Checklist A : Prouver que le problème est TRIM/GC (30–90 minutes)

Capturez la latence périphérique de base pendant la période « mauvaise » (iostat -x et latence écriture applicative p99).
Confirmez la capacité de discard sur le périphérique brut (/sys/block/nvme*/queue/discard_max_bytes).
Confirmez la capacité de discard sur le périphérique source réel du montage (souvent dm-*).
Exécutez sudo fstrim -av et enregistrez les octets trimés par montage.
Exécutez un test fio contrôlé et enregistrez les percentiles p95/p99.
Répétez fio après fstrim (et une courte fenêtre d’inactivité) avec les mêmes paramètres.
Si la latence tail s’améliore sensiblement : traitez le chemin TRIM et le budget d’espace libre comme cibles de correction.

Checklist B : Rendre TRIM fiable (fenêtre de maintenance)

Activez fstrim.timer et vérifiez qu’il est programmé.
Assurez que /etc/crypttab inclut les options discard si vous utilisez LUKS et que votre modèle de menace le permet.
Redémarrez ou rouvrez en toute sécurité les mappings dm-crypt si nécessaire.
Confirmez que /sys/block/dm-*/queue/discard_max_bytes est non nul.
Exécutez un fstrim -av manuel et confirmez des trims non nuls.
Surveillez les logs hebdomadaires de fstrim et alertez si ça trimme 0 B de manière répétée sur des volumes à churn élevé.

Checklist C : Garder le problème résolu (hygiène continue)

Fixez des cibles de capacité : gardez 15–30% d’espace libre sur les volumes à écriture chaude.
Séparez les workloads à forte écriture sur plusieurs volumes/périphériques quand c’est possible.
Conservez un profil fio standard pour votre environnement et relancez-le mensuellement (ou après mises à jour kernel/stockage).
Surveillez NVMe SMART : température, avertissements critiques, erreurs média, percentage_used.
Surveillez les percentiles de latence, pas seulement le débit et l’await moyen.

FAQ

1) Pourquoi les performances SSD/NVMe se dégradent-elles avec le temps ?

Parce que la flash nécessite un effacement avant écriture au niveau bloc. Quand le SSD ne trouve pas de blocs propres, il doit déplacer des données valides (GC) avant d’écrire. Sans TRIM, il suppose que plus de données sont valides, alourdissant la GC et augmentant l’amplification d’écriture et les pics de latence.

2) NVMe n’est-il pas censé être « toujours rapide » ?

NVMe est un protocole et une interface optimisés pour le parallélisme et la faible surcharge. Il ne change pas le fonctionnement interne de la NAND. Une interface rapide peut juste livrer une chute de performance plus rapide.

3) Dois‑je monter ext4 avec `discard` sur Ubuntu 24.04 ?

Généralement non. Préférez fstrim.timer périodique. Utilisez le discard continu seulement après benchmark, et seulement sur les volumes dont le pattern de suppression et les exigences de latence le justifient.

4) À quelle fréquence dois‑je exécuter fstrim ?

Hebdomadaire est un bon défaut. Pour des workloads à fort churn, vous pouvez l’exécuter quotidiennement hors-peak. Mesurez : si les performances se dégradent en quelques jours, trimmez plus souvent ou corrigez le niveau de remplissage et le workload.

5) TRIM fonctionne-t-il à travers le chiffrement LUKS ?

Oui, potentiellement, mais seulement si activé. dm-crypt peut bloquer les discards sauf si configuré (souvent via discard dans /etc/crypttab). L’activer peut révéler des motifs d’allocation, décidez selon votre modèle de menace.

6) J’ai exécuté fstrim et il a trimé beaucoup. Est-ce mauvais pour la durée de vie du SSD ?

TRIM n’écrit pas de données ; il informe le SSD que des blocs ne sont plus nécessaires. Il peut en réalité réduire l’amplification d’écriture en aidant le SSD à nettoyer plus efficacement. Le risque plus grand pour la durée de vie est l’amplification d’écriture soutenue due au fonctionnement proche du plein sans TRIM effectif.

7) Pourquoi fstrim affiche-t-il 0 octet sur un serveur occupé où nous supprimons des données quotidiennement ?

Causes communes : discards bloqués par dm-crypt/LVM ; thin provisioning ou snapshots qui gardent des blocs « en usage » ; le backend ignore les discards (certains disques virtuels) ; ou votre workload réécrit en place sans libérer d’extents visibles par trim.

8) Puis‑je « réinitialiser » le SSD pour restaurer les performances ?

Certaines unités supportent secure erase ou format qui ramènent le périphérique à l’état neuf, mais c’est destructeur. Opérationnellement, l’approche non destructive est : assurer que TRIM fonctionne, maintenir de l’espace libre, et éviter les empilements pathologiques qui bloquent les discards.

9) Mon disque affiche seulement 3% d’usure (SMART percentage_used), pourquoi est-il lent ?

Le percentage_used SMART indique l’usure, pas le niveau de remplissage. Vous pouvez avoir un disque presque neuf avec de mauvaises performances s’il est maintenu à un fort remplissage logique, sous écritures constantes, sans TRIM effectif et avec beaucoup de GC interne.

10) Dois‑je changer l’ordonnanceur I/O pour NVMe sur Ubuntu 24.04 ?

Souvent non ; les noyaux modernes utilisent des choix raisonnables par défaut (souvent none pour NVMe). Les ajustements de scheduler ne compenseront pas un disque forcé en GC de premier plan. Corrigez discard et espace libre d’abord, puis tunez si nécessaire.

Conclusion : prochaines étapes pratiques

Si votre SSD/NVMe sous Ubuntu 24.04 devient plus lent avec le temps, traitez-le comme un problème d’ingénierie, pas du folklore. Prouvez l’hypothèse par des mesures avant/après : même job fio, même périphérique, avec et sans un trim réussi. Si la latence tail s’améliore après le trim, cessez le débat et commencez à réparer le chemin discard de bout en bout.

Prochaines étapes à faire dans cet ordre :

Vérifier la chaîne discard : support discard du NVMe brut, puis du périphérique dm, puis sortie de fstrim.
Rendre fstrim fiable : activer le timer, confirmer des trims non nuls au fil du temps, alerter si ça ne fait rien en silence.
Corriger le problème structurel : ne plus faire tourner les volumes à écriture chaude à 95–99% d’occupation ; c’est une taxe de latence auto-infligée.
Conserver des justificatifs : stocker un profil fio de référence et le relancer après mises à jour, changements d’image et modifications de la pile de stockage.

Le disque continuera à effectuer de la garbage collection. Votre boulot est de la maintenir en arrière-plan, là où elle doit rester.