ZFS autotrim : maintenir la rapidité des pools SSD dans le temps

novembre 24, 2025 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

Les SSD sont rapides, jusqu’à ce qu’ils ne le soient plus. Pas de façon catastrophique, pas avec des erreurs bruyantes—juste progressivement plus lents, avec une latence plus bruyante et des performances étrangement incohérentes sous des charges d’écriture lourdes. Dans l’univers ZFS, ce « SSD qui vieillit » est souvent juste le flash translation layer (FTL) du disque qui manque de réponses faciles parce qu’il ne sait pas quelles zones vous avez cessé de considérer comme utiles.

TRIM est la façon de dire au SSD : « Ces blocs sont libres ; vous pouvez les réutiliser quand vous voulez. » L’autotrim de ZFS est la méthode adaptée à la production pour maintenir cette conversation sans transformer votre équipe stockage en culte du job batch du week-end. Cet article explique ce que fait réellement autotrim, ce qu’il ne fait pas, et comment l’exécuter en toute sécurité quand votre pool est le cœur battant d’un business qui attend que la disponibilité soit ennuyeuse.

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

Autotrim dans ZFS est TRIM continu. Quand ZFS libère des blocs—parce que vous avez supprimé des données, les avez écrasées, détruit un snapshot, ou qu’un bloc est relocalisé—autotrim peut transmettre à l’SSD l’indice « ces LBAs ne sont plus utilisés ». Le SSD peut alors effacer proactivement des blocs de flash en arrière-plan, pour que les prochaines écritures n’aient pas à payer la « taxe de garbage collection » au pire moment possible.

Autotrim n’est pas un défragmenteur. Il ne défragmentera pas votre pool ni ne rendra les données anciennes contiguës. Il ne récupère pas non plus magiquement de l’espace ; ZFS connaît déjà son propre espace libre. TRIM concerne le ménage interne du périphérique et l’amplification d’écriture, pas la comptabilité de ZFS.

Autotrim n’est pas non plus un substitut au bon dimensionnement et à l’overprovisioning. Si votre pool est rempli à 95 %, autotrim revient à demander poliment à un ascenseur d’aller plus vite pendant que vous continuez à entasser des personnes dedans. L’ascenseur continuera de s’arrêter à chaque étage.

Une petite blague, parce que le stockage a besoin de mécanismes d’adaptation : TRIM, c’est en gros dire à votre SSD « ce n’est pas toi, c’est moi. » Malheureusement, le SSD se souvient de tout quand même—juste plus lentement quand il est vexé.

La réalité des SSD avec laquelle ZFS négocie

Les SSD n’écrivent pas en place. Les pages de flash sont écrites, mais les effacements se font à une granularité plus grande (erase blocks). Quand vous « écrasez » un LBA, le SSD écrit généralement les nouvelles données ailleurs et marque l’ancien emplacement physique comme obsolète. Plus tard, la garbage collection consolide les pages valides et efface les anciens blocs pour qu’ils puissent être réutilisés. C’est là que l’amplification d’écriture apparaît : vous avez écrit 4 KB, mais le SSD a dû déplacer 256 KB pour nettoyer un bloc.

TRIM aide parce qu’il réduit la quantité de données « peut-être encore valides » que le SSD doit préserver pendant la garbage collection. Si le SSD sait qu’une plage est inutilisée, il peut l’ignorer immédiatement. Cela signifie souvent une variance de latence plus faible et de meilleures performances d’écriture soutenues, surtout après de longues périodes de churn.

En exploitation d’entreprise, la variance de latence est le tueur. Les moyennes ne vous réveillent pas. La latence en queue de distribution vous réveille, et elle vous réveille à 02:13 avec un panneau Grafana à moitié rendu et une équipe base de données qui se souvient soudainement de votre prénom.

Faits intéressants et contexte historique

TRIM est arrivé comme commande ATA standardisée à la fin des années 2000 quand les SSD ont commencé à montrer un comportement « rapides sortis de la boîte, six mois plus tard… hum » sous des charges desktop.
NVMe utilise « Dataset Management » (deallocate) plutôt que ATA TRIM, mais l’intention est la même : communiquer les LBAs inutilisés pour que le contrôleur optimise.
Les firmwares SSD initiaux ignoraient souvent TRIM ou le géraient mal, d’où la méfiance des anciens quand vous dites « activez discard ».
ZFS ciblait à l’origine des disques où les réécritures étaient bon marché et où la connaissance de l’espace libre était surtout une préoccupation OS, pas un souci du périphérique.
Les filesystems copy-on-write (ZFS, btrfs) changent l’histoire du TRIM parce que les libérations se produisent en rafales (destructions de snapshot, commits de transaction group), pas comme des réécritures en place.
Certaines cartes RAID gardaient le TRIM bloqué ou le traitaient mal, surtout avec du hardware RAID sur SATA. Les HBAs modernes en mode IT sont généralement plus sûrs pour ZFS.
Le thin provisioning dans les SANs a un concept similaire : il faut UNMAP/discard pour rendre les blocs libérés à l’array ; sans cela, l’array reste « plein » pour toujours.
« Secure erase » n’est pas TRIM ; secure erase est une opération destructrice de remise à zéro, tandis que TRIM est un indice sur l’espace inutilisé.

