ZFS zpool iostat -v : repérer le disque qui ruine la latence

Le modèle mental : les performances ZFS se mesurent par vdev, pas par pool

Commencez ici, car cela change la façon dont vous lisez chaque graphique et chaque compte rendu d’incident.
Un pool ZFS est une collection de vdevs. Les données sont stripées entre les vdevs, mais chaque bloc vit sur un vdev spécifique.
Si un vdev devient lent, toute charge qui touche des blocs sur ce vdev en souffre.
Si le vdev est un miroir et qu’un côté est lent, ZFS peut parfois contourner ce côté pour les lectures — jusqu’à ce que ce ne soit plus possible (ou pendant les écritures,
ou un resilver, ou si votre charge est très synchrone).

Il y a aussi une vérité plus agaçante : ZFS est très doué pour transformer de petites misères intermittentes de périphérique en latence de queue pour tout le système.
Il fait cela parce que ZFS est cohérent : il attend le stockage qu’il a demandé. Votre appli se fiche que 99,9 % des E/S soient correctes ;
elle se souvient des 0,1 % qui ont pris 2 secondes parce qu’un disque a décidé d’exécuter sa maintenance interne au pire moment.

Donc l’objectif de zpool iostat -v n’est pas « mesurer le pool ». C’est « trouver le vdev ou le disque qui raconte une histoire différente des autres ».
Vous ne chassez pas les moyennes basses ; vous chassez les valeurs aberrantes, les pics, la croissance des files d’attente et l’asymétrie.

Faits rapides et historique qui aident vraiment au debugging

• ZFS a été conçu autour des sommes de contrôle de bout en bout. C’est excellent pour l’intégrité, mais cela signifie aussi que ZFS va exposer bruyamment les périphériques défaillants en faisant des retries, des réparations et en journalisant les erreurs plutôt que de renvoyer silencieusement des données corrompues.
• RAIDZ n’est pas « RAID matériel en logiciel ». Les calculs de parité et le comportement d’allocation de RAIDZ rendent les petites écritures aléatoires plus complexes que les mirrors, ce qui compte quand un seul disque ralentit.
• « Le disque le plus lent ruine le vdev » est plus vieux que ZFS. Les RAIDs classiques ont toujours été limités par leur membre le plus lent ; ZFS vous donne juste de meilleurs outils pour le prouver.
• La réalité des secteurs 4K a tout changé. ashift existe parce que les disques ont longtemps menti (ou partiellement menti) sur la taille des secteurs ; un mauvais alignement peut amplifier les I/O et la latence.
• Scrub est une fonctionnalité, pas une punition. ZFS scrute tout intentionnellement ; le but est de trouver les erreurs latentes avant qu’un resilver ne vous enseigne la leçon à la dure.
• ZFS peut choisir différents côtés d’un miroir pour les lectures. Cela peut masquer un disque lent sur les lectures alors que les écritures souffrent toujours, ce qui conduit à des incidents déroutants où « les lectures vont bien, les écritures sont horribles ».
• SLOG n’est pas un cache d’écriture. Un dispositif de log séparé accélère uniquement les écritures synchrones ; il ne résoudra pas la latence des écritures asynchrones ni des membres lents du pool.
• L’iostat d’OpenZFS est devenu utile avec le temps. Les anciennes implémentations étaient plus maigres ; OpenZFS moderne expose plus de comportements par vdev, et sur certaines plates-formes vous pouvez obtenir des histogrammes de latence via d’autres outils.
• Les SSD peuvent être « sains » et quand même se bloquer. Le GC du firmware et le throttling thermique peuvent créer des pics de latence sans échecs SMART évidents — jusqu’à ce que vous corréliez iostat et températures.

Ce que zpool iostat -v montre vraiment (et ce qu’il masque)

La commande que vous utiliserez réellement

L’outil de base est :
zpool iostat -v avec un intervalle et éventuellement un nombre de répétitions.
Sans intervalle, vous obtenez des moyennes depuis le démarrage/import — utile pour la planification de capacité, catastrophique pour les incidents.
Avec un intervalle, vous obtenez des deltas par intervalle. C’est là que se trouve la vérité.

Variantes courantes :

• zpool iostat -v 1 pour une surveillance en temps réel
• zpool iostat -v 5 12 pour un instantané d’une minute
• zpool iostat -v -y 1 pour supprimer la première ligne « depuis le boot », qui distrait souvent en salle de crise
• zpool iostat -v -p pour des octets exacts (pas d’humanisation), ce qui compte quand vous examinez de petits deltas

Ce que signifient les colonnes (et ce que vous devez en déduire)

Selon votre plate-forme/version d’OpenZFS, vous verrez des colonnes comme capacity, operations, bandwidth.
La sortie typique montre les ops de lecture/écriture et la bande passante lecture/écriture au niveau du pool, du vdev et des périphériques feuilles.
C’est suffisant pour attraper de nombreux tueurs de latence parce que la latence se manifeste généralement par une baisse des ops plus une distribution inégale plus un périphérique qui fait moins de travail (ou étrangement plus).

