Debian 13 : TRIM ne s’exécute pas — activez le timer fstrim et vérifiez son fonctionnement

Ce qu’est TRIM (et ce que ce n’est pas)

TRIM, c’est le système d’exploitation qui indique au stockage à base de mémoire flash quelles blocs ne contiennent plus de données utiles. Ça paraît banal jusqu’à ce qu’on se rappelle comment fonctionnent les SSD : la mémoire flash ne peut pas réécrire sur place ; elle écrit de nouvelles pages ailleurs et efface ensuite d’anciens blocs par morceaux plus gros. Si le disque ne sait pas qu’un bloc est inutile, il peut le garder comme « peut-être encore utilisé », ce qui augmente l’amplification d’écriture, réduit les performances d’écriture soutenues et accélère l’usure.

Sur Linux, vous rencontrerez TRIM via deux mécanismes :

• TRIM périodique : fstrim parcourt les systèmes de fichiers montés et émet des opérations de discard pour l’espace libre. Debian planifie typiquement cela toutes les semaines via un timer systemd.
• Discard continu : l’option de montage discard (ou des variantes spécifiques au système de fichiers) émet des discards au fur et à mesure que des blocs sont libérés.

Utilisez TRIM périodique sauf raison impérieuse de ne pas le faire. Le discard continu peut fonctionner correctement, mais il peut aussi ajouter de la latence dans des charges d’écriture lourdes et complique souvent le débogage des performances. TRIM périodique, c’est ennuyeux. Ennuyeux, c’est bien.

TRIM n’est pas non plus un bouton magique « rendez mon SSD rapide ». Si votre goulot d’étranglement concerne des lectures aléatoires à faible profondeur de file d’attente, TRIM ne vous sauvera pas. Si votre problème est que l’hôte VM ment sur le support des discards, TRIM ne sauvera pas non plus votre carrière.

Une citation à garder dans votre carnet mental : Werner Vogels (CTO d’Amazon) a dit, « Everything fails, all the time. » (idée paraphrasée). Le stockage est inclus. Supposez que cela va échouer — puis vérifiez.

Faits et contexte intéressants (pour ceux qui aiment savoir pourquoi)

• Fait 1 : La commande TRIM SATA a été introduite dans les standards ATA à l’époque où les SSD sont devenus grand public ; avant cela, les disques devaient deviner quelles données étaient obsolètes.
• Fait 2 : Sur NVMe, l’équivalent s’appelle Dataset Management / Deallocate, mais Linux le traite toujours sous le parapluie « discard ».
• Fait 3 : Les premiers SSD se trompaient parfois sur TRIM. Certaines versions de firmware géraient mal les discards au point que des administrateurs les ont désactivés à l’échelle de flottes pendant des années par pure auto-défense.
• Fait 4 : Les systèmes de fichiers ne « ont pas besoin » de TRIM pour fonctionner. Ils en ont besoin pour empêcher que la collecte de déchets du SSD ne devienne une taxe silencieuse sur les performances.
• Fait 5 : La plupart des distributions Linux modernes sont passées du discard toujours actif à fstrim programmé parce que c’est plus facile à raisonner et souvent plus rapide globalement.
• Fait 6 : Le stockage thin-provisionné (LVM thin, disques virtuels, LUN SAN) peut récupérer de la capacité en amont avec discard — si chaque couche coopère. Une couche dit « non », et vous payez encore pour des blocs supprimés il y a des mois.
• Fait 7 : dm-crypt a historiquement refusé par défaut de transmettre les discards parce que ceux-ci peuvent divulguer quelles zones sont allouées. Vous pouvez l’activer si vous le souhaitez.
• Fait 8 : De nombreux contrôleurs RAID et certains stacks device-mapper laissaient tomber les requêtes de discard. Les noyaux modernes sont meilleurs, mais « meilleur » n’est pas « garanti ».

Blague #1 : TRIM, c’est comme nettoyer son bureau — personne ne remarque quand vous le faites, mais tout le monde remarque quand vous ne le faites pas.

Playbook de diagnostic rapide (vérifiez d’abord ceci)

Si TRIM « ne s’exécute pas », vous déboguez en réalité l’un des trois cas suivants : planification, permissions/unités, ou support du discard à travers la pile de stockage. Ne noyez pas le poisson. Vérifiez dans cet ordre :

1) Le timer est-il activé et se déclenche-t-il ?

• Vérifiez que fstrim.timer est activé et a une prochaine exécution prévue.
• Vérifiez quand il a été exécuté pour la dernière fois et si cela a réussi.

2) fstrim -av fonctionne-t-il manuellement ?

• Si le trim manuel échoue : ce n’est pas la planification. C’est le support, les options de montage, ou la pile de périphériques.
• Si le trim manuel fonctionne mais que le timer ne le fait pas : c’est l’état de l’unité systemd, un masquage, ou un problème d’horloge/timer.