Comment TRIM/autotrim ZFS fonctionne en interne

ZFS suit les allocations au niveau du pool dans les metaslabs. Quand des blocs sont libérés, ils passent d’alloués à libres dans la vue de ZFS. Autotrim ajoute une seconde étape : il émet des TRIM/deallocate pour ces plages vers les vdevs sous-jacents.

Il existe deux modèles opérationnels que vous verrez :

Autotrim continu : activé au niveau du pool pour que les libérations déclenchent des indices TRIM au fil du temps.
Trim manuel « zpool trim » : une opération de fond explicite qui parcourt les space maps et envoie des trims pour les régions libres, utile après l’import d’un pool, après une grosse suppression, ou quand on active autotrim tard.

Nuance importante : ZFS ne peut pas toujours trimmer des régions parfaitement contiguës et larges parce que les allocations peuvent être entrelacées et à cause de la façon dont les space maps enregistrent les allocations historiques. De plus, trimmer trop agressivement peut entrer en compétition avec l’I/O réelle. Comme toujours dans le stockage, c’est un compromis entre « faire du travail maintenant pour éviter du travail plus tard » et « s’il vous plaît, ne faites pas de travail quand mes bases écrivent ».

Deuxième blague, parce qu’on l’a tous méritée : activer autotrim sur un pool occupé puis benchmarker immédiatement, c’est comme balayer la cuisine en recevant des invités—techniquement productif, socialement catastrophique.

Activer, vérifier et observer autotrim

La première question en production n’est pas « puis-je l’activer ? » mais « quoi d’autre va-t-il toucher ? » Autotrim affecte la couche périphérique et peut changer les schémas d’I/O, surtout sur des SSD SATA avec des queues limitées ou sur des systèmes où les opérations discard se sérialisent derrière d’autres commandes.

NVMe moderne tend à gérer les deallocate avec moins de drame, mais « tend à » n’est pas « garantit ». La bonne approche est : activez autotrim, observez la latence et l’utilisation des périphériques, et soyez prêt à revenir en arrière ou à planifier des trims manuels si nécessaire.

Aussi : confirmez que l’ensemble du chemin le supporte. Le firmware du disque, le transport (SATA/SAS/NVMe), le mode du contrôleur et le pilote OS comptent tous. Si vous êtes sur une plateforme virtualisée et que le « SSD » est un disque virtuel, TRIM peut être avalé par la couche hyperviseur.

Tâches pratiques : commandes + interprétation

Les suivantes sont des tâches de production que j’exécute réellement (ou que j’aurais aimé exécuter plus tôt). Les commandes sont montrées pour Linux avec OpenZFS, et elles sont réalistes ; adaptez les noms de périphériques et de pools.

Task 1: Identify pools and vdevs (baseline inventory)

cr0x@server:~$ sudo zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank   7.25T  3.90T  3.35T        -         -    18%    53%  1.00x  ONLINE  -

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_1    ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_2    ONLINE       0     0     0

Interpretation : Sachez ce que vous êtes en train de trimmer. Les mirrors et RAIDZ se comportent différemment sous pression ; assurez-vous aussi que vous êtes réellement sur SSD/NVMe et pas sur un mélange avec un périphérique SATA surprise.

Task 2: Check whether the pool has autotrim enabled

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  off       default

Interpretation : off signifie que ZFS n’émettra pas continuellement des indices TRIM lors des libérations. Cela ne veut pas dire que le SSD est condamné—cela signifie simplement qu’on s’appuie davantage sur les heuristiques internes et sur tout trim manuel périodique que vous effectuez.

Task 3: Enable autotrim (and record the change)

cr0x@server:~$ sudo zpool set autotrim=on tank
cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE  SOURCE
tank  autotrim  on     local

Interpretation : C’est un changement en direct. Surveillez la latence et l’utilisation des périphériques pendant un moment, surtout si le pool est chargé ou presque plein.

