ZFS zpool iostat -w : Comprendre les schémas de charge en temps réel

octobre 3, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Vous n’avez pas besoin d’un tableau de bord pour savoir que votre stockage est mécontent. Il suffit d’un timeout d’API, d’un fil Slack « pourquoi le déploiement est bloqué ? »,
et d’un dirigeant qui lance « mais hier ça marchait ». ZFS vous donne un sérum de vérité : zpool iostat -w.

Bien utilisé, il vous dit si vous êtes limité par le CPU, par les IOPS, par la latence, par les écritures sync, ou simplement par « l’optimisme ».
Mal utilisé, il vous convainc d’acheter du matériel inutile, de toucher à des réglages que vous ne comprenez pas, et de blâmer « le réseau » par habitude.

Ce que `-w` affiche réellement (et pourquoi cela compte)

zpool iostat est le moniteur du battement cardiaque. L’option -w ajoute la partie que vous souhaiteriez généralement avoir lors d’un incident : la latence.
Pas la latence théorique. Pas la latence du datasheet du vendeur. La latence observée telle que ZFS la voit pour les opérations du pool et des vdev.

Si vous exploitez des systèmes en production, traitez zpool iostat -w comme l’outil « est-ce que le stockage est le goulot maintenant ? ».
Il répond à :

Est-ce qu’on fait la queue ? La latence augmente avant que le débit chute.
Où est la douleur ? Niveau pool vs un vdev lent vs une seule jambe de miroir.
Quel type de douleur ? Lecture, écriture, écritures sync, travail lourd en métadonnées, resilver, trim, ou « petits accès aléatoires partout ».

La latence est la monnaie que dépensent les apps. Le débit, c’est ce dont se vantent les équipes stockage. Quand la facture arrive, les apps règlent en latence.

Ce que `-w` ajoute et ce qu’il n’ajoute pas

Les colonnes exactes varient selon l’implémentation et la version de ZFS (OpenZFS sur Linux vs FreeBSD vs illumos). Mais en gros :

Il ajoute des colonnes de latence (souvent séparées pour lecture et écriture).
Il peut ajouter du temps de queue ou de « wait » selon la plateforme.
Il ne sépare pas magiquement la latence d’intention ZFS de la latence du périphérique sauf si vous le demandez (plus loin).
Il ne vous dit pas pourquoi la latence est élevée ; il vous indique où creuser ensuite.

Une vérité sèche : zpool iostat peut faire apparaître votre système sain alors que votre application est en feu, parce que l’ARC cache vous sauve en silence.
Puis les misses du cache explosent et le même pool s’effondre sous les lectures disque réelles. Vous devez le surveiller en continu, pas seulement quand tout est déjà fichu.

Bref historique et faits qui font sens des sorties

Quelques points de contexte transforment des « colonnes de nombres » en histoire exploitable. Voici neuf faits courts qui comptent vraiment.

ZFS est né chez Sun Microsystems (milieu des années 2000) comme une pile de stockage bout-en-bout : filesystem + gestionnaire de volumes, avec checksums partout.
L’idée de « pool » est l’innovation centrale : les systèmes de fichiers vivent au-dessus d’un pool, et le pool décide où placer les blocs entre les vdevs.
Le Copy-on-write (CoW) explique pourquoi la fragmentation se ressent différemment : ZFS n’écrase pas les blocs en place ; il écrit de nouveaux blocs et met à jour des pointeurs.
Le ZIL n’est pas un cache d’écriture : c’est un journal pour les écritures synchrones. Il existe même sans dispositif SLOG dédié.
SLOG est un dispositif, ZIL est un concept : ajouter un SLOG déplace le ZIL sur un média plus rapide, mais seulement pour les écritures sync.
OpenZFS a unifié plusieurs forks : des fonctionnalités comme le retrait de périphériques, les vdevs spéciaux et le L2ARC persistant sont devenues plus courantes.
Ashift est pour toujours (presque) : mal configuré à la création du pool et vous payez ce coût de performance pour la durée de vie du vdev.
“IOPS” est une demi-vérité sans latence : vous pouvez pousser beaucoup d’IOPS avec une latence catastrophique ; votre base de données vous en voudra quand même.
Resilver et scrub sont des douleurs intentionnelles : ce sont des lectures/écritures de fond qui peuvent dominer zpool iostat si vous les laissez faire.

Une citation sèche, parce que les ingénieurs méritent mieux que des posters motivationnels :
L’espoir n’est pas une stratégie. — idée souvent paraphrasée dans les cercles d’exploitation.

Un modèle mental pour la production : de la requête applicative au vdev

Quand une application effectue des E/S sur ZFS, vous observez plusieurs couches négocier la réalité :