3) Le périphérique bloc annonce-t-il le support du discard ?

• Utilisez lsblk -D (granularité de discard / max bytes) et des contrôles de sanity avec blkdiscard.
• Pour LUKS/LVM/RAID/VM, validez que chaque couche transmet les discards.

4) Traitez-vous la bonne cible pour le trim ?

• fstrim ne trim que les systèmes de fichiers montés. Si votre montage important n’est pas monté au moment du timer (rare, mais ça arrive), il ne sera pas trim.
• Certains systèmes de fichiers ou options de montage peuvent désactiver complètement le discard.

Tâches pratiques : commandes, sortie attendue et décision

Ceci est le cœur. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision suivante. Exécutez ces commandes en root ou avec sudo selon l’indication.

Task 1: Confirm Debian sees your drives as discard-capable

cr0x@server:~$ lsblk -D -o NAME,MODEL,ROTA,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME        MODEL               ROTA DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1     Samsung SSD 980      0      4K       2T         0
sda         ST1000DM010-2EP1     1      0B       0B         0

Signification : DISC-GRAN et DISC-MAX non nuls indiquent que le périphérique affirme supporter le discard. Les disques rotatifs (ROTA=1) montrent typiquement 0B parce que TRIM concerne les médias de type SSD.

Décision : Si votre SSD/NVMe affiche 0B/0B, cessez d’accuser systemd. Vous avez probablement une couche qui bloque le discard (dm-crypt, RAID, type de disque virtuel) ou un périphérique qui ne le supporte réellement pas.

Task 2: Check the fstrim timer status

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-29 09:10:12 UTC; 3h ago
    Trigger: Sun 2026-01-04 00:24:31 UTC; 4 days left
   Triggers: ● fstrim.service

Signification : Enabled + active (waiting) avec un prochain déclenchement programmé est ce que vous voulez. Si ça indique disabled, inactive, masked ou pas de trigger, il ne s’exécutera pas.

Décision : Si désactivé, activez-le. Si actif mais ne se déclenche jamais, inspectez les timers et les logs (tâches suivantes).

Task 3: List timers and verify fstrim is scheduled

cr0x@server:~$ systemctl list-timers --all | grep -E 'fstrim|NEXT|LAST'
Sun 2026-01-04 00:24:31 UTC  4 days left Sun 2025-12-28 00:22:09 UTC  1 day ago  fstrim.timer  fstrim.service

Signification : Vous obtenez un NEXT et un LAST. Si LAST est « n/a », il ne s’est jamais exécuté. Si NEXT est « n/a », il ne s’exécutera pas.

Décision : S’il ne s’est jamais exécuté, lancez-le manuellement et lisez les logs. S’il s’est exécuté mais a toujours trim 0 bytes, vous pourriez avoir une couche en amont qui ignore les discards — ou il n’y a simplement pas beaucoup d’espace libre à trimer.

Task 4: See whether the service was invoked and what it did

cr0x@server:~$ systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead) since Sun 2025-12-28 00:22:12 UTC; 1 day ago
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)
    Process: 2021 ExecStart=/sbin/fstrim --fstab --verbose --quiet (code=exited, status=0/SUCCESS)
   Main PID: 2021 (code=exited, status=0/SUCCESS)

Signification : Le code 0/SUCCESS signifie qu’il s’est exécuté. « inactive (dead) » est normal après une unité oneshot qui termine.

Décision : Si vous voyez des codes d’échec, consultez le journal. Si c’est réussi, vérifiez les octets trimés et le chemin du discard.

Task 5: Read the journal for fstrim details

cr0x@server:~$ journalctl -u fstrim.service -n 50 --no-pager
Dec 28 00:22:09 server systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Dec 28 00:22:09 server fstrim[2021]: /: 18.7 GiB (20068429824 bytes) trimmed on /dev/nvme0n1p2
Dec 28 00:22:12 server systemd[1]: fstrim.service: Deactivated successfully.
Dec 28 00:22:12 server systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.

Signification : C’est votre preuve. Ça montre quels points de montage ont été trimés et combien.

Décision : S’il n’en liste que certains, vérifiez /etc/fstab et l’état des montages. S’il trim 0 bytes en boucle, validez le support du discard ; il pourrait être bloqué ou il n’y a rien de nouveau à supprimer.

Task 6: Run fstrim manually across all mounted filesystems

cr0x@server:~$ sudo fstrim -av
/: 18.7 GiB (20068429824 bytes) trimmed on /dev/nvme0n1p2
/var: 2.1 GiB (2254857830 bytes) trimmed on /dev/nvme0n1p3