Task 4: Run a one-time trim pass (useful after enabling late)

cr0x@server:~$ sudo zpool trim tank
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim in progress since Thu Dec 21 02:11:54 2025
        1.20T trimmed, 22.3% done, 0:36:18 to go
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_1    ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_2    ONLINE       0     0     0

Interpretation : Le trim manuel est une activité en arrière-plan (similaire à scrub/resilver dans l’esprit). Il peut quand même entrer en concurrence avec la charge. Traitez-le comme un événement d’exploitation : planifiez-le, observez-le et arrêtez-le s’il gêne.

Task 5: Pause or stop an in-progress trim (when it hurts)

cr0x@server:~$ sudo zpool trim -s tank
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim stopped since Thu Dec 21 02:51:09 2025
        1.34T trimmed, 24.9% done

Interpretation : Arrêter un trim n’est pas un échec. C’est un levier de contrôle. Quand la charge business souffre, vous interrompez les tâches de fond et vous revenez plus tard.

Task 6: Confirm the device advertises discard/TRIM support (SATA/SCSI path)

cr0x@server:~$ lsblk -D
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1             0      512B       2T         0
nvme1n1             0      512B       2T         0

Interpretation : Une granularité/max non nulle est un bon signe. Si ces champs sont à zéro sur des SSD, discard peut être bloqué par la pile (contrôleur, pilote, virtualisation).

Task 7: Verify NVMe deallocate capabilities (NVMe devices)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | sed -n '1,80p'
vid     : 0x144d
ssvid   : 0x144d
sn      : S4X9NF0M123456
mn      : SAMSUNG MZVLB1T0HBLR-00000
fr      : EXA7301Q
...
oncs    : 0x001f
...

Interpretation : Les capacités du contrôleur varient selon le modèle/firmware. Vous recherchez le support des fonctionnalités de dataset management dans la pile, et vous voulez un firmware à jour car les « quirks » NVMe existent.

Task 8: Watch pool-level latency and throughput during trim

cr0x@server:~$ sudo zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.90T  3.35T    122    410  26.1M  71.4M
  mirror    3.90T  3.35T    122    410  26.1M  71.4M
    nvme0n1     -      -     61    210  13.0M  36.2M
    nvme1n1     -      -     61    200  13.1M  35.2M

Interpretation : C’est votre premier contrôle « est-ce que ça gêne ? ». Si les opérations d’écriture grimpent mais que la bande passante ne suit pas, ou si les temps de service explosent (voir tâches suivantes), le trim peut être en compétition avec votre charge.

Task 9: Observe per-disk latency and queueing with iostat

cr0x@server:~$ iostat -x 1
Linux 6.6.0 (server) 	12/25/2025 	_x86_64_	(32 CPU)

Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
nvme0n1         62.0   215.0    13.2    36.7   2.10    0.65   58.0
nvme1n1         61.0   205.0    13.0    35.9   2.05    0.61   56.9

Interpretation : Sur NVMe, await en millisecondes faibles et à un chiffre sous charge est souvent acceptable ; les pics dans les dizaines de ms sont là où les applications commencent à « se sentir hantées ». Pour les SSD SATA, des valeurs plus élevées peuvent rester normales, mais c’est la tendance qui compte.

Task 10: Check dataset properties that influence churn (recordsize, atime, sync)

cr0x@server:~$ sudo zfs get -o name,property,value,source recordsize,atime,sync tank
NAME  PROPERTY    VALUE   SOURCE
tank  recordsize  128K    default
tank  atime       off     local
tank  sync        standard default

Interpretation : TRIM n’améliore pas le churn pathologique. Si un dataset VM utilise un recordsize qui cause une amplification de réécriture constante, autotrim sera occupé à nettoyer les conséquences.

Task 11: Determine how full and fragmented the pool is

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  7.25T  3.90T 3.35T 53%  18%   ONLINE

Interpretation : Une CAP élevée et une FRAG élevée se corrèlent souvent avec une dégradation des performances au fil du temps. TRIM aide le SSD, mais il ne crée pas de metaslabs libres contigus dans ZFS. La solution ennuyeuse peut être « ajouter des vdevs » ou « arrêter d’utiliser le pool à 90% ».

Task 12: Check snapshot pressure (a hidden TRIM limiter)

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation -S used | head
NAME                          USED  REFER  CREATION
tank/db@hourly-2025-12-25-0200  98G  1.20T  Thu Dec 25 02:00 2025
tank/db@hourly-2025-12-25-0100  96G  1.19T  Thu Dec 25 01:00 2025
tank/db@hourly-2025-12-25-0000  95G  1.18T  Thu Dec 25 00:00 2025