L’app émet des lectures/écritures (souvent petites, souvent aléatoires, et parfois insultantes).
Le système d’exploitation et ZFS agrègent, mettent en cache (ARC) et parfois réordonnent.
ZFS traduit les blocs logiques en écritures physiques à travers les vdevs, en respectant la redondance et les règles d’allocation.
Vos vdevs traduisent cela en commandes réelles au périphérique. Le composant pertinent le plus lent impose le rythme.

Pool vs vdev : pourquoi vos « disques rapides » peuvent rester lents

La performance ZFS est centrée sur le vdev. Un pool est un ensemble de vdevs. Le débit de votre pool évolue avec le nombre de vdevs, pas avec le nombre de disques
comme beaucoup le supposent naïvement.

Les miroirs vous donnent plus d’IOPS par vdev que RAIDZ, et plusieurs miroirs s’additionnent. Les vdevs RAIDZ sont excellents pour l’efficacité de capacité et les lectures séquentielles larges,
mais ils ne se transforment pas magiquement en monstres d’IOPS. Si vous avez construit un énorme vdev RAIDZ2 et attendu du I/O aléatoire de niveau base de données,
vous avez acheté un monospace et l’avez engagé dans une course de dragsters.

La latence est une pile : temps de service + temps d’attente

La façon la plus utile d’interpréter -w est : « le périphérique est-il lent » vs « le périphérique est-il occupé ».
Une latence élevée avec une utilisation modérée signifie souvent que le périphérique lui-même est lent (ou en train de tomber en panne, ou d’effectuer un GC interne).
Une latence élevée avec des IOPS/débit élevés signifie généralement de l’attente en file : la charge dépasse ce que le vdev peut servir à une latence acceptable.

Comment lire les colonnes sans se mentir

Vous verrez des variantes comme :

capacity : utilisé, libre, fragmentation, et parfois espace alloué par pool/vdev.
operations : opérations de lecture/écriture par seconde (IOPS).
bandwidth : octets lus/écrits par seconde (débit).
latency : latence lecture/écriture, parfois découpée en « wait » et « service ».

La règle : vous diagnostiquez avec une combinaison d’IOPS, de débit et de latence. Une seule est une menteuse.

Les lignes au niveau pool sont des moyennes ; les lignes vdev disent la vérité

Les stats du pool peuvent cacher un seul disque malade dans un miroir ou un vdev RAIDZ lent qui traîne tout le monde.
Utilisez toujours -v pour voir la répartition par vdev lors du diagnostic.

Surveillez le changement, pas le chiffre

zpool iostat est mieux utilisé comme une série temporelle. Lancez-le avec un intervalle d’1s ou 2s et observez les tendances.
Le « maintenant » compte plus que les moyennes sur la durée de vie.

Blague n°1 : Les graphiques de stockage sont comme les horoscopes — vagues jusqu’à ce que le pager sonne, puis soudainement ils sont « évidemment prédictifs ».

Mode opératoire de diagnostic rapide

Voici la séquence que j’utilise quand une équipe applicative dit « le stockage est lent » et que vous avez 90 secondes pour décider si c’est vrai.

Première étape : déterminer si vous regardez le disque ou le cache

Exécutez zpool iostat -w avec des intervalles d’1s pendant 10–20 secondes.
Si les IOPS et le débit de lecture sont faibles mais que l’app est lente, suspectez le CPU, des verrous, le réseau, ou des misses de cache pas encore arrivés au disque.
Si les IOPS de lecture explosent et que la latence suit, vous êtes sur les disques. Là, c’est réel.

Deuxième étape : isoler la couche goulot

Utilisez zpool iostat -w -v. Trouvez le vdev avec la pire latence ou les symptômes d’utilisation les plus élevés.
Si c’est un disque dans un miroir : probablement défaillant, firmware étrange, ou problème de chemin.
Si c’est un vdev RAIDZ entier : vous saturez les IOPS de ce vdev. La correction est architecturale (plus de vdevs, miroirs, ou accepter la latence).

Troisième étape : décider si c’est de la douleur d’écriture sync

Recherchez des pics de latence d’écriture corrélés à des IOPS d’écriture faibles en débit.
Vérifiez si la charge force des écritures sync (bases de données, NFS, hyperviseurs).
Si oui : examinez la santé du SLOG et la latence du périphérique ; considérez si vos réglages sync sont corrects selon votre tolérance au risque.

Quatrième étape : vérifier les « jobs de fond qui se prennent pour du trafic »

Les scrubs, resilvers, trims et snapshots/clones lourds peuvent dominer les E/S.
Si zpool status indique un travail actif, décidez de le throttler, le programmer ou le laisser finir.