Signification : -a signifie « tous les systèmes de fichiers montés qui le supportent » ; -v affiche ce qui s’est passé. Si vous voyez « Operation not supported », vous avez un problème de pile ou de limitation du système de fichiers.

Décision : Si le trim manuel fonctionne mais pas le timer, concentrez-vous sur systemd. Si le manuel échoue, concentrez-vous sur la pile de stockage et les montages.

Task 7: Check which filesystems are eligible (mounted and in fstab)

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

Signification : Affiche les options de montage et le système de fichiers. Avec le fstrim périodique, vous n’avez pas besoin de l’option de montage discard.

Décision : Si vous utilisez discard et que vous cherchez des pics de latence, envisagez de le retirer et de vous appuyer sur le timer.

Task 8: Confirm fstrim will consider the filesystem (fstab filter)

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/fstab
UUID=8c2b1f2a-6a3f-4ad4-9b7f-3d2b0b7b6f12 /     ext4 defaults,errors=remount-ro 0 1
UUID=0f3f0c1a-27ae-4f1c-a90f-8b0b7fe1f5c1 /var  ext4 defaults                  0 2

Signification : Le fstrim.service de Debian exécute couramment fstrim --fstab, ce qui signifie qu’il utilise les entrées de fstab plutôt que « tout ce qui est monté ». Si vous montez quelque chose manuellement qui n’est pas dans fstab, il se peut qu’il ne soit jamais trimé par le timer.

Décision : Si un montage doit être trimé, ajoutez-le à fstab ou ajustez votre stratégie de trim.

Task 9: Verify the timer isn’t masked or overridden

cr0x@server:~$ systemctl is-enabled fstrim.timer
enabled

Signification : « masked » signifie que quelqu’un l’a désactivé de manière à ce que l’activation soit impossible tant que le masquage n’est pas retiré.

Décision : Si masqué, unmaskez et activez (montré plus loin). Si désactivé, activez.

Task 10: Check for systemd unit overrides that change behavior

cr0x@server:~$ systemctl cat fstrim.service
# /usr/lib/systemd/system/fstrim.service
[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)

[Service]
Type=oneshot
ExecStart=/sbin/fstrim --fstab --verbose --quiet

Signification : Si vous voyez des sections supplémentaires sous /etc/systemd/system/fstrim.service.d/, vous avez peut-être un override. Les overrides sont puissants et aussi un excellent moyen de perdre la tête de votre vous futur.

Décision : Si override présent, confirmez qu’il trim toujours ce que vous attendez et que la sortie/logging n’est pas supprimée dans l’invisibilité.

Task 11: Validate discard support through dm-crypt (LUKS)

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

Signification : Cela n’indique pas directement que le discard est activé. Pour ça, vous vérifiez typiquement /etc/crypttab ou la table device-mapper. Mais voir dm-crypt dans le chemin est un signal : les discards peuvent être bloqués à moins d’être explicitement autorisés.

Décision : Si vous utilisez LUKS et que vous voulez TRIM, prévoyez d’activer les discards délibérément (en comprenant les compromis de fuite de métadonnées).

Task 12: Confirm discard limits on device-mapper nodes

cr0x@server:~$ lsblk -D -o NAME,TYPE,DISC-GRAN,DISC-MAX /dev/mapper/cryptroot
NAME     TYPE DISC-GRAN DISC-MAX
cryptroot crypt     4K       2T

Signification : Si le mappage dm-crypt annonce la capacité de discard, le chemin est au moins plausible. S’il affiche 0B/0B, les discards sont bloqués à ce niveau.

Décision : 0B/0B ici : corrigez les options dans crypttab ou acceptez « pas de TRIM » pour ce volume.

Task 13: Validate that the filesystem supports trimming

cr0x@server:~$ df -T /
Filesystem     Type  1K-blocks      Used Available Use% Mounted on
/dev/nvme0n1p2 ext4  960379552 302118912 609136192  34% /

Signification : ext4, xfs, btrfs supportent généralement TRIM. Certains systèmes de fichiers anciens ou exotiques peuvent ne pas le supporter, ou exiger des options spécifiques.

Décision : Si vous êtes sur quelque chose d’exotique, vérifiez le support et ce à quoi vous pouvez vous attendre. Si vous êtes sur ext4/xfs/btrfs et que les discards échouent, le problème se situe probablement en dessous du système de fichiers.

Task 14: Check whether you’re inside a VM that doesn’t pass discards

cr0x@server:~$ systemd-detect-virt
kvm

Signification : Être virtualisé n’interdit pas TRIM, mais cela signifie que l’hyperviseur et le type de disque virtuel doivent être configurés pour transmettre discard/unmap.

Décision : Si c’est une VM, coordonnez-vous avec l’équipe plateforme (ou avec vous-même, si vous portez ce chapeau) pour activer le passage des discards de bout en bout.