Interpretation : Si les snapshots épinglent d’anciens blocs, les suppressions ne libèrent pas réellement l’espace. Cela signifie moins d’opportunités de TRIM, et plus de vieux déchets qui traînent sur le SSD.

Task 13: Measure actual free space inside a thin-provisioned zvol (VM disks)

cr0x@server:~$ sudo zfs get -o name,property,value,source volblocksize,refreservation,compressratio tank/vm-100-disk-0
NAME                 PROPERTY       VALUE  SOURCE
tank/vm-100-disk-0    volblocksize   16K    local
tank/vm-100-disk-0    refreservation none   default
tank/vm-100-disk-0    compressratio  1.35x  -

cr0x@server:~$ sudo zfs list -o name,used,logicalused,volsize tank/vm-100-disk-0
NAME                 USED  LOGICALUSED  VOLSIZE
tank/vm-100-disk-0   420G  760G         800G

Interpretation : L’OS invité peut supprimer des données, mais sans propagation du discard de guest → hyperviseur → zvol → pool → SSD, le périphérique sous-jacent n’apprend jamais que ces blocs sont libres. Autotrim aide une fois que ZFS sait que des blocs sont libres ; il ne peut pas deviner l’intention de l’invité.

Task 14: Check whether compression is helping reduce churn

cr0x@server:~$ sudo zfs get -o name,property,value,source compression,compressratio tank
NAME  PROPERTY      VALUE     SOURCE
tank  compression   lz4       local
tank  compressratio 1.52x     -

Interpretation : Moins de volume d’écriture physique signifie souvent moins de pression de garbage collection. La compression ne remplace pas TRIM, mais elle réduit la quantité de travail que TRIM tente d’atténuer.

Task 15: Validate that “freeing space” actually trims over time (operational observation)

cr0x@server:~$ sudo zfs destroy tank/tmp@old-bulk-delete
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim in progress since Thu Dec 25 03:05:41 2025
        220G trimmed, 6.4% done, 1:12:44 to go

Interpretation : De grosses destructions de snapshot peuvent déclencher beaucoup de libérations, ce qui peut déclencher beaucoup de trims. Si votre charge est sensible, planifiez les grands changements de rétention comme vous planifieriez une migration de schéma.

Task 16: Prove the stack isn’t hiding discard (sanity check with a small scratch pool)

cr0x@server:~$ sudo zpool create -o ashift=12 trimtest /dev/nvme2n1
cr0x@server:~$ sudo zpool set autotrim=on trimtest
cr0x@server:~$ sudo zfs create -o compression=off trimtest/scratch
cr0x@server:~$ sudo dd if=/dev/zero of=/trimtest/scratch/bigfile bs=1M count=2048 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 5 s, 429 MB/s
cr0x@server:~$ sudo rm /trimtest/scratch/bigfile
cr0x@server:~$ sudo zpool status -t trimtest
  pool: trimtest
 state: ONLINE
  scan: trim in progress since Thu Dec 25 03:22:10 2025
        2.00G trimmed, 100% done, 0:00:00

Interpretation : Cela ne prouve pas que chaque couche est parfaite, mais cela détecte les situations évidentes où « discard est un no-op ». Détruisez le pool de test quand vous avez fini.

Trois mini-histoires du monde d’entreprise (vraisemblables)

1) Incident causé par une mauvaise hypothèse : « SSD veut dire pas de fragmentation »

Tout a commencé par un ticket « les bases de données sont lentes » avec le ton habituel : des graphiques vagues, des opinions fortes, sans étapes de reproduction. Le pool de stockage était un RAIDZ tout-SSD, et l’hypothèse de l’équipe était que la latence SSD était si faible que le détail de l’agencement des fichiers était de la trivia.

Mais le symptôme n’était pas la latence moyenne ; c’étaient des pics périodiques. La base de données allait bien jusqu’à ce qu’elle n’aille plus bien, puis les requêtes timeoutaient par rafale. Les graphiques montraient la latence d’écriture sauter, puis redescendre, puis sauter à nouveau—comme un battement de coeur, sauf que le patient était un système de revenu.

Nous avons trouvé que le pool était au-delà de 85% de capacité avec une fragmentation croissante. De plus, autotrim n’avait jamais été activé, et l’environnement avait un churn important : datasets de staging éphémères, créations/destructions fréquentes de snapshot, et une CI qui traitait le stockage comme un gobelet jetable.