Ce que vous ne verrez souvent pas directement, ce sont les millisecondes de latence. Certaines plates-formes l’exposent via des modes iostat étendus ou d’autres outils,
mais même sans colonnes de latence explicites vous pouvez diagnostiquer : quand la charge est stable, un périphérique lent apparaît comme une chute de ses ops/bande passante comparé à ses pairs,
plus une charge accrue ailleurs, plus des blocages visibles par les utilisateurs.

La discipline : ne fixez pas votre regard sur les totaux du pool. Les totaux du pool peuvent sembler « corrects » alors qu’un disque provoque en silence de la latence de queue en se bloquant par intermittence.
Développez toujours jusqu’au vdev et au disque.

Blague #1 : Si le stockage était un sport d’équipe, le disque lent serait celui qui insiste pour « juste une chose rapide de plus » avant chaque passe.

Playbook de diagnostic rapide (première/deuxième/troisième étapes)

Première étape : confirmez que c’est la latence stockage, pas CPU, réseau ou mémoire

Si le système swappe, ou si votre NIC perd des paquets, ou si le CPU est saturé par la compression, le stockage sera quand même blâmé.
Faites un contrôle de 60 secondes :

• Moyenne de charge vs utilisation CPU
• Activité de swap
• Erreurs réseau
• Taille de l’arc ZFS et évictions

Mais n’en faites pas trop : si la latence de votre appli se corrèle avec un pic du pool, continuez l’investigation.

Deuxième étape : lancez zpool iostat -v avec un intervalle et surveillez l’asymétrie

Exécutez zpool iostat -v -y 1 pendant l’incident. Vous cherchez :

• Un périphérique feuille avec beaucoup moins d’ops que ses pairs (ou des intervalles périodiques à zéro)
• Un périphérique avec une bande passante étrange comparée aux autres (amplification de lecture, retries, trafic de reconstruction)
• Un vdev unique qui tire les ops du pool vers le bas (commun avec RAIDZ sous I/O aléatoire)

Troisième étape : corroborer avec la télémétrie de santé et les erreurs

Une fois que vous avez un disque suspect, validez-le :

• zpool status -v pour les erreurs, l’activité de resilver/scrub
• smartctl pour les erreurs média, les erreurs CRC, la température et les patterns de timeout
• iostat / nvme pour l’utilisation périphérique et la latence (selon la plate-forme)

Le point de décision est généralement l’un de ceux-ci :

• Mettre hors ligne / remplacer un disque défaillant
• Corriger un chemin/câble/contrôleur (erreurs CRC, réinitialisations de lien)
• Arrêter une « optimisation » qui génère des I/O destructeurs (mauvais recordsize, utilisation abusive de sync, timing de scrub pathologique)
• Rééquilibrer ou repenser la disposition des vdevs si vous l’avez dépassée (largeur RAIDZ, mirrors, vdev spécial)

Tâches pratiques : commandes, signification des sorties, décisions

Voici les actions à faire sur un système en production. Chacune indique ce que vous regardez et quelle décision elle entraîne.
Utilisez un intervalle. Utilisez -y. Et arrêtez de coller des moyennes depuis le démarrage dans les canaux d’incident comme si elles signifiaient quelque chose.

Tâche 1 : Obtenir une vue propre et temps réel par disque

cr0x@server:~$ zpool iostat -v -y 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        7.12T  3.80T    980    420   120M  38.0M
  raidz2-0  7.12T  3.80T    980    420   120M  38.0M
    sda         -      -    170     70  21.0M  6.2M
    sdb         -      -    165     71  20.8M  6.4M
    sdc         -      -    168     69  20.9M  6.1M
    sdd         -      -     20    180   2.0M  19.3M
    sde         -      -    170     71  21.1M  6.3M
    sdf         -      -    167     70  20.7M  6.2M

Signification : Un disque (sdd) effectue beaucoup moins de lectures et beaucoup plus d’écritures que ses pairs ; le motif est asymétrique.
Cela peut être un réel biais de charge, mais en RAIDZ c’est souvent un indice de retries, de lectures de reconstruction, ou d’un périphérique qui se comporte étrangement.

Décision : Marquez sdd comme suspect et corroborer avec zpool status et SMART. Ne remplacez rien encore, mais arrêtez de débattre des « totaux du pool ».

Tâche 2 : Se concentrer sur un seul pool et réduire le bruit

cr0x@server:~$ zpool iostat -v -y tank 2 10
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        7.12T  3.80T    950    410   118M  37.6M
  raidz2-0  7.12T  3.80T    950    410   118M  37.6M
    sda         -      -    165     68  20.6M  6.0M
    sdb         -      -    163     67  20.7M  6.1M
    sdc         -      -    164     66  20.5M  5.9M
    sdd         -      -     10    175   1.1M  18.7M
    sde         -      -    166     67  20.8M  6.0M
    sdf         -      -    162     69  20.5M  6.1M

Signification : L’imbrication persiste sur les intervalles. Ce n’est pas un pic ponctuel.