Task 15: Dry-run whether discards are refused at the block layer

cr0x@server:~$ sudo blkdiscard -v -n /dev/nvme0n1p2
blkdiscard: /dev/nvme0n1p2: 0 bytes were discarded

Signification : -n est un dry run sur de nombreux systèmes (n’effectue pas réellement le discard). Ceci vérifie que le chemin ioctl existe. Si vous obtenez « Operation not supported », la pile du noyau n’accepte pas les discards pour ce périphérique.

Décision : Si non supporté ici, fstrim ne peut rien faire. Corrigez la couche sous-jacente, ou arrêtez d’essayer.

Task 16: Confirm the timer actually fired when you think it did (time and missed runs)

cr0x@server:~$ systemctl show -p LastTriggerUSec,LastTriggerUSecMonotonic fstrim.timer
LastTriggerUSec=Sun 2025-12-28 00:22:09 UTC
LastTriggerUSecMonotonic=120394889230

Signification : Confirme la dernière heure de déclenchement. Utile si vous suspectez des timers manqués après une mise en veille, une coupure ou des sauts d’horloge.

Décision : Si le timer ne se déclenche pas, enquêtez sur le comportement des timers systemd, l’horloge système, et si l’unité est inhibée.

Activer le timer fstrim sur Debian 13 (la bonne méthode)

Sur Debian avec systemd, vous voulez le timer, pas un cron aléatoire trouvé dans un billet de blog de 2014. Le timer s’intègre à la journalisation du service, aux dépendances et à la gestion uniforme. Il facilite aussi les audits.

Enable and start the timer

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

Signification : Activé au démarrage et démarré immédiatement. Dorénavant, Debian devrait exécuter automatiquement le TRIM hebdomadaire.

Décision : Si vous gérez des flottes, intégrez cela dans votre baseline (Ansible, Salt, ou autre). Ne comptez pas sur « quelqu’un s’en souviendra ».

If it’s masked, unmask it

cr0x@server:~$ sudo systemctl unmask fstrim.timer
Removed "/etc/systemd/system/fstrim.timer".

Signification : Le masquage est le réglage « je veux vraiment désactiver ». Unmask supprime ce blocage dur.

Décision : Si c’était masqué, découvrez pourquoi. Le masquage est souvent une cicatrice d’un incident, d’une posture de sécurité, ou d’un tweak malavisé.

Force a run now (without waiting a week)

cr0x@server:~$ sudo systemctl start fstrim.service

Signification : Pas d’affichage est normal ; vérifiez le journal pour les résultats.

Décision : Vérifiez toujours les octets trimés dans les logs. Un « run réussi » qui n’a rien trimé peut indiquer quand même un problème.

Adjust scheduling (carefully)

La cadence hebdomadaire par défaut convient à la plupart des serveurs. Si vous gérez de grosses bases de données à fort turnover, vous pouvez vouloir un trim plus fréquent — mais ne devinez pas. Mesurez. Un trim excessivement fréquent est généralement sans conséquence sur les disques modernes, mais il peut devenir du bruit de fond gênant dans les profils de performance.

Si vous devez changer le planning, utilisez un override systemd pour le timer, pas des modifications des unités fournisseurs. Exemple : le passer en exécution quotidienne à une heure prévisible.

cr0x@server:~$ sudo systemctl edit fstrim.timer

Ensuite ajoutez un override comme ceci (l’éditeur systemd s’ouvrira) :