Cinquième étape : confirmer avec un second signal

Corrélez avec le CPU (mpstat), la pression mémoire, ou l’I/O par processus (pidstat).
Utilisez des outils de niveau périphérique (iostat -x) pour voir si un NVMe fond pendant que ZFS moyenne tout.

Tâches pratiques : commandes, sens, décisions

Vous avez demandé des tâches concrètes, pas des impressions. En voici quatorze. Chacune inclut une commande, un extrait d’exemple, ce que cela signifie, et la décision qu’elle entraîne.
Les sorties sont représentatives ; vos colonnes peuvent différer selon la plateforme/version.

Task 1: Baseline pool latency in real time

cr0x@server:~$ sudo zpool iostat -w tank 1
              capacity     operations     bandwidth    latency
pool        alloc   free   read  write   read  write   read  write
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank        3.21T  7.58T    210    180  18.2M  22.4M   2ms   4ms
tank        3.21T  7.58T    195    260  16.9M  31.1M   3ms  18ms
tank        3.21T  7.58T    220    240  19.1M  29.7M   2ms  20ms

Sens : Les écritures ont vu la latence passer de 4ms à ~20ms pendant que le débit augmentait. C’est un classique « on pousse le chemin d’écriture ».

Décision : Si cela s’aligne avec la latence visible par l’utilisateur, considérez le stockage comme suspect. Ensuite : ajoutez -v pour trouver le vdev responsable.

Task 2: Find the vdev that’s hurting you

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                  220    240  19.1M  29.7M   2ms  20ms
tank        mirror-0                           110    120   9.5M  14.6M   2ms  10ms
tank          nvme0n1                          108    118   9.4M  14.4M   2ms  12ms
tank          nvme1n1                          112    119   9.6M  14.7M   2ms  65ms
tank        mirror-1                           110    120   9.6M  15.1M   2ms  10ms
tank          nvme2n1                          110    118   9.5M  14.8M   2ms  11ms
tank          nvme3n1                          110    121   9.7M  15.3M   2ms  10ms

Sens : Une jambe de miroir (nvme1n1) affiche 65ms de latence d’écriture alors que son partenaire est correct. ZFS peut lire sur un miroir, mais les écritures attendent les deux jambes.

Décision : C’est un problème de périphérique/chemin. Vérifiez SMART, le firmware, les erreurs PCIe, le multipath et la vitesse du lien. Remplacez ou réparez le chemin avant de tuner ZFS.

Task 3: Separate “busy” from “broken” at the device layer

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

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         110.0   120.0     9.5    14.4     197.0      0.4     3.1      2.0      4.2    0.4   18.0
nvme1n1         112.0   119.0     9.6    14.7     198.2      9.8    66.7      2.2     65.8    0.5   95.0

Sens : nvme1n1 est à forte utilisation avec une file profonde et un attend d’écriture énorme. Ce n’est pas ZFS qui est « bavard » ; c’est un périphérique malade ou étranglé.

Décision : Arrêtez de blâmer le recordsize. Inspectez la santé du périphérique et le throttling (thermique, GC du firmware). Si c’est un lane PCIe partagé, corrigez la topologie.

Task 4: Detect a sync-write workload quickly

cr0x@server:~$ sudo zpool iostat -w tank 1
              operations     bandwidth    latency
pool        read  write   read  write   read  write
----------  ----  -----  -----  -----  -----  -----
tank          80   3200   6.1M  11.8M   1ms  35ms
tank          75   3500   5.9M  12.4M   1ms  42ms

Sens : Très hautes IOPS d’écriture mais faible bande passante d’écriture indique des petites écritures. La latence est élevée. Si l’app est une base de données, un hôte VM ou un serveur NFS, supposez une pression sync.

Décision : Vérifiez le SLOG et les réglages sync. Si vous n’avez pas de SLOG et que vous avez besoin de sync sûr, acceptez que les disques rotatifs souffrent.

Task 5: Verify whether datasets are forcing sync behavior

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received sync tank
NAME   PROPERTY  VALUE
tank   sync      standard

Sens : Le pool/les datasets utilisent la sémantique par défaut : honorer les requêtes sync de l’app.

Décision : Si la latence vous tue et que vous pouvez accepter le risque pour un dataset spécifique (pas tout le pool), envisagez sync=disabled seulement pour ce dataset.
Si vous ne pouvez pas expliquer le risque à un auditeur sans transpirer, n’en faites rien.