Décision : Montez le statut de « intuition » à « investigation active ». Quelqu’un doit lancer un dump SMART et vérifier les erreurs maintenant, pas après la fin de l’incident.

Tâche 3 : Vérifier l’état du pool et voir si ZFS vous donne déjà la réponse

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced.
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Wed Dec 25 03:12:41 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       3     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

errors: No known data errors

Signification : sdd a des erreurs de lecture. ZFS les a corrigées (donc vous n’avez pas de corruption), mais cela a coûté de la latence.
« Applications are unaffected » signifie intégrité des données, pas expérience utilisateur.

Décision : Traitez sdd comme défaillant jusqu’à preuve du contraire. Préparez le remplacement et vérifiez aussi le câblage/le contrôleur.

Tâche 4 : Récupérer la santé SMART et chercher les menteurs habituels

cr0x@server:~$ sudo smartctl -a /dev/sdd
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   100   100   010    Pre-fail  Always       -       12
187 Reported_Uncorrect      100   100   000    Old_age   Always       -       3
197 Current_Pending_Sector  100   100   000    Old_age   Always       -       1
199 UDMA_CRC_Error_Count    200   199   000    Old_age   Always       -       48
194 Temperature_Celsius     031   048   000    Old_age   Always       -       57

Signification : « PASSED » n’est pas une garantie de performance. Les secteurs réalloués et en attente suggèrent une dégradation du média.
Les erreurs CRC pointent vers des problèmes de câblage/backplane/contrôleur. 57°C signifie « je ne suis pas mort, je suis juste lent et en colère ».

Décision : Si CRC augmente, resserrez/remplacez le câble/backplane/ligne. Si des realloc/pending existent, planifiez le remplacement du disque.
Si la température est élevée, corrigez le flux d’air ; la chaleur cause des pics de latence avant les pannes définitives.

Tâche 5 : Confirmer le mapping du disque suspect (éviter de remplacer le mauvais disque)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep sdd | head
lrwxrwxrwx 1 root root  9 Dec 25 09:10 ata-ST12000NM0007_ZL0ABC12 -> ../../sdd
lrwxrwxrwx 1 root root 10 Dec 25 09:10 wwn-0x5000c500a1b2c3d4 -> ../../sdd

Signification : Vous avez des identifiants stables (WWN/by-id) qui survivent aux reboots et au renumérotage des périphériques.

Décision : Utilisez by-id/WWN dans les procédures de remplacement et dans zpool replace quand c’est possible.
« On a sorti le mauvais disque » est un genre d’incident.

Tâche 6 : Vérifier si un scrub/resilver concurrence pour l’I/O

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 09:02:11 2025
        3.11T scanned at 1.25G/s, 1.44T issued at 595M/s, 7.12T total
        0B repaired, 20.18% done, 00:18:43 to go

Signification : Un scrub lit activement le pool. Sur des pools chargés, scrub peut augmenter la latence en saturant les files disque.
Si un disque est faible, le scrub le met en évidence en traînant des pieds.

Décision : Pendant un incident visible par les clients, envisagez de mettre le scrub en pause (zpool scrub -p) si la politique le permet.
Mais ne « corrigez » pas l’incident en supprimant définitivement les scrubs ; c’est comme transformer des erreurs latentes en perte de données plus tard.

Tâche 7 : Déterminer la pression d’écritures sync (et cesser de blâmer SLOG à tort)

cr0x@server:~$ zfs get -o name,property,value -H sync,logbias tank
tank	sync	standard
tank	logbias	latency

Signification : Les écritures sync sont honorées normalement ; logbias favorise le device de log si présent.
Si la latence de votre appli vient d’écritures fsync intensives, la qualité du SLOG compte. Si ce n’est pas sync-heavy, SLOG ne vous sauvera pas.

Décision : Si l’incident concerne la latence d’écriture et que vous n’avez pas de SLOG (ou qu’il est lent), envisagez d’ajouter un SLOG sûr contre les pertes de puissance.
Si vous en avez déjà un, ne supposez pas qu’il fonctionne — mesurez-le.

Tâche 8 : Observer le comportement par vdev dans un miroir (attraper le cas « un côté est malade »)

cr0x@server:~$ zpool iostat -v -y ssdpool 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
ssdpool      812G   989G   4200   1800   520M   210M
  mirror-0   812G   989G   4200   1800   520M   210M
    nvme0n1      -      -   4100    900   505M   110M
    nvme1n1      -      -    100    900    15M   110M

Signification : Les lectures sont majoritairement servies par nvme0n1 ; les écritures sont miroir donc les deux en prennent part.
Ce motif peut survenir parce que ZFS préfère le côté le plus rapide pour les lectures. Si nvme1n1 se bloque, vous ne le remarquerez peut-être pas tant que la latence d’écriture ou le resilver n’apparaît pas.

Décision : Enquêtez quand même sur le côté « silencieux ». Lancez SMART/log NVMe et vérifiez le throttling thermique ou les erreurs média.