cr0x@server:~$ cat /etc/systemd/system/fstrim.timer.d/override.conf
[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true

Signification : RandomizedDelaySec empêche tous les serveurs d’une flotte de trim au même instant. Persistent=true signifie que si la machine était éteinte au moment prévu, systemd exécutera la tâche manquée au prochain démarrage.

Décision : Pour des flottes, conservez la randomisation. Si vous voulez « exactement 02:00 », acceptez le risque d’un petit thundering herd auto-infligé.

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart fstrim.timer

Vérifier que TRIM fonctionne de bout en bout (la partie que l’on saute)

Voici la vérité inconfortable : voir fstrim rapporter « X GiB trimmed » est bon, mais pas suffisant dans tous les environnements. Dans une VM, un LUN thin, un SAN ou une configuration device-mapper en couches, vous vous souciez de savoir si les discards se propagent jusqu’au stockage physique.

Verify from the filesystem outward

Commencez par la sortie de fstrim -av et les entrées du journal. Si elles montrent des octets trimés et pas d’erreurs, le système de fichiers émet des discards.

Puis vérifiez que le périphérique bloc accepte réellement le discard avec lsblk -D. Vous voulez des valeurs non nulles au niveau le plus bas pertinent (périphérique NVMe/SATA physique) et au niveau mappé que vous trimmez (volumes LUKS/LVM).

Know what “0 bytes trimmed” really means

Zéro octet trimé peut être parfaitement normal. Si vous avez trimé hier et que rien n’a changé, il n’y a rien à libérer. Cela peut aussi signifier :

• le système de fichiers ne supporte pas TRIM,
• le périphérique ne supporte pas le discard,
• le discard est bloqué par une couche intermédiaire,
• vous trimez un montage qui n’est pas sur un stockage backé par SSD.

Verify the schedule actually runs when the machine is “on”

Les laptops, serveurs de labo et nœuds edge sont notoires : ils sont éteints la nuit, en veille le week-end, et leurs timers ne se déclenchent jamais. C’est pour ça que Persistent=true existe — utilisez-le quand c’est approprié.

Blague #2 : Si votre timer ne fonctionne que lorsque le serveur est éteint, félicitations — vous avez inventé la fenêtre de maintenance de Schrödinger.

Où TRIM meurt : chiffrement, LVM, RAID, SAN et VMs

TRIM est une requête qui doit survivre à un parcours à travers de multiples composants. Chacun d’entre eux peut la bloquer pour des raisons allant de « défaut de sécurité » à « firmware de contrôleur d’une ère géologique différente ». Voici comment cela casse couramment et ce que vous pouvez faire.

LUKS/dm-crypt : sécurité vs récupération

dm-crypt peut transmettre les discards, mais il faut généralement s’y inscrire explicitement. Le risque : les discards peuvent révéler quelles zones sont utilisées, une forme de fuite de métadonnées. Dans beaucoup de modèles de menace (la plupart des salles serveurs), c’est acceptable. Dans d’autres (certains laptops, environnements à haut risque), ce ne l’est pas.

Sur Debian, activer les discards pour une racine chiffrée implique souvent d’ajouter discard à l’entrée concernée dans /etc/crypttab, puis de reconstruire l’initramfs et redémarrer. Ne faites pas cela à la légère en production sans comprendre votre chaîne de boot et votre plan de récupération.

cr0x@server:~$ sudo grep -vE '^\s*#|^\s*$' /etc/crypttab
cryptroot UUID=2d4f1f67-8f5f-4a4b-9a0e-2c6d52f9c5a1 none luks,discard

Signification : L’option discard indique à dm-crypt de transmettre les requests de discard en aval. Sans cela, les périphériques mappés affichent souvent 0B discard dans lsblk -D.

Décision : Décidez en fonction du modèle de menace. Si vous l’activez, vérifiez avec lsblk -D aux niveaux dm-crypt et périphérique sous-jacent après redémarrage.

LVM (thick et thin)

LVM classique (thick) sur SSD se comporte généralement bien tant que le PV sous-jacent supporte le discard et que rien ne le bloque. LVM thin provisioning est l’endroit où il faut être très prudent : les discards peuvent récupérer de l’espace dans le thin pool, mais les paramètres et le comportement du noyau comptent.

Si votre objectif est de récupérer de l’espace de pool thin (ou en amont sur un SAN), vous ne faites pas seulement de l’optimisation de santé SSD : vous gérez la capacité. Validez toute la chaîne.

mdadm RAID et RAID matériel

Le support du discard par RAID logiciel (md) s’est amélioré, mais dépend du niveau RAID et du noyau. Le RAID matériel est un autre univers : certains contrôleurs traduisent correctement le discard, d’autres le laissent tomber. Parfois la seule façon de le savoir est de tester et d’observer la récupération d’espace en amont.

Machines virtuelles : l’hyperviseur doit coopérer

Dans les environnements KVM/QEMU, le support du discard dépend du type de disque virtuel (virtio-scsi vs virtio-blk), des réglages comme « discard=unmap », et du stockage de backing. Sur VMware, cela dépend du provisioning du disque virtuel et si UNMAP est activé. Sur les clouds, cela dépend de ce qu’ils exposent.

Le guest peut être parfaitement configuré et envoyer des requêtes TRIM dans un vide si l’hôte refuse de les transmettre.

Filesystems : nuance ext4, xfs, btrfs

• ext4 : TRIM périodique via fstrim est la pratique normale. L’option de montage discard existe mais n’est pas obligatoire.
• xfs : Supporte aussi fstrim. Bon pour les grands systèmes de fichiers ; le trim est généralement simple.
• btrfs : Supporte le discard et a ses propres subtilités. Beaucoup d’administrateurs préfèrent encore le fstrim périodique pour garder le comportement explicite.

Trois mini-récits en entreprise depuis le terrain

Incident causé par une hypothèse erronée : « On est sur SSD, donc TRIM doit être activé »

Une entreprise moyenne a migré un cluster de traitement par lots depuis des SSD SATA vers des NVMe. Ils ont fait la migration de façon « raisonnable » : images OS construites une fois, déployées partout, et stockage géré par une disposition LVM chiffrée standard. Tout le monde a supposé que les performances s’amélioreraient automatiquement.

Ça a marché — au début. Puis, au fil de quelques semaines, les nœuds à forte écriture ont commencé à afficher des temps de traitement plus longs. Rien de dramatique, juste suffisamment pour rater parfois des SLO internes. Les graphiques ressemblaient à une marée lente, pas une chute brutale. Ce sont les pires.

L’équipe a chassé les suspects habituels : voisins bruyants, mises à jour du noyau, latence réseau, régressions applicatives. Un ingénieur perspicace a finalement exécuté lsblk -D et a remarqué que la couche dm-crypt rapportait 0B de discard. Le fstrim manuel « fonctionnait » sur certains montages mais ne trimait que des quantités ridicules. Les disques faisaient la garbage collection sans savoir quoi était libre. L’amplification d’écriture a augmenté et les performances soutenues ont décliné.

La correction n’était pas exotique : ils ont explicitement activé les discards pour les volumes chiffrés (après revue de sécurité) et vérifié les octets trimés dans journald chaque semaine. Les performances se sont stabilisées. La leçon : « SSD » n’est pas une configuration. C’est un fait matériel. La pile logicielle doit toujours savoir ce que vous voulez.

Par la suite, ils ont ajouté un contrôle de conformité de base : si un montage sur SSD affiche 0B de discard au niveau mappé, le nœud échoue la readiness. C’était légèrement gênant. Ça les a empêchés de répéter la même erreur dans l’environnement suivant.

Optimisation qui s’est retournée contre eux : activation du discard continu partout

Une autre organisation avait une philosophie simple : « Si discard est bon, plus de discard est mieux. » Ils ont activé l’option de montage discard sur toute une flotte, y compris des serveurs de bases de données et quelques machines d’ingestion de logs qui martelaient le système de fichiers avec de petites écritures et suppressions.

L’effet a été subtil au début. Les centiles de latence ont augmenté, surtout pendant les pics d’ingestion. Pas de façon consistante — juste assez pour rendre les nuits d’astreinte piquantes. L’équipe a vu une augmentation du I/O wait mais n’a pas pu la relier clairement aux changements applicatifs.

Finalement, quelqu’un a corrélé les pics à des opérations fréquentes de discard dans les traces du bloc. Le discard continu ajoutait du travail synchrone à des moments inopportuns, et le backend de stockage n’était pas ravi de ce bavardage d’unmap constant non plus. L’optimisation s’était transformée en jitter.

Ils sont revenus au fstrim périodique via le timer systemd. Le profil de latence s’est calmé et l’espace a quand même été récupéré sur un planning prévisible. La morale : une maintenance prévisible bat un comportement « intelligent » qui se déclenche au pire moment.

Pratique ennuyeuse mais correcte qui a sauvé la mise : journalisation et vérification régulières

Une équipe de services financiers faisait tourner Debian sur des NVMe chiffrés, avec un mix de bare metal et de VMs. Ils avaient une checklist opérationnelle hebdomadaire qui incluait la revue de la santé des timers systemd et la vérification qu’un ensemble de services de maintenance fonctionnaient. Oui, c’était ennuyeux. Oui, c’était efficace.

Un week-end, ils ont remarqué un changement dans les entrées de journal de fstrim : toujours « SUCCESS », mais les octets trimés sont tombés à presque zéro sur plusieurs VMs qui trim normalement quelques gigaoctets. Aucun alerting n’avait déclenché car rien n’avait « échoué ». Des humains l’ont remarqué parce qu’ils regardaient.

Il s’est avéré que la plateforme de virtualisation avait été mise à jour et qu’un comportement par défaut avait changé : le discard/unmap n’était plus transmis aux invités pour un sous-ensemble de types de disque. Les invités continuaient d’émettre des discards ; l’hôte les ignorait poliment. Le stockage thin-provisionné a commencé à gonfler, et l’équipe SAN allait passer un mauvais mois.

Parce que l’équipe ops l’a détecté tôt, la correction a été propre : mettre à jour la configuration des disques VM pour autoriser le discard et valider avec le trim côté guest et la récupération d’espace côté hôte. Pas d’achat d’urgence de capacité, pas de fenêtre d’intervention le week-end, pas de réunion exécutive « comment avons-nous raté ça ? ». La pratique ennuyeuse a payé pour elle-même, discrètement, comme la plupart du bon travail SRE.

Erreurs courantes : symptôme → cause → correctif

1) « TRIM ne s’exécute pas » mais le timer est désactivé