Task 6: Check if you even have a SLOG and whether it’s healthy

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
            nvme0n1   ONLINE       0     0     0
            nvme1n1   ONLINE       0     0     0
          mirror-1    ONLINE       0     0     0
            nvme2n1   ONLINE       0     0     0
            nvme3n1   ONLINE       0     0     0
        logs
          mirror-2    ONLINE       0     0     0
            nvme4n1   ONLINE       0     0     0
            nvme5n1   ONLINE       0     0     0

Sens : Un SLOG en miroir existe. Bien : un SLOG mono-périphérique est une arme à feu si vous tenez à la durabilité.

Décision : Si les écritures sync sont lentes, mesurez la latence du périphérique SLOG séparément et envisagez de remplacer par un NVMe avec protection contre perte d’alimentation.

Task 7: Measure per-vdev behavior during a scrub or resilver

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 25 10:11:03 2025
        1.23T scanned at 1.1G/s, 512G issued at 450M/s, 3.21T total
        0B repaired, 15.9% done, 01:42:18 to go

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                 6200    180  1.05G  22.4M  12ms   4ms
tank        mirror-0                          3100     90  525M  11.2M  13ms   4ms
tank        mirror-1                          3100     90  525M  11.2M  12ms   4ms

Sens : Les lectures sont dominées par le scrub. La latence est élevée mais explicable. Les écritures semblent normales.

Décision : Si c’est une fenêtre de production chargée, throttlez le scrub (selon la plateforme) ou replanifiez. Si la latence de lecture casse vos SLOs, le timing du scrub devient un problème SRE, pas stockage.

Task 8: Identify a single slow disk in a mirror without guessing

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        mirror-0                           800    900  65M   72M     3ms  14ms
tank          sda                              400    450  32M   36M     2ms   6ms
tank          sdb                              400    450  33M   36M     3ms  80ms

Sens : sdb est l’ancre qui ralentit le bateau. Les miroirs écrivent sur les deux côtés ; une jambe lente empoisonne la latence d’écriture.

Décision : Récupérez les données SMART, vérifiez le câblage/HBA, et planifiez le remplacement. Ne « touchez pas » au tunning pour contourner un disque mourant.

Task 9: Confirm ashift and why it matters

cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n
45:        ashift: 12

Sens : ashift=12 (secteurs 4K). C’est généralement sensé pour les disques modernes et les SSD. Si vous voyez ashift=9 sur du média natif 4K, vous payez une taxe d’amplification d’écriture pour toujours.

Décision : Si ashift est incorrect, vous ne le « corrigez pas avec un sysctl ». Vous migrez vers un nouveau vdev/pool avec ashift correct.

Task 10: Detect metadata-heavy pain and consider a special vdev

cr0x@server:~$ sudo zpool iostat -w -v tank 1
                                            operations     bandwidth    latency
pool        vdev                             read  write   read  write   read  write
----------  -------------------------------- ----  -----  -----  -----  -----  -----
tank        -                                 5200   2100  48M   39M    18ms  22ms
tank        raidz2-0                           5200   2100  48M   39M    18ms  22ms

Sens : Des IOPS énormes avec un faible débit signent un travail metadata ou petits blocs aléatoires (parcours de répertoires, petits fichiers, maildirs, couches de conteneur).
RAIDZ n’apprécie pas.

Décision : Envisagez d’ajouter des miroirs, d’ajouter plus de vdevs, ou d’utiliser un vdev spécial pour les métadonnées/petits blocs si votre plateforme le supporte et si vous pouvez l’opérationnaliser en sécurité.

Task 11: Verify dataset recordsize vs workload (and avoid self-inflicted pain)

cr0x@server:~$ sudo zfs get -o name,property,value recordsize tank/db
NAME     PROPERTY    VALUE
tank/db  recordsize  128K

Sens : recordsize 128K convient aux I/O séquentiels larges, mais beaucoup de bases préfèrent plus petit (comme 16K) selon le moteur et la taille de page.

Décision : Si votre charge est aléatoire de petites pages et que vous voyez de l’amplification de lecture, testez un recordsize plus petit pour ce dataset.
Ne changez pas le recordsize aveuglément pour un dataset existant en espérant des miracles instantanés ; les blocs existants restent tels quels.

Task 12: Check compression and learn whether you’re CPU-bound

cr0x@server:~$ sudo zfs get -o name,property,value compression,compressratio tank/vm
NAME      PROPERTY       VALUE
tank/vm   compression    zstd
tank/vm   compressratio  1.62x

cr0x@server:~$ mpstat 1 3
Linux 6.5.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:11:01 AM  all   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:11:02 AM  all   72.0    0.0   11.0     2.0   0.0    0.0     0.0   15.0

Sens : La compression est en action et efficace. Le CPU est assez occupé. Si zpool iostat montre une faible activité disque mais que l’app a de la latence, le CPU peut être le facteur limitant.