Tâche 9 : Vérifier la santé NVMe pour throttling et réinitialisations

cr0x@server:~$ sudo nvme smart-log /dev/nvme1
temperature                         : 79 C
available_spare                     : 100%
percentage_used                     : 12%
media_errors                        : 0
num_err_log_entries                 : 27
warning_temp_time                   : 148
critical_comp_time                  : 0

Signification : 79°C plus un temps d’avertissement thermique important : le périphérique throttle probablement.
Les entrées de log d’erreur suggèrent des réinitialisations/timeouts même si media_errors est zéro.

Décision : Corrigez le refroidissement et vérifiez le comportement du firmware/contrôleur. Le throttling est un tueur de latence qui ressemble à des « pauses ZFS aléatoires ».

Tâche 10 : Chercher des problèmes de contrôleur ou de lien dans les logs du kernel

cr0x@server:~$ sudo dmesg | egrep -i "sdd|ata|reset|timeout|I/O error" | tail -n 8
[ 8123.441122] ata7: hard resetting link
[ 8123.771090] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 8124.112904] blk_update_request: I/O error, dev sdd, sector 223456789 op 0x0:(READ)
[ 8124.112970] sd 7:0:0:0: [sdd] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 8124.113001] sd 7:0:0:0: [sdd] Sense Key : Medium Error [current]

Signification : Réinitialisations de lien et erreurs I/O. Ce n’est pas « ZFS est lent ». C’est le périphérique ou le chemin.

Décision : Remplacez/réparez le chemin (câble/backplane/port HBA) et probablement le disque. Si les erreurs persistent après correction du chemin, le disque est coupable.

Tâche 11 : Confirmer ashift et éviter l’amplification d’écriture accidentelle

cr0x@server:~$ zdb -C tank | egrep "ashift|vdev_tree" -n | head -n 12
56:        vdev_tree:
78:            ashift: 12

Signification : ashift: 12 signifie secteurs 4K. Bon pour les disques modernes.
Si vous voyez 9 (512B) sur du media 4K, vous pouvez créer un comportement sauvage de read-modify-write et de la latence sous écritures aléatoires.

Décision : Si ashift est incorrect, la vraie correction est de reconstruire le pool correctement. Ne supposez pas qu’un réglage sauvera la situation.

Tâche 12 : Déterminer si un vdev spécial est le goulot caché

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME           STATE     READ WRITE CKSUM
        tank           ONLINE       0     0     0
          raidz2-0     ONLINE       0     0     0
            sda        ONLINE       0     0     0
            sdb        ONLINE       0     0     0
            sdc        ONLINE       0     0     0
            sdd        ONLINE       3     0     0
            sde        ONLINE       0     0     0
            sdf        ONLINE       0     0     0
        special
          mirror-1     ONLINE       0     0     0
            nvme2n1    ONLINE       0     0     0
            nvme3n1    ONLINE       0     0     0

Signification : Il y a un vdev spécial en miroir. S’il est sous-dimensionné ou en throttling, les workloads lourds en métadonnées ralentissent même si le RAIDZ principal semble correct.
Si le vdev spécial meurt, le pool peut être compromis selon ce qui y est alloué.

Décision : Surveillez le vdev spécial comme s’il était critique (parce qu’il l’est). S’il est chaud ou en erreur, réparez-le en priorité.

Tâche 13 : Corréler le comportement ZFS avec l’utilisation du bloc-dispositif

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11.20    0.00    6.10    9.40    0.00   73.30

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  svctm  %util
sda             168.0    70.0 21000.0  6200.0    224.2     1.10    5.20   1.40  33.2
sdb             166.0    69.0 20800.0  6100.0    223.9     1.08    5.10   1.35  32.9
sdc             167.0    68.0 20900.0  6000.0    224.1     1.12    5.30   1.38  33.5
sdd              10.0   175.0  1100.0 18700.0    225.0    18.40  115.00   5.90  99.8
sde             167.0    69.0 21100.0  6100.0    224.0     1.09    5.20   1.37  33.1
sdf             165.0    70.0 20700.0  6200.0    224.3     1.11    5.10   1.36  33.0

Signification : sdd a une file d’attente énorme (avgqu-sz), un await élevé, et 99.8% d’utilisation.
Les pairs roulent à ~33% d’utilisation avec des awaits ~5 ms. Voilà votre coupable de latence.

Décision : Vous avez assez de preuves pour agir. Si la redondance le permet, mettez sdd hors ligne et remplacez-le, ou réparez son chemin.
N’attendez pas qu’il « échoue davantage ».

Tâche 14 : Mettre un disque hors ligne en toute sécurité (si vous savez ce que vous faites)

cr0x@server:~$ sudo zpool offline tank sdd

Signification : ZFS cesse d’utiliser ce périphérique. Dans un vdev RAIDZ2, vous pouvez survivre à deux périphériques manquants ; dans un miroir, vous pouvez survivre à un seul.