Voici la mauvaise hypothèse : « ZFS connaît l’espace libre, donc le SSD doit aussi. » Non. Le fait que ZFS connaisse l’espace libre ne se traduit pas automatiquement par le fait que le SSD sache quelles pages flash il peut laisser tomber lors de la garbage collection. Donc les disques faisaient plus de copies internes pour soutenir les écritures, et ce travail se manifestait par des pics de latence en queue quand le contrôleur décidait qu’il était temps de faire le ménage.

La correction n’a pas été héroïque. Nous avons activé autotrim, planifié un zpool trim initial en heures creuses, et—plus important—arrêté d’exploiter le pool à la capacité « je peux encore créer un dataset ». Un mois plus tard, les pics « aléatoires » avaient en grande partie disparu. L’équipe a appris une leçon qu’elle répète maintenant aux nouveaux arrivants : les SSD n’abolissent pas la physique ; ils la déplacent dans le firmware.

2) Optimisation qui a mal tourné : « tronquons tout, tout le temps, maintenant »

Un autre site, même genre de problème : dérive des performances sur des mois. Un ingénieur bien intentionné a proposé un job nightly de trim sur tous les pools, parce que « ça marche sur mon laptop ». Ils l’ont mis en cron, exécuté à minuit, et sont partis en se sentant responsables.

À 00:07, le téléphone on-call a commencé son travail habituel. Les systèmes de batch—également planifiés à minuit—se sont heurtés à un mur. Le pool n’était pas hors-ligne. C’était pire : il était vivant et douloureusement lent. La latence a grimpé, les profondeurs de queue ont augmenté, et l’équipe applicative a commencé à multiplier les retries, ce qui est l’équivalent production d’ajouter de l’essence sur un feu de camp pour le rendre « plus chaud ».

Le retour de manivelle était simple : trim, c’est de l’I/O. Sur ce modèle de SSD SATA spécifique, les commandes discard étaient effectivement sérialisées et entraient en compétition avec les écritures. Le job de trim a transformé le contrôleur SSD en un pont à voie unique juste au moment où le trafic le plus chargé voulait traverser.

La solution finale a été nuancée. Nous avons retiré le trim nightly. Nous avons activé autotrim pour l’état steady-state, puis utilisé le trim manuel seulement après de grosses libérations connues (comme la destruction d’une longue fenêtre de rétention) et seulement pendant des fenêtres où les jobs batch n’étaient pas en cours. Nous avons aussi ajouté de la supervision corrélant l’activité de trim avec la latence d’écriture, pour détecter « TRIM gêne aujourd’hui » au lieu de deviner.

Moralité : si vous planifiez une « maintenance » à minuit parce que c’est une heure creuse, vous vivez peut-être en 2009. En 2025, minuit c’est quand les jobs tournent, les backups tournent, les compactions tournent, et tout le monde fait semblant que l’internet dort. Ce n’est pas le cas.

3) Une pratique ennuyeuse mais correcte qui a sauvé la mise : gestion du changement + boucles de vérification

Celle-ci n’est pas glamour, ce qui explique pourquoi elle mérite d’être racontée. Une équipe exploitait un cluster de virtualisation multi-tenant sur des mirrors ZFS NVMe. Ils voulaient autotrim parce que le churn VM était constant et que la prévisibilité des performances importait plus que le pic d’IOPS.

Ils ont fait la chose ennuyeuse : le staged rollout. Ils ont activé autotrim sur un pool non critique d’abord, puis surveillé zpool iostat, la latence par périphérique, et les performances visibles par les invités pendant une semaine. Ils ont aussi vérifié le support du discard de bout en bout en testant une VM qui émettait des discards (et en confirmant que ZFS voyait des libérations et que le pool montrait une activité de trim).

Puis ils ont déployé pool par pool avec un plan de rollback : si la latence en queue dépassait un seuil, ils désactivaient autotrim et programmaient des trims manuels pendant des fenêtres connues calmes. Ils l’ont documenté, et prévenu les équipes applicatives de ce à quoi s’attendre.

Deux mois plus tard, un bug firmware dans une gamme de SSD a causé des blocages occasionnels du contrôleur sous de fortes commandes de dataset management. Leur supervision l’a détecté rapidement parce qu’ils avaient des métriques de base issues du déploiement progressif. Ils ont désactivé temporairement autotrim sur les pools affectés, stabilisé les performances, et remplacé le firmware pendant une fenêtre de maintenance.

Pas d’héroïsme. Pas de pointage du doigt. Juste une boucle de feedback, et ce type de retenue opérationnelle qui ne reçoit jamais une ovation mais qui maintient l’entreprise en activité.

Impacts sur les performances et décisions de réglage

Autotrim est en général un gain net sur les SSD modernes, mais « en général » n’est pas un SLA. L’impact dépend de :