Décision : Si la saturation CPU corrèle avec la latence I/O, pensez à changer le niveau de compression (gardez la compression), ajouter du CPU, ou isoler des voisins bruyants.
Ne désactivez pas la compression comme premier réflexe ; elle réduit souvent l’I/O disque.

Task 13: Spot TRIM/autotrim impact and decide when to run it

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

cr0x@server:~$ sudo zpool iostat -w tank 1
              operations     bandwidth    latency
pool        read  write   read  write   read  write
----------  ----  -----  -----  -----  -----  -----
tank         180    220  12.4M  19.1M   2ms   6ms
tank         175    240  12.2M  19.8M   3ms  18ms

Sens : Si vous voyez des pics périodiques de latence d’écriture sans changement de charge correspondant, la maintenance de fond (y compris TRIM sur certains périphériques) peut en être la cause.

Décision : Si autotrim provoque des jitter visibles sur des systèmes sensibles à la latence, testez la désactivation d’autotrim et planifiez des trims manuels en heures creuses. Mesurez, n’improvisez pas.

Task 14: Correlate “who is doing the I/O” with pool symptoms

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.0 (server)  12/25/2025  _x86_64_  (32 CPU)

12:12:01 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
12:12:02 AM     0      2211      120.0   82000.0      0.0       1  postgres
12:12:02 AM     0      3440      200.0   14000.0      0.0       0  qemu-system-x86

Sens : Postgres martèle des écritures. Si zpool iostat -w montre une forte latence d’écriture, vous pouvez alors avoir une conversation productive avec le propriétaire de la base.

Décision : Déterminez s’il s’agit d’une augmentation légitime de la charge (scaler le stockage), d’une app mal configurée (boucle fsync), ou d’un job opérationnel (vacuum, reindex) à planifier.

Reconnaître les patrons de charge en production

Le but de zpool iostat -w est de reconnaître les patrons assez vite pour agir. Voici les cas courants qui apparaissent en conditions réelles.

Pattern: small random writes, high IOPS, low bandwidth, high latency

Ressemble à : des milliers d’opérations d’écriture, quelques Mo/s, latence d’écriture de plusieurs dizaines de millisecondes ou pire.

Généralement : pression WAL/fsync de base de données, journaling VM, écritures NFS sync, workloads lourds en logs.

Que faire :

Confirmer si les écritures sont synchrones (dataset sync et comportement applicatif).
Assurer la présence d’un SLOG rapide et protégé contre la perte d’alimentation si vous tenez à la durabilité.
Ne mettez pas un SSD grand public comme SLOG et appelez ça un gain. C’est ainsi qu’on achète une perte de données avec une facture.

Pattern: high read bandwidth, moderate IOPS, rising read latency

Ressemble à : centaines de Mo/s à Go/s en lectures, latence qui passe de quelques ms à des dizaines de ms.

Généralement : lectures massives lors de sauvegarde, analyses, scrubs, ou tempête de misses du cache.

Que faire :

Vérifiez l’état du scrub/resilver.
Vérifiez le ratio de hit ARC indirectement en regardant si les lectures atteignent le disque (associez avec des stats ARC si disponibles).
Si c’est du trafic utilisateur réel, vous aurez peut-être besoin de plus de vdevs ou de médias plus rapides. La latence ne négocie pas.

Pattern: one vdev shows high latency; pool average looks “okay”

Ressemble à : la ligne pool de zpool iostat -w paraît correcte ; -v montre un miroir ou disque avec une latence 10–100x.

Généralement : disque en train de lâcher, mauvais câble, tempêtes de reset HBA, throttling thermique, ou bug de firmware.

Que faire : Traitez-le comme du matériel jusqu’à preuve du contraire. Remplacez. Ne passez pas une semaine à rédiger une proposition de tuning autour d’un disque qui meurt en silence.

Pattern: latency spikes at steady throughput

Ressemble à : même Mo/s et IOPS, mais la latence monte périodiquement en flèche.

Généralement : GC du périphérique, TRIM, flushs du write cache, ou contention sur des ressources partagées (lanes PCIe, HBA, hôte virtualisé).

Que faire : Corrélez avec des métriques périphériques et les logs système. Si c’est du throttling thermique NVMe, votre « correctif » peut être l’airflow, pas le logiciel.

Blague n°2 : Si vos « pics de latence sont aléatoires », félicitations — vous avez construit une distribution de probabilité en production.

Trois mini-histoires d’entreprise (parce que la réalité est cruelle)

Mini-story #1: The incident caused by a wrong assumption