Décision : Faites cela uniquement si la redondance le permet et que vous êtes confiant dans l’identité du périphérique. Mettre hors ligne peut immédiatement améliorer la latence en retirant le périphérique bloquant du chemin I/O.

Tâche 15 : Remplacement par-id et surveiller la distribution d’I/O du resilver

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/wwn-0x5000c500a1b2c3d4 /dev/disk/by-id/wwn-0x5000c500d4c3b2a1

Signification : Vous remplacez l’appareil WWN exact par un nouveau. Cela évite la roulette des noms de périphériques.

Décision : Après remplacement, utilisez zpool iostat -v pendant le resilver pour assurer que le nouveau disque se comporte comme ses pairs et que le pool reste réactif.

Comment interpréter les motifs : signatures de latence des pannes courantes

Signature 1 : Un disque montre moins d’ops et des intervalles de « plat » occasionnels

Vous verrez un disque dont les ops lecture/écriture tombent près de zéro pendant un intervalle, puis qui « rattrape ».
C’est classique pour les blocages de firmware, le GC interne (SSD), ou les réinitialisations de lien SATA.
Le total du pool peut ne pas s’effondrer parce que les autres périphériques travaillent encore, mais votre p99 sera catastrophique.

Que faire : Vérifiez dmesg pour les réinitialisations/timeouts et les logs SMART/NVMe. Vérifiez les températures. Si ça revient, remplacez.

Signature 2 : Un disque est à 100% d’utilisation avec des files énormes ; les pairs sont plutôt calmes

C’est un coupable évident. ZFS émet ce qu’il peut, mais le périphérique ne suit pas.
En RAIDZ, un disque à 100% peut limiter les lectures de reconstruction et les opérations de parité. Dans les mirrors, le côté lent peut encore nuire aux écritures.

Que faire : Confirmez avec iostat -x. Si c’est un problème de chemin (erreurs CRC), réparez le câblage. Si c’est le média, remplacez le disque.

Signature 3 : Les écritures sont lentes partout, mais les lectures vont bien

Souvent des écritures sync. Ou un SLOG qui n’est pas réellement rapide. Ou un dataset dont les paramètres forcent le sync (ou votre appli appelle fsync sans cesse).
Les mirrors masquent mieux les problèmes de lecture que d’écriture ; RAIDZ punit les écritures aléatoires.

Que faire : Confirmez les paramètres du dataset (sync, logbias), vérifiez la présence d’un SLOG et validez qu’il est faible en latence et sûr contre les pertes de puissance.
Vérifiez aussi si la fragmentation et les petits records sur RAIDZ posent problème.

Signature 4 : Pendant un scrub/resilver, tout devient lent

Scrub/resilver est un sport de contact total. ZFS va se battre pour le temps disque avec votre workload.
Si vous avez un disque marginal, le scrub en fait la vedette.

Que faire : Planifiez le scrub. Envisagez de limiter via des outils d’ordonnancement I/O au niveau système (spécifique à la plate-forme) plutôt que de désactiver les scrubs.
Si le scrub révèle des erreurs sur un disque spécifique, ne discutez pas ; remplacez-le.

Signature 5 : Le vdev spécial ou le device métadonnées se bloque et provoque des comportements bizarres « tout est lent mais les disques de données sont calmes »

Les métadonnées sont souvent le goulet pour de nombreuses charges. Si le vdev spécial est surchargé ou throttlé, les opérations de fichier et les petites I/O peuvent ramper.
Vous verrez les périphériques du vdev spécial plus chauds/occupés que le vdev principal.

Que faire : Surveillez-le comme une ressource de niveau 0. Utilisez zpool iostat -v et la télémétrie périphérique pour confirmer que ce n’est pas un throttling thermique.

Une citation à garder sur un post-it (idée paraphrasée) : Le message fiabilité de John Allspaw : vous ne « prévenez » pas la panne ; vous construisez des systèmes qui détectent et récupèrent rapidement.

Blague #2 : SMART « PASSED » est comme un rapport de statut en entreprise — techniquement vrai, émotionnellement inutile.

Trois mini-récits d’entreprise depuis les tranchées de la latence

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

Une entreprise SaaS de taille moyenne exploitait un niveau NFS sur ZFS pour des artefacts CI et des images de conteneurs. Pendant des mois, tout allait bien.
Puis une lenteur « aléatoire » a commencé : les builds se bloquaient, les pulls expiraient, et l’astreinte se faisait dire, à plusieurs reprises, que « le stockage est lent encore ».
L’équipe a supposé qu’il s’agissait d’une saturation réseau parce que les graphiques de débit du pool ne paraissaient pas terribles.

Ils ont passé une matinée à ajuster les threads NFS et à débattre sur le MTU. Ils ont redémarré un switch.
Rien n’a changé. Les pics de latence étaient toujours là, surtout pendant les heures de pointe des commits.
Quelqu’un a finalement lancé zpool iostat -v -y 1 pendant une fenêtre d’incident et a remarqué un disque dans un vdev RAIDZ2
affichant beaucoup moins de lectures que ses frères, avec des intervalles périodiques presque nuls.