Comportement du disque et du firmware : certains périphériques traitent discard comme un métadonnée bon marché ; d’autres font du travail réel immédiatement.
Transport : NVMe gère généralement mieux les files d’attente que SATA ; SAS peut varier selon l’expander/contrôleur.
Charge : les workloads à fort churn et écritures aléatoires en bénéficient le plus ; les datasets majoritairement en lecture rarement remarquent.
Remplissage du pool : les pools presque pleins amplifient tout : contention d’allocation, comportement des metaslabs, et pression GC du périphérique.
Rétention de snapshots : les snapshots épinglent des blocs, réduisant ce qui peut être libéré—et donc ce qui peut être trimé.

Il y a aussi la question subtile : autotrim change le moment où le travail est fait. Sans lui, le SSD peut différer le nettoyage jusqu’à ce que ce soit nécessaire, provoquant des pics rares mais brutaux. Avec autotrim, vous pouvez voir plus d’activité de fond constante. Beaucoup d’équipes de production préfèrent un « bruit de fond modéré et constant » plutôt qu’une « falaise de latence surprise ».

Quand hésiterais-je à activer autotrim ?

Quand le « SSD » est derrière une couche de virtualisation qui ment sur le support de discard ou le gère mal.
Sur des SSD SATA connus problématiques dans des environnements à fort écriture sans marge de performance suffisante.
Quand vous manquez d’observabilité ; l’activer à l’aveugle, c’est comment vous vous retrouvez à déboguer des ressentis.

Fiche de diagnostic rapide

Voici la séquence « c’est lent et tout le monde vous regarde ». Le but est de décider rapidement si le goulot est : (a) le comportement d’allocation ZFS / niveau pool, (b) la garbage collection/interaction trim côté périphérique, ou (c) autre chose complètement.

Step 1: Confirm it’s storage latency, not CPU or network

Vérifiez les métriques applicatives : les timeouts sont-ils alignés avec l’attente disque ?
Vérifiez le système : iowait CPU, file d’exécution, et retransmissions réseau.

cr0x@server:~$ uptime
 03:41:12 up 94 days,  5:22,  2 users,  load average: 1.12, 1.44, 1.51

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 821244  55432 9123456    0    0   120   890 4120 8200 15  7 70  8  0

Interpretation : Une montée du wa (iowait) accompagnant les plaintes est un indice, pas un verdict. Sur les systèmes modernes, cela peut être trompeur, mais c’est toujours un test olfactif rapide.

Step 2: Check pool health and obvious throttles

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

errors: No known data errors

Interpretation : Si vous êtes en train de resilver ou scruber, cette I/O de fond peut dominer. Si les erreurs montent, le « problème de performance » est parfois le système qui réessaie désespérément.

Step 3: Look at real-time pool I/O vs device I/O

cr0x@server:~$ sudo zpool iostat -v tank 1

Interpretation : Si les écritures pool sont élevées mais l’utilisation du périphérique est saturée avec une latence croissante, vous êtes limité par le périphérique. Si l’utilisation est faible mais la latence applicative élevée, suspectez les réglages sync, des périphériques log, ou une contention de niveau supérieur.

Step 4: Check if trim/autotrim activity is coincident with pain

cr0x@server:~$ sudo zpool status -t tank

Interpretation : Si trim est en cours et que votre workload souffre, arrêtez-le (zpool trim -s) et voyez si la latence revient. Ce n’est pas une solution permanente, mais c’est une expérience à fort signal.

Step 5: Validate discard support and path correctness

cr0x@server:~$ lsblk -D

Interpretation : Si discard n’est pas supporté (ou apparaît à zéro), autotrim n’aidera pas. Dans ce cas, votre seule « correction » est le comportement du firmware du disque, plus d’overprovisioning, ou un changement de périphérique/contrôleur.

Step 6: Check pool fullness, fragmentation, and snapshot pinning

cr0x@server:~$ sudo zpool list -o name,cap,frag
NAME  CAP  FRAG
tank  87%  62%

cr0x@server:~$ sudo zfs list -t snapshot | wc -l
14328

Interpretation : CAP élevée + FRAG élevée + beaucoup de snapshots = écritures lentes en attente. TRIM peut aider le SSD, mais votre ennemi plus grand peut être le comportement d’allocation sous pression.

Erreurs courantes : symptômes et corrections

Mistake 1: Enabling autotrim and benchmarking immediately

Symptôme : « Nous avons activé autotrim et les performances ont empiré. »