Une entreprise SaaS de taille moyenne a migré un cluster Postgres chargé d’un SAN vieillissant vers des NVMe locaux en miroirs ZFS. L’équipe a célébré :
les benchmarks semblaient excellents, la latence moyenne était faible, et les graphes de stockage arrêtaient enfin de ressembler à une scène de crime.

Deux semaines plus tard, un incident : des blocages périodiques de 2–5 secondes sur des endpoints lourds en écritures. Pas constants. Pas prévisibles.
L’équipe applicative accusait les verrous. Les DBA blâmaient autovacuum. Les SRE parlaient « peut-être le noyau ».
Chacun avait son méchant préféré et aucun n’était les disques.

Quelqu’un a finalement lancé zpool iostat -w -v 1 pendant un blocage. Les moyennes pool étaient correctes, mais un NVMe montrait une latence d’écriture de centaines de millisecondes.
Ce n’était pas une défaillance franche. C’était un throttling intermittent.

L’hypothèse erronée : « NVMe est toujours rapide, et si c’est lent ça doit être ZFS. » La réalité : les NVMe grand public peuvent atteindre des limites thermiques et chuter fortement
sous des patterns d’écriture soutenue de type sync. La machine avait un excellent CPU et un refroidissement lamentable.

Le correctif fut délicieusement ennuyeux : améliorer le refroidissement, mettre à jour le firmware, et remplacer ce modèle par des pièces enterprise lors du prochain cycle de maintenance.
Tuner ZFS n’aurait rien fait. Observer la latence par périphérique avec -w -v a résolu le mystère.

Mini-story #2: The optimization that backfired

Une équipe plateforme a géré un cluster de virtualisation multi-tenant reposant sur un grand pool RAIDZ2. Sous pression : les dev voulaient un CI plus rapide,
et le stockage était « ce dont tout le monde se plaint ».

Quelqu’un a proposé un raccourci : mettre sync=disabled sur le dataset VM. L’argument était séduisant : « On a des onduleurs. L’hyperviseur récupère.
Et ce ne sont que des environnements dev. » Ils l’ont changé tard un après-midi et ont vu la latence d’écriture baisser. High-fives.

Puis l’effet boomerang. Un hôte a planté d’une manière que l’UPS n’a pas évitée (c’était un souci de carte mère, pas une panne de courant).
Quelques VMs ont eu une corruption de système de fichiers. Pas toutes. Juste assez pour gâcher un weekend et rendre le postmortem épicé.

L’erreur opérationnelle n’était pas « sync=disabled est toujours mauvais ». L’erreur était de traiter les sémantiques de durabilité comme un bouton de performance sans modéliser le blast-radius.
Ils ont optimisé pour le cas médian et payé le risque de queue.

Le correctif à long terme : réactiver sync=standard, ajouter un SLOG miroir protégé contre perte d’alimentation, et segmenter « vrai dev » et « pseudo prod »
pour que la décision de durabilité corresponde à la réalité métier. La leçon : zpool iostat -w peut montrer que les écritures sync coûtent,
mais il ne vous donne pas le droit de les désactiver.

Mini-story #3: The boring but correct practice that saved the day

Une entreprise liée à la finance utilisait ZFS pour des services de fichiers et des artefacts de build. Rien de fancy. Le stockage qui passe inaperçu jusqu’à panne.
L’ingénieur stockage avait une habitude : un « drill de cinq minutes » hebdomadaire pendant les heures ouvrables.
Lancer zpool iostat -w -v 1 pendant une minute, regarder les latences, vérifier zpool status, et passer à autre chose.

Un mardi, le drill montra une jambe de miroir avec une latence d’écriture qui montait progressivement. Pas d’erreurs encore. Pas d’alertes. Le système était « correct ».
Mais la tendance de latence était mauvaise, comme un bruit de boîte de vitesses avant qu’elle n’explose.

Ils ont relevé les données SMART et trouvé des erreurs média en hausse. Le disque n’était pas mort ; il commençait à mentir.
Ils ont planifié le remplacement à la prochaine fenêtre, résilverisé et n’ont jamais eu d’incident.

Des semaines plus tard, un disque du même modèle dans une autre flotte a lâché brutalement et causé un incident visible. Même vendeur, même batch, même mode de défaillance.
Leur équipe a été sauvée purement parce que quelqu’un regardait -w et faisait confiance à la dérive lente.

La pratique ennuyeuse n’était pas de l’héroïsme. C’était reconnaître que les disques ne passent rarement de « parfait » à « mort » sans une phase « bizarre ».
zpool iostat -w est excellent pour attraper le bizarre.

Erreurs courantes : symptôme → cause racine → correction

Voici les modes d’échec que je vois dans les organisations réelles. L’astuce est de mapper le symptôme dans zpool iostat -w à la cause probable,
puis d’appliquer un changement spécifique qui peut être validé.