Symptôme : systemctl status fstrim.timer montre disabled/inactive ; list-timers n’affiche pas fstrim.

Cause racine : Le timer n’a jamais été activé (ou une image de base l’a désactivé il y a longtemps).

Fix : Activez et démarrez : systemctl enable --now fstrim.timer. Puis lancez systemctl start fstrim.service et vérifiez journalctl -u fstrim.service.

2) Timer activé, mais rien ne se passe pendant des semaines

Symptôme : Timer activé ; LAST est « n/a » ou très ancien ; machine souvent éteinte/en veille.

Cause racine : Le système n’était pas actif au moment planifié ; le timer n’est pas persistant.

Fix : Ajoutez un override de timer avec Persistent=true. Ou planifiez-le plus fréquemment avec randomisation.

3) fstrim manuel échoue avec « Operation not supported »

Symptôme : sudo fstrim -av montre des erreurs ; blkdiscard indique non supporté ; lsblk -D affiche 0B discard.

Cause racine : Le périphérique ou une couche (LUKS, RAID, hyperviseur) ne supporte/passe pas le discard.

Fix : Identifiez la couche qui rapporte 0B dans lsblk -D. Activez le passage des discards (options crypttab / réglages hyperviseur) ou acceptez l’absence de TRIM pour ce chemin.