Pourquoi cela arrive : Vous venez d’introduire du travail de fond tout en mesurant le travail au premier plan. Vous testez « système en maintenance », pas « système en état stable ».

Correction : Mesurez avant, activez autotrim, puis mesurez après que les choses se soient stabilisées. Si vous avez besoin d’un nettoyage initial, planifiez zpool trim hors-peak et benchmarquez après la fin.

Mistake 2: Assuming deletes in guests free space on the host

Symptôme : Un invité VM supprime des données, mais l’allocation du pool ne baisse pas ; les SSD ralentissent avec le temps.

Pourquoi cela arrive : Le discard doit se propager du filesystem invité au disque virtuel au zvol au pool. Beaucoup de couches refusent le discard par défaut.

Correction : Assurez-vous que le discard invité est activé et supporté, et vérifiez avec zfs list l’usage logique vs physique et l’activité de trim. Autotrim aide seulement après que ZFS marque les blocs comme libres.

Mistake 3: Running manual trims on a schedule without load awareness

Symptôme : Pics de latence nocturnes prédictibles ou effondrements de débit.

Pourquoi cela arrive : Trim entre en compétition avec l’I/O réelle et peut se sérialiser sur certains périphériques.

Correction : Préférez autotrim pour l’état steady-state ; réservez le trim manuel pour des opérations post-événement (grosses libérations) et exécutez-le avec supervision et bouton d’arrêt.

Mistake 4: Treating TRIM as a cure for a nearly full pool

Symptôme : Autotrim activé, mais les écritures restent lentes et les avertissements d’espace persistent.

Pourquoi cela arrive : À forte utilisation du pool, l’allocation ZFS devient contrainte et l’overprovisioning effectif du SSD disparaît.

Correction : Réduisez l’utilisation (supprimez, déplacez, ajoutez des vdevs), ajustez la rétention des snapshots, et gardez une marge. Pensez « gestion de capacité », pas « commande magique ».

Mistake 5: Using the wrong ashift (and blaming trim)

Symptôme : Amplification d’écriture persistante, mauvaises performances en petits writes, charge d’écriture périphérique élevée.

Pourquoi cela arrive : Un alignement de secteur incorrect force des read-modify-write et du travail interne supplémentaire sur les SSD.

Correction : Définissez ashift=12 (ou plus si approprié) à la création des pools. Vous ne pouvez pas changer ashift en place ; c’est une décision de rebuild/migration. Autotrim ne sauvera pas un pool mal aligné.

Mistake 6: Trusting a RAID controller or expander that eats discard

Symptôme : zpool set autotrim=on montre activé, mais lsblk -D indique pas de discard, et les performances se dégradent toujours.

Pourquoi cela arrive : Certains intermédiaires ne transmettent pas correctement discard/UNMAP.

Correction : Utilisez des HBAs en mode IT pour ZFS, gardez le firmware à jour, et validez le support de discard au niveau OS.

Listes de contrôle / plan pas-à-pas

Plan A: Enabling autotrim safely on an existing production pool

Métriques de référence : capturez zpool iostat -v, iostat -x, et la latence applicative sur une période de charge typique.
Vérifiez le support discard : contrôlez lsblk -D et confirmez que les périphériques sont bien SSD/NVMe sur le chemin attendu.
Vérifiez la marge du pool : assurez-vous que la capacité n’est pas dangereusement élevée et qu’il y a un plan si c’est le cas (changement de rétention, extension).
Vérifiez le churn des snapshots : comptez les snapshots et identifiez les datasets où les suppressions ne libéreront pas d’espace à cause de la rétention.
Activez autotrim : zpool set autotrim=on POOL.
Observez pendant 24–72 heures : surveillez la latence en queue et l’utilisation des périphériques ; cherchez des corrélations avec l’activité de trim.
Décidez d’un trim manuel initial : si le pool a des années de churn et que vous avez activé autotrim tard, lancez zpool trim dans une fenêtre contrôlée.
Documentez et opérationnalisez : incluez « comment arrêter trim » et quelles métriques surveiller dans les runbooks.

Plan B: Ongoing operational hygiene (the boring stuff)

Évitez de maintenir les pools au-dessus de « 80–85% » sauf si vous aimez le roulette des performances.
Révisez les politiques de rétention des snapshots trimestriellement ; liez-les au besoin business, pas à l’habitude.
Suivez les percentiles de latence d’écriture et l’utilisation périphérique, pas seulement le débit.
Maintenez firmware et mises à jour OS sur les nœuds de stockage en tant que workstream prioritaire.
Testez un changement à la fois : autotrim, puis tuning recordsize, puis changements sync/log—jamais tout en même temps.