1) Pool write latency is high, but only one mirror leg is slow

Symptôme : La latence d’écriture du pool monte ; -v montre un périphérique avec une latence d’écriture beaucoup plus élevée.
Cause racine : Throttling du périphérique, GC firmware, problème thermique, lien défectueux, ou disque en défaillance.
Correction : Vérifiez avec iostat -x et les logs ; remplacez le périphérique ou réparez le chemin. Ne perdez pas de temps à tuner recordsize ou ARC.

2) High write IOPS, low write bandwidth, ugly write latency

Symptôme : Des milliers d’écritures/s, quelques Mo/s seulement, latence d’écriture de dizaines de ms à secondes.
Cause racine : Écritures sync sans SLOG rapide, ou SLOG lent.
Correction : Ajouter/remplacer un SLOG miroir PLP ; confirmer le comportement sync de l’app ; isoler les datasets et régler les sémantiques sync intentionnellement.

3) Reads look fine until ARC misses spike, then everything melts

Symptôme : Normalement faibles lectures disque ; pendant les incidents, IOPS/débit de lecture explosent et la latence de lecture monte.
Cause racine : Working set qui dépasse l’ARC, ou changement de pattern d’accès (scan, job de rapport, sauvegarde, nouvelle fonctionnalité).
Correction : Ajouter de la RAM (souvent le meilleur ROI), repenser la stratégie de cache, ou isoler les workloads de scan. Validez en observant les changements de lecture dans zpool iostat -w.

4) RAIDZ vdev saturates on metadata/small random I/O

Symptôme : IOPS élevés, faible Mo/s, latence élevée ; le vdev est RAIDZ.
Cause racine : Surcharge due à l’overhead de parité RAIDZ et IOPS limités par vdev pour petits écrits aléatoires.
Correction : Ajouter plus de vdevs (pas plus de disques au même vdev), ou passer à des miroirs pour les workloads sensibles à la latence. Envisager un vdev spécial pour les métadonnées si approprié.

5) “We upgraded disks but it’s still slow”

Symptôme : Nouveaux SSD, latence similaire sous charge.
Cause racine : Vous êtes limité par le CPU (compression/checksum), ou limité par la topologie d’un seul vdev, ou contraint par PCIe/HBA.
Correction : Confirmez avec métriques CPU et stats par vdev ; scalez le nombre de vdevs, corrigez la topologie, ou migrez les datasets chauds vers un pool séparé.

6) Latency spikes during scrubs/resilver and users complain

Symptôme : La latence de lecture augmente fortement quand la maintenance tourne.
Cause racine : Scrub/resilver en compétition avec le workload de production.
Correction : Planifiez la maintenance en heures creuses, throttlez si possible, ou provisionnez suffisamment de marge pour que les checks d’intégrité ne deviennent pas une panne.

Checklists / plan étape par étape

Checklist: responding to “storage is slow” in under five minutes

Exécutez sudo zpool iostat -w -v tank 1 et regardez 10–20 lignes.
Identifiez si ce sont les lectures ou écritures qui dominent, et si la latence monte avec la charge.
Si un périphérique se démarque, basculez sur iostat -x et les logs système pour ce périphérique.
Vérifiez sudo zpool status tank pour scrub/resilver.
Vérifiez les réglages sync du dataset concerné.
Corrélez avec l’I/O par processus (pidstat -d) pour ne pas déboguer des fantômes.
Faites un changement à la fois ; confirmez l’impact avec la même vue zpool iostat -w.

Checklist: building a baseline before you touch anything

Capturez zpool iostat -w -v 2 30 pendant une période connue comme saine.
Capturez la même chose pendant le pic de trafic.
Enregistrez les sorties horodatées dans votre carnet d’incident ou ticket.
Notez la topologie du pool : types de vdev, modèles de disques, ashift.
Notez les propriétés des datasets : recordsize, compression, sync, atime.
Décidez ce que « mauvais » signifie (seuils de latence alignés sur vos SLO applicatifs).

Step-by-step plan: turning observations into an improvement project

Classifiez la charge : aléatoire vs séquentielle, lecture vs écriture, sync vs async, métadonnées vs grands blocs.
Mappez à la topologie ZFS : déterminez si le design vdev correspond à la charge.
Corrigez la correction d’abord : remplacez les périphériques défaillants, corrigez câblage/HBA, assurez la redondance pour SLOG/vdev spécial.
Réduisez l’I/O évitable : activez une compression sensée, ajustez recordsize par dataset, envisagez atime=off quand approprié.
Scalez correctement : ajoutez des vdevs pour scaler les IOPS ; n’augmentez pas sans cesse un seul vdev RAIDZ en espérant des miracles.
Validez avec -w : vous voulez moins de latence à la même charge, pas seulement de beaux chiffres de débit.
Opérationnalisez : ajoutez des contrôles routiniers et des alertes sur anomalies de latence par vdev, pas seulement sur la capacité.