4) fstrim s’exécute mais ne trim que « / » et saute /var ou montages de données

Symptôme : Le journal montre le trim pour certains montages seulement.

Cause racine : fstrim --fstab ne trim que les montages définis dans fstab ; le montage n’est pas dans fstab ou n’est pas monté au moment de l’exécution.

Fix : Mettez le montage dans /etc/fstab (ou ajustez votre unité pour utiliser -a sans --fstab si vous voulez vraiment « tout ce qui est monté »). Assurez-vous qu’il soit monté quand le timer tourne.

5) « 0 bytes trimmed » en permanence, alors que vous en attendiez plus

Symptôme : Le trim réussit, mais trim toujours 0 bytes.

Cause racine : Pas de blocs récemment libérés depuis le dernier trim ; système de fichiers presque plein ; ou discards coalescés/ignorés en amont.

Fix : Libérez de l’espace et retestez. Vérifiez le support du discard avec lsblk -D à chaque couche. Dans les environnements thin-provisionnés, validez la récupération en amont séparément.

6) Vous avez activé discard sur des volumes chiffrés et vous êtes devenus nerveux pour la sécurité

Symptôme : La revue sécurité signale un risque de fuite de métadonnées.

Cause racine : Les discards peuvent révéler des schémas d’allocation.

Fix : Décidez explicitement. Si le modèle de menace l’exige, gardez les discards désactivés et acceptez les compromis de performance/usure. N’activez pas « à moitié » d’une manière que personne ne comprendra plus tard.

7) Vous avez essayé de « réparer » avec cron et vous avez maintenant deux trims qui se concurrencent

Symptôme : Trims qui s’exécutent deux fois, logs confus, parfois chevauchement.

Cause racine : Cron job plus timer systemd, les deux actifs.

Fix : Supprimez la tâche cron. Gardez le timer systemd. Un responsable par job.

Listes de contrôle / plan étape par étape

Checklist A: Minimal fix (single Debian 13 host, bare metal SSD)

1. Vérifiez la capacité de discard : exécutez lsblk -D. Confirmez que votre SSD montre des valeurs de discard non nulles.
2. Activez le timer : systemctl enable --now fstrim.timer.
3. Forcer une exécution : systemctl start fstrim.service.
4. Vérifiez les résultats : journalctl -u fstrim.service -n 50. Cherchez « X bytes trimmed » sur les montages attendus.
5. Confirmez le planning : systemctl list-timers --all | grep fstrim.

Checklist B: Layered storage (LUKS + LVM + SSD)

1. Vérifiez le discard du périphérique de base : lsblk -D /dev/nvme0n1.
2. Vérifiez le discard du périphérique mappé : lsblk -D /dev/mapper/cryptroot (et des LVs si applicable).
3. Si la couche mappée montre 0B discard, relisez /etc/crypttab pour l’option discard, puis appliquez le changement en toute sécurité (initramfs + reboot si la racine est chiffrée).
4. Exécutez fstrim -av et confirmez les octets trimés.
5. Confirmez l’automatisation hebdomadaire via le timer et le journal.

Checklist C: VM guest on shared storage (the “trust but verify” plan)

1. Dans le guest : lsblk -D doit montrer le support de discard sur le disque virtuel.
2. Dans le guest : exécutez fstrim -av. Confirmez l’absence de « Operation not supported ».
3. Confirmez la planification du timer et les entrées journald au fil du temps.
4. Côté hôte/stockage : vérifiez que l’unmap/discard est activé pour le type de disque VM et que la récupération d’espace est observable (spécifique à la plateforme).
5. Documentez-le. « On pense que ça marche » n’est pas un contrôle.

Checklist D: Fleet baseline (what you automate)