La mauvaise hypothèse était subtile : ils croyaient que « si le débit est correct, le stockage n’est pas le problème ».
Mais leur charge faisait beaucoup de petites lectures aléatoires (traversées de répertoires axées métadonnées et beaucoup de petits fichiers), où la latence de queue compte plus que le MB/s agrégé.
Un disque réinitialisait intermittemment le lien SATA. ZFS a gardé le pool en ligne et a réparé, mais les retries se sont traduits par des blocages visibles pour les utilisateurs.

Ils ont remplacé le disque, et les graphiques n’ont pas beaucoup changé. C’est le point : le débit n’était jamais le vrai symptôme.
Les tickets clients ont cessé dans l’heure parce que la latence p99 a cessé de faire des détours par la récupération d’erreurs.
La leçon qu’ils ont retenue : on ne dépanne pas les incidents ZFS avec les totaux du pool ; on les dépanne avec des deltas par périphérique et des preuves.

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

Une entreprise du domaine financier utilisait un pool ZFS pour servir des VM via iSCSI. La latence était correcte mais pas excellente.
Un ingénieur a proposé un « gain facile » : changer des propriétés de dataset pour chercher la performance — recordsize plus petit « pour les bases de données », compression plus agressive,
et un changement global pour traiter les écritures sync différemment parce que « l’onduleur nous couvrira ».

Le benchmark immédiat semblait meilleur. Puis la production est arrivée.
Les bases ont commencé à faire plus d’I/O par transaction à cause du mismatch du recordsize avec les patterns, la compression a augmenté le CPU lors des pics, et les changements sync ont créé des comportements pathologiques avec les patterns de fsync de l’application.
Pour empirer, l’équipe a ajouté un NVMe grand public comme SLOG parce qu’il était « rapide », en ignorant les caractéristiques d’anti-perte-de-puissance et la latence soutenue.

zpool iostat -v a raconté une histoire précise : le device SLOG était saturé avec de fortes ops d’écriture pendant les heures de pointe,
et un membre d’un miroir a commencé à montrer une distribution inégale alors qu’il surchauffait.
La latence a empiré exactement quand l’équipe espérait l’améliorer.

Le rollback a résolu l’incident. Le postmortem n’était pas une histoire de honte ; c’était une leçon de discipline.
Les optimisations qui changent la sémantique des écritures ne sont pas des « ajustements ». Ce sont des changements d’architecture.
Si vous ne pouvez pas expliquer les nouveaux modes de défaillance — et les mesurer en direct — vous déplacez juste le risque jusqu’à ce qu’il atterrisse sur un client.

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

Un fournisseur de soins de santé utilisait ZFS pour un stockage de documents. Personne n’aimait ce système ; il était « legacy », ce qui veut dire critique et sous-financé.
Mais l’ingénieur stockage avait une habitude : fenêtres de scrub hebdomadaires, et un runbook simple qui incluait la capture de zpool iostat -v pendant le scrub.
Ennuyeux. Répétitif. Efficace.

Un week-end, le temps de scrub a augmenté sensiblement. Pas assez pour déclencher une alerte, mais assez pour apparaître dans les notes.
Pendant le scrub, les stats par disque ont montré un disque faisant moins de lectures et se bloquant parfois.
SMART affichait toujours « PASSED », bien entendu, mais il y avait quelques CRC en croissance et une température élevée.

L’ingénieur a ouvert un ticket pour remplacer le câble et, si nécessaire, le disque lors de la prochaine fenêtre de maintenance.
Le remplacement du câble a réduit les CRC mais n’a pas éliminé les blocages. Ils ont remplacé le disque de manière proactive, le resilver s’est déroulé proprement, et ils ont continué.

Deux mois plus tard, une autre équipe a eu une panne quasi identique sur un châssis similaire et a subi un incident désordonné parce qu’elle n’avait pas d’historique de tendance ni l’habitude d’observer le comportement par disque.
La pratique ennuyeuse n’a pas seulement évité un downtime ; elle a évité l’ambiguïté.
Quand vous pouvez dire « ce disque se dégrade sur des semaines », vous faites de la maintenance au lieu d’être un héros.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Le débit du pool semble correct, mais la latence p99 est terrible

Cause racine : Un disque se bloque de façon intermittente ; ZFS relance/répare ; les moyennes cachent la latence de queue.
Ou le vdev spécial bloque les opérations métadonnées.

Correction : Utilisez zpool iostat -v -y 1 pendant l’événement ; trouvez l’asymétrie.
Corrélez avec iostat -x, dmesg, et les logs SMART/NVMe. Remplacez le disque/chemin défaillant ; corrigez la surchauffe.

2) Symptom : Les écritures sont lentes sur un miroir même si les lectures sont rapides

Cause racine : ZFS peut choisir le côté le plus rapide pour les lectures, masquant un disque malade ; les écritures doivent toucher les deux.
Ou les écritures sync saturent un SLOG faible.