FAQ

1) What does `zpool iostat -w` actually measure for latency?

Il rapporte la latence observée pour les I/O ZFS au niveau pool/vdev, telle que comptabilisée par ZFS. Ce n’est pas un substitut parfait des métriques firmware du périphérique,
mais c’est extrêmement utile pour montrer où le temps est dépensé et si du queueing se produit.

2) Why does pool latency look fine, but my database is still slow?

Parce que les disques peuvent ne pas être le goulot. Vous pouvez être limité par le CPU (compression, checksumming), par des verrous, ou par le comportement fsync applicatif.
De plus, l’ARC peut masquer les lectures disque jusqu’à ce que les misses explosent. Corrélez avec le CPU et l’I/O par processus.

3) Should I always run with `-v`?

Pour le diagnostic, oui. Les moyennes pool cachent les périphériques lents et la charge inégale des vdevs. Pour un échantillonnage rapide sur un système chargé, commencez sans -v puis pivotez.

4) Does adding more disks to a RAIDZ vdev increase IOPS?

Pas comme la plupart l’attendent. Cela peut augmenter le débit séquentiel, mais le petit I/O aléatoire est limité par l’overhead de parité et le comportement du vdev.
Si vous avez besoin de plus d’IOPS, ajoutez des vdevs ou utilisez des miroirs pour les données chaudes.

5) When is a SLOG worth it?

Quand vous avez une charge d’écritures synchrones significative et que vous tenez aux sémantiques de durabilité (sync=standard).
Sans pression sync, un SLOG ne fait souvent rien de mesurable. Avec pression sync, il peut être la différence entre « ça marche » et « pourquoi tout timeoute ? ».

6) Can I use a consumer SSD as a SLOG?

Vous pouvez, mais vous ne devriez probablement pas si vous tenez à la correction. Un bon SLOG nécessite une faible latence sous écritures sync soutenues et une protection contre la perte d’alimentation.
Les SSD bon marché peuvent mentir sur les flushes et chuter en performance sous la charge exactement pour laquelle vous les avez achetés.

7) Why do I see high latency during scrub, even when user traffic is low?

Les scrubs lisent beaucoup de données et peuvent pousser les files d’attente des vdevs. Même avec peu de trafic applicatif, le scrub est un I/O réel.
La solution : planification, throttling (si supporté), ou provisionner suffisamment de marge.

8) Is `sync=disabled` ever acceptable?

Seulement si vous avez une décision de risque claire et pouvez tolérer la perte des dernières secondes d’écritures en cas de crash ou coupure, potentiellement avec de la corruption applicative.
Si le dataset contient quelque chose que vous qualifieriez d’« important » dans un postmortem, n’en faites rien. Utilisez un SLOG approprié.

9) Why does write latency increase even when write bandwidth is constant?

Parce que le queueing et le comportement interne du périphérique comptent. Un débit constant peut quand même accumuler un retard si le temps de service du périphérique augmente à cause du garbage collection,
du throttling thermique, de flushs de cache d’écriture, ou de contention.

10) How long should I sample with `zpool iostat -w`?

Pour le triage d’incident, 10–30 secondes à des intervalles d’1s suffisent généralement pour repérer le goulot. Pour la planification de capacité ou le travail de performance, capturez plusieurs fenêtres :
idle, pic, et « jour mauvais ».

Conclusion : prochaines étapes qui font réellement la différence

zpool iostat -w n’est pas un outil de reporting. C’est un moteur de décision. Il vous dit si vous avez un problème de périphérique, de topologie, d’écritures sync,
ou un problème « la maintenance de fond me mange » — pendant que le système est vivant et dysfonctionne.

Prochaines étapes pratiques :

Pendant une période calme, capturez une baseline : sudo zpool iostat -w -v tank 2 30.
Notez à quoi ressemble la latence « normale » par vdev et par fenêtre de charge.
Quand la prochaine plainte arrive, suivez le mode opératoire de diagnostic rapide et résistez à l’envie de tuner en premier.
Si vous découvrez un patron répété (pression d’écritures sync, un périphérique lent, douleur RAIDZ metadata), transformez-le en projet d’ingénierie avec résultats mesurables.

Votre futur vous n’a pas besoin de plus de graphiques. Votre futur vous a besoin de moins de surprises. -w est la façon de commencer à facturer les intérêts du chaos.