1. Assurez-vous que fstrim.timer est activé sur tous les nœuds backés par SSD.
2. Override du timer avec randomisation et persistence lorsque approprié.
3. Conformité quotidienne/hebdo : vérifiez systemctl is-enabled fstrim.timer et parsez journalctl -u fstrim.service pour des exécutions récentes réussies.
4. Alertez sur « Operation not supported » et sur une chute globale soudaine des octets trimés à travers un cluster (c’est ainsi que l’on détecte des régressions d’hyperviseur).

FAQ

1) Dois-je utiliser l’option de montage discard ou le fstrim hebdomadaire ?

Utilisez fstrim hebdomadaire pour la plupart des systèmes. C’est prévisible et plus facile à raisonner. Utilisez le discard continu seulement après mesure et si vous savez qu’il n’affecte pas négativement vos latences.

2) Pourquoi Debian utilise un timer plutôt que cron ?

Les timers systemd s’intègrent à la gestion des dépendances et à journald. Opérationnellement, ils sont plus faciles à inspecter et auditer (list-timers, logs par unité) qu’un crontab mystérieux.

3) Si fstrim dit « X GiB trimmed », est-ce que le SSD l’a vraiment récupéré ?

Cela signifie que le système de fichiers a émis des discards et que le noyau les a acceptés. Dans des configurations en couches (VMs, SAN, thin provisioning), vous devez encore confirmer que la couche de backing les honore.

4) Est-ce sûr d’activer le discard sur LUKS ?

C’est un compromis. Cela peut fuiter des schémas d’allocation (quels blocs sont utilisés). Beaucoup de modèles de menace serveurs l’acceptent ; d’autres non. Décidez délibérément, documentez et ne mélangez pas les hypothèses.

5) Pourquoi fstrim saute certains montages ?

Souvent parce que Debian exécute fstrim --fstab. Si un montage n’est pas dans /etc/fstab (ou n’est pas monté), il ne sera pas inclus. Confirmez avec la sortie du journal et findmnt.

6) Est-ce grave si fstrim trim 0 bytes ?

Pas nécessairement. S’il n’y a rien de nouveau à libérer, 0 est attendu. S’il est toujours à 0 sur un système actif où vous supprimez régulièrement des données, investiguez le support du discard avec lsblk -D et vérifiez les blocages.

7) TRIM peut-il causer des problèmes de performance ?

TRIM périodique a généralement un impact minimal. Le discard continu peut ajouter de la latence dans certains workloads. Aussi, trimer de très gros systèmes de fichiers en période de pic peut concurrencer d’autres I/O — planifiez-le intelligemment si vous êtes sensible.

8) Ai-je besoin de TRIM sur des SSD NVMe ou d’entreprise ?

Oui, en général. Les disques d’entreprise ont des contrôleurs et firmware meilleurs, mais ils bénéficient toujours de la connaissance exacte de l’espace libre pour réduire l’amplification d’écriture et améliorer les performances en régime permanent.

9) Qu’en est-il des partitions swap et TRIM ?

Le swap sur SSD peut être trimé, mais le comportement dépend du noyau et de la configuration. Dans la plupart des cas, vos gains principaux viennent du trim des systèmes de fichiers principaux et de la vérification du support des discards.

10) Comment prouver que TRIM s’exécute régulièrement pour un audit ?

Utilisez systemctl list-timers pour la preuve du planning et journalctl -u fstrim.service pour l’évidence d’exécution et les octets trimés. C’est opérationnellement crédible et reproductible.

Conclusion : prochaines étapes qui réduisent réellement le risque

Activez le timer, lancez un trim une fois, et vérifiez les logs. C’est la base. Ensuite faites la partie adulte : confirmez le support du discard à travers chaque couche de stockage dont vous dépendez. Si vous êtes en VM ou sur du stockage thin-provisionné, traitez « TRIM fonctionne » comme un contrat multi-équipes, pas seulement un réglage invité.

Prochaines étapes pratiques :

1. Exécutez lsblk -D et identifiez où le discard devient 0B/0B.
2. Activez et démarrez fstrim.timer ; déclenchez fstrim.service manuellement une fois.
3. Vérifiez que les entrées du journal montrent des octets trimés significatifs sur les montages qui vous importent.
4. Si chiffré : décidez de l’option discard dans crypttab selon le modèle de menace, puis implémentez proprement et validez après le reboot.
5. Si virtualisé : vérifiez les réglages discard/unmap de l’hyperviseur et confirmez la récupération d’espace en amont.
6. Pour les flottes : ajoutez un contrôle de conformité pour timer activé + logs récents de trim réussi, et alertez sur les changements de comportement de trim.

TRIM n’est pas glamour. C’est pour ça qu’il échoue silencieusement. Rendez-le à nouveau ennuyeux : activé, vérifié et sans histoire.