Correction : Cherchez l’imbalance par feuille dans le miroir avec zpool iostat -v.
Validez le comportement du SLOG. Réparez/remplacez le membre lent du miroir ou le device SLOG.

3) Symptom : Les scrubs rendent le pool inutilisable

Cause racine : Le scrub concurrence les I/O ; le pool est près de la capacité ou fragmenté ; un disque marginal devient le goulot.

Correction : Planifiez les scrubs en heures creuses ; envisagez de les mettre en pause pendant les incidents.
Enquêtez le disque lent avec zpool iostat -v et SMART ; remplacez-le s’il traîne. Gardez de l’espace libre sain.

4) Symptom : Un pool RAIDZ a une mauvaise latence d’écriture aléatoire comparé aux attentes

Cause racine : Overhead de parité RAIDZ plus petits blocs ; mauvais recordsize ; ashift mal aligné ; workload sync-heavy sans design adapté.

Correction : Confirmez ashift. Alignez recordsize avec la charge. Pour IOPS et faible latence de queue, préférez les mirrors ou ajustez la largeur des vdevs et les patterns de workload.
Ne « tolérez » pas la parité.

5) Symptom : Un disque affiche beaucoup d’erreurs CRC mais pas de réallocations

Cause racine : Problèmes de câblage/backplane/HBA provoquant corruption au niveau du lien et retries.

Correction : Remplacez/remontez les câbles, changez de port, vérifiez le backplane. Surveillez si les CRC continuent d’augmenter après correction.

6) Symptom : Remplacer un disque n’a pas aidé ; la latence pique toujours

Cause racine : Le chemin/contrôleur est le vrai problème ; ou la charge martèle des écrits sync ; ou le vdev spécial throttle.

Correction : Utilisez dmesg et la télémétrie du contrôleur. Validez sync/logbias et le SLOG.
Inspectez l’iostat du vdev spécial et les thermiques NVMe.

7) Symptom : « zpool iostat ne montre rien de mal » mais l’appli est lente

Cause racine : Vous regardez des moyennes depuis le boot (pas d’intervalle), ou l’incident est intermittent et vous l’avez manqué.
Ou le goulot est au-dessus de ZFS (CPU, mémoire, réseau) ou en dessous (multipath, SAN, hyperviseur).

Correction : Utilisez toujours le mode intervalle. Capturez pendant l’événement. Ajoutez un échantillonnage continu léger dans votre monitoring pour pouvoir rejouer le moment.

Checklists / plan étape par étape

Étape par étape : attraper le disque lent en moins de 10 minutes

1. Exécuter des stats par intervalle.

   cr0x@server:~$ zpool iostat -v -y 1
   

   Décision : Identifier tout périphérique feuille dont les ops/bande passante ne correspondent pas à ses pairs.

2. Confirmer l’état du pool et l’activité en arrière-plan.

   cr0x@server:~$ zpool status -v
   

   Décision : Si scrub/resilver est actif, décider s’il faut le mettre en pause pour atténuer l’incident.

3. Corréler avec la file et l’attente du périphérique bloc.

   cr0x@server:~$ iostat -x 1 3
   

   Décision : Forte await et file sur un disque = action. N’attendez pas.

4. Vérifier les logs pour réinitialisations/timeouts.

   cr0x@server:~$ sudo dmesg | egrep -i "reset|timeout|I/O error|blk_update_request" | tail -n 30
   

   Décision : Si des réinitialisations existent, suspectez câblage/HBA/backplane même si SMART est calme.

5. Récupérer les logs SMART/NVMe du périphérique suspect.

   cr0x@server:~$ sudo smartctl -a /dev/sdX
   

   Décision : Pending/realloc/CRC/temp orientent vers remplacer vs corriger le chemin.

6. Si la redondance le permet, mettre le fautif hors ligne pour restaurer la latence.

   cr0x@server:~$ sudo zpool offline tank sdX
   

   Décision : Utilisez ceci comme mesure d’urgence, pas comme mode de vie permanent.

7. Remplacer avec des identifiants stables et surveiller le resilver.

   cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/OLD /dev/disk/by-id/NEW
   

   Décision : Si le nouveau disque a un iostat différent des pairs, arrêtez et validez le matériel et le firmware.

Checklist : que capturer pour un postmortem utile

• zpool iostat -v -y 1 échantillons pendant la fenêtre d’incident (même 60 secondes aident)
• zpool status -v incluant les comptes d’erreurs et l’état des scans
• Logs SMART/NVMe pour tout disque suspect (incluant température et CRC)
• iostat -x pour confirmer file/await/util
• Logs kernel autour du pic (réinitialisations, timeouts)
• Ce qui a changé récemment (firmware, déplacement de câbles, changements de workload, paramètres de dataset)

Checklist : décisions à prendre explicitement (pas à la sensation)

• Le problème est-il isolé à un disque, un vdev, ou systémique ?
• Avons-nous la redondance pour mettre hors ligne maintenant ?
• Est-ce un problème de chemin (CRC/réinitialisations) ou de média (pending/realloc/uncorrectable) ?
• Un scrub/resilver amplifie-t-il le problème, et peut-il être mis en pause en toute sécurité ?
• Faut-il revoir l’architecture (mirrors vs RAIDZ, dimensionnement du vdev spécial) plutôt que de tuner ?