Plan C: If you suspect autotrim is harming performance

Vérifiez s’il y a un trim manuel en cours : zpool status -t.
Arrêtez le trim comme expérience : zpool trim -s.
Laissez autotrim activé mais évitez les trims manuels ; observez la stabilité.
Si l’autotrim continu est suspecté, mettez autotrim=off et appuyez-vous sur des fenêtres de trim manuel occasionnelles.
Escaladez : vérifiez le firmware, le chemin contrôleur, et envisagez le remplacement du périphérique si la gestion du discard est pathologique.

FAQ

1) Should I enable autotrim on all-SSD ZFS pools?

Dans la plupart des environnements modernes, oui—surtout pour les pools à forte écriture ou à fort churn. Mais faites-le avec de l’observabilité. Si vos périphériques ou contrôleurs gèrent mal discard, autotrim peut augmenter la latence sous charge.

2) What’s the difference between autotrim and `zpool trim`?

Autotrim est continu : il émet des trims au fur et à mesure que de l’espace est libéré. zpool trim est un passage explicite en arrière-plan qui trim les régions libres en masse. Pensez « hygiène continue » vs « nettoyage en profondeur ».

3) Is this the same as `fstrim`?

Non. fstrim opère au niveau du filesystem sur des périphériques bloc traditionnels. ZFS est à la fois gestionnaire de volumes et filesystem ; le trimming ZFS est fait par ZFS lui-même. Lancer fstrim sur un dataset ZFS ne s’applique pas comme sur ext4/xfs.

4) Will autotrim wear out my SSD faster?

Autotrim émet des indices discard ; il n’écrit pas de données utilisateur. Il peut provoquer plus d’effacements de fond à des moments différents, mais l’objectif général est moins d’amplification d’écriture pendant les écritures réelles. L’usure est davantage pilotée par votre workload et l’overprovisioning que par l’existence de TRIM.

5) I enabled autotrim but I don’t see anything happening. Is it broken?

Pas nécessairement. Autotrim se déclenche quand ZFS libère des blocs. Si des snapshots épinglent des blocs, ou si votre workload est principalement append-only avec peu de suppressions/écrasements, il peut y avoir peu à trimmer. Vérifiez aussi le support discard avec lsblk -D.

6) Can autotrim help with read performance?

Indirectement, parfois. Le bénéfice principal est la performance d’écriture soutenue et une latence en queue réduite en diminuant la pression de garbage collection. Les lectures peuvent s’améliorer si le SSD est moins occupé à faire du GC en tâche de fond pendant les opérations de premier plan.

7) Should I enable autotrim on mixed HDD/SSD pools?

Autotrim importe pour les vdevs SSD. Sur les HDD c’est sans objet. Si vous avez des vdevs spéciaux ou un SLOG sur SSD, considérez autotrim pour que ces composants SSD restent sains sous churn metadata/log. Validez le support périphérique et observez.

8) Does TRIM reclaim space inside ZFS?

Non. ZFS suit déjà l’espace. TRIM indique au SSD quels LBAs sont inutilisés pour que le SSD gère mieux la flash. Vos zfs list et zpool list ne changent pas à cause de TRIM ; ils changent à cause des frees.

9) Why does performance still degrade even with autotrim enabled?

Raisons courantes : pool trop plein, rétention de snapshots qui épingle des blocs, choix ashift/volblocksize provoquant une amplification d’écriture, workload sync-heavy sans SLOG approprié, ou discard qui n’atteint pas réellement le disque.

10) What’s the safest rollout strategy?

Activez autotrim sur un pool d’abord, observez au moins une semaine, puis déployez graduellement. Gardez un plan de rollback (désactiver autotrim, arrêter les trims manuels) et un ensemble clair de métriques (percentiles de latence, utilisation périphérique, profondeur de queue).

Conclusion

ZFS autotrim n’est pas un interrupteur magique, mais c’est l’un des rares réglages de production qui peut réellement garder les pools SSD « comme neufs » plus longtemps—surtout sous churn. L’astuce est de le traiter comme tout autre changement qui affecte le timing d’I/O : vérifiez le support discard de bout en bout, déployez avec des métriques, et ne confondez pas « maintenance de fond » avec « performance gratuite ».

Si vous ne retenez qu’une leçon opérationnelle : optimisez pour la prévisibilité. Autotrim échange souvent des pics de latence catastrophiques occasionnels contre un travail de fond doux et gérable. En production, c’est un bon compromis—parce que les systèmes prévisibles ne vous réveillent pas, et ils ne font certainement pas apprendre votre numéro de téléphone à l’équipe base de données.