FAQ

1) Pourquoi un disque lent peut-il nuire à tout le pool ?

Parce que ZFS émet des I/O vers des vdevs spécifiques. Si un bloc vit sur le vdev lent (ou nécessite une reconstruction impliquant ce vdev), la requête attend.
La latence de queue est dominée par le pire participant, pas par le participant moyen.

2) Est-ce que zpool iostat affiche la latence ?

En général il montre les ops et la bande passante, pas les millisecondes. Mais la latence apparaît indirectement comme une réduction des ops, une distribution inégale et la croissance des files
confirmée par iostat -x ou des outils de latence spécifiques à la plate-forme.

3) Pourquoi devrais-je toujours utiliser un intervalle (comme zpool iostat -v 1) ?

Sans intervalle, vous regardez des moyennes depuis l’import/démarrage. Les incidents vivent dans des pics et des deltas.
Le mode intervalle vous donne la réalité par seconde (ou par N secondes).

4) Je vois un côté de miroir qui sert presque toutes les lectures. Est-ce mauvais ?

Pas automatiquement. ZFS peut préférer le côté le plus rapide. C’est mauvais quand le côté « ignoré » est ignoré parce qu’il est malade
(throttling thermique, timeouts, erreurs). Vérifiez la télémétrie du périphérique.

5) SMART indique PASSED. Le disque peut-il quand même être en cause ?

Oui. L’état global SMART est grossier. Regardez les attributs spécifiques (pending sectors, reallocations, CRC errors, temperature)
et les logs d’erreurs. Vérifiez aussi dmesg pour les réinitialisations/timeouts.

6) Dois-je mettre en pause le scrub pendant un incident ?

Si le scrub concurrence des I/O de production critiques et que vous devez restaurer le service, la pause peut être une mesure raisonnable à court terme.
Mais replanifiez-le et enquêtez pourquoi le scrub fait tant de mal — souvent il révèle un disque faible ou un design surchargé.

7) Ajouter un SLOG corrige-t-il la latence ?

Il peut corriger la latence des écritures synchrones lorsque la charge est vraiment sync-heavy et que le device SLOG est à faible latence et sûr contre la perte de puissance.
Il ne fait rien pour les écritures asynchrones ou les lectures, et un mauvais SLOG peut empirer la situation.

8) Comment savoir si c’est un câble/backplane plutôt qu’un disque ?

L’augmentation de UDMA_CRC_Error_Count sur les appareils SATA est un indice fort, ainsi que les réinitialisations de lien dans dmesg.
Les erreurs média (pending/realloc/uncorrectable) indiquent plutôt le disque lui-même. Parfois vous avez les deux ; corrigez le chemin d’abord, puis réévaluez.

9) Pourquoi RAIDZ est souvent pire pour la latence d’écriture aléatoire que les mirrors ?

La parité requiert des lectures/écritures supplémentaires et une coordination entre disques ; les petites écritures peuvent devenir des cycles read-modify-write.
Les mirrors effectuent des écritures plus simples. Si vous avez besoin d’IOPS et de faible latence de queue, les mirrors sont généralement le choix direct.

10) Quelle est la preuve la plus rapide que je peux montrer à des non-spécialistes stockage ?

Une courte capture de zpool iostat -v -y 1 plus iostat -x 1 où un périphérique a un await et une file dramatiquement plus élevés tandis que les pairs sont normaux.
C’est visuel, reproductible, et ne nécessite pas de croire au folklore du stockage.

Conclusion : quoi faire ensuite, aujourd’hui

Quand la latence ZFS déraille, ne commencez pas par « tuner ZFS ». Commencez par prouver si un disque ou un vdev se comporte mal.
zpool iostat -v avec un intervalle est votre lampe torche ; il trouve l’asymétrie rapidement.
Puis corroborer avec zpool status, les logs SMART/NVMe et les messages du kernel.

Prochaines étapes pratiques :

• Intégrez zpool iostat -v -y 1 dans votre runbook d’incident, pas seulement dans votre mémoire.
• Pendant la prochaine fenêtre de scrub, capturez le comportement par disque et baselinez-le. Les baselines ennuyeuses raccourcissent les incidents excitants.
• Si vous trouvez un périphérique suspect, décidez rapidement : corriger le chemin, mettre hors ligne, ou remplacer. La latence de queue ne guérit rarement seule.
• Si votre architecture est mal adaptée (DB sync-heavy sur RAIDZ large, vdev spécial sous-dimensionné), admettez-le et planifiez la refonte au lieu de vénérer des réglages.

Le disque unique qui ruine la latence est rarement subtil. La partie subtile, c’est nous : nous continuons à regarder les totaux du pool en espérant que les moyennes diront la vérité.
Elles ne le feront pas. Les deltas par périphérique le feront.