ZFS vous offre un cadeau rare en production : il vous dit ce qu’il sait, et il est généralement honnête. Mais zpool status n’est pas un contrôle binaire de santé ; c’est un rapport de crash, une photo de scène de crime et une prévision météo en un seul. Lisez-le comme un analyste médico-légal et il vous évitera le pire type d’incident : celui qui semble normal jusqu’au moment où il ne l’est plus.
Ce guide de terrain s’adresse aux SRE et aux ingénieurs stockage qui veulent passer de « le pool est DEGRADED, panique » à « voici le domaine de défaillance, voici le rayon d’impact, voici la commande suivante. » Nous dissèquerons la sortie, associerons les symptômes aux causes racines et parcourrons des tâches opérationnelles réelles — scrubs, clears, remplacements, resilvers, et les moments embarrassants où les disques sont innocents et le câblage coupable.
Ce que zpool status est vraiment (et n’est pas)
zpool status est une vue synthétique d’un système de stockage transactionnel capable d’auto-guérison, d’auto-diagnostic et parfois d’auto-incrimination. Ce n’est pas un rapport SMART complet, pas un tableau de bord de performance et pas un oracle. C’est un ensemble structuré d’indices : la topologie du pool, l’état de chaque vdev, les compteurs d’erreurs et les derniers événements notables.
En termes médico-légaux : c’est la chronologie de l’incident plus la liste des suspects. Vous devez toujours interroger les suspects (SMART, câblage, HBAs, multipath), reconstruire la chronologie (logs de scrub/resilver), et confirmer si la “victime” est des données, de la performance, ou les deux.
Une vérité opérationnelle : zpool status privilégie la justesse plutôt que le confort. S’il dit “DEGRADED”, il ne vous invite pas à méditer ; il vous demande d’agir, ou du moins de comprendre le risque que vous avez accepté.
Anatomie de zpool status : chaque ligne compte
Commençons par une sortie représentative puis démontons-la comme un post-mortem.
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: ZFS-8000-2Q
scan: scrub repaired 0B in 0 days 02:41:19 with 0 errors on Tue Dec 24 03:12:18 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-SAMSUNG_SSD_860... ONLINE 0 0 0
ata-SAMSUNG_SSD_860... UNAVAIL 0 0 0 cannot open
raidz1-1 ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
ata-WDC_WD40EFRX... ONLINE 0 0 0
errors: No known data errorspool / state / status / action : le résumé exécutif
pool: est le nom du pool. En réponse à incident, c’est aussi votre étiquette de rayon d’impact : tout ce qui est monté depuis ce pool partage le même destin lors d’une panne.
state: est la classification de santé grossière. Ce n’est pas juste “bon/mauvais” ; c’est “combien de façons puis-je encore lire la vérité.” ONLINE signifie que la redondance est intacte. DEGRADED signifie que la redondance est compromise mais que suffisamment de répliques existent pour continuer à servir les données. FAULTED signifie que le pool ne peut pas fournir des données cohérentes.
status: est l’interprétation lisible par un humain. ZFS vous dira souvent s’il manque un périphérique, s’il y a de la corruption, ou s’il a observé des erreurs I/O. Ce n’est pas parfait, mais c’est généralement indicatif.
action: est la suggestion de votre prochaine étape. Ne la traitez pas comme un biscuit de la fortune ; traitez-la comme un indice de runbook. Elle peut recommander zpool clear, zpool online, remplacer un périphérique, ou restaurer depuis une sauvegarde.
scan : la sortie scrub/resilver est votre chronologie
scan: vous indique si un scrub est en cours, terminé, ou si un resilver (reconstruction après remplacement/rattachement d’un périphérique) est en cours. Cette ligne répond à des questions cruciales :
- Un scrub a-t-il été effectué récemment, ou jouez-vous à la roulette de la corruption silencieuse ?
- ZFS a-t-il réparé quelque chose ? Si oui, l’a-t-il réparé à partir de la parité/mirror ou s’est-il contenté de détecter ?
- Y a-t-il eu des erreurs pendant le scrub ? “0 errors” rassure ; “with N errors” escalade la situation.
config : la topologie est la carte des domaines de défaillance
L’arbre config: est la section la plus importante à lire comme un ingénieur stockage, pas comme une file d’assistance. Il vous dit :
- Quels types de vdev vous avez (mirror, raidz1/2/3, special, log, cache, spare).
- Quels périphériques feuilles soutiennent chaque vdev.
- À quel niveau la dégradation se produit (un disque feuille, un vdev complet, ou le pool).
Les pools ZFS sont une “bande de vdevs”. Cela signifie que la disponibilité du pool dépend de chaque vdev de niveau supérieur. La défaillance d’un seul vdev de niveau supérieur peut mettre le pool hors service, même si les autres vdevs vont bien. C’est là que les gens lisent “un seul disque manquant” et le traduisent par erreur en “seul un disque compte”.
errors : la fin trompeusement calme
errors: No known data errors n’est pas équivalent à « rien de grave ne s’est produit ». Cela signifie que ZFS n’a pas identifié de corruption de données persistante qu’il n’a pas pu réparer ou qui reste après réparation. Vous pouvez toujours avoir :
- Des timeouts I/O transitoires qui ont incrémenté READ/WRITE mais n’ont pas corrompu les données.
- Des erreurs de checksum qui ont été guéries via la redondance (ce qui est bon) mais qui restent un signal d’alerte (ce qui est aussi bon).
- Un périphérique qui a disparu puis réapparu, vous laissant à un reboot près d’un mauvais jour.
Première blague (celle que vous apprécierez à 03:00) : ZFS est comme un bon pager—quand il est silencieux, ça ne veut pas dire que tout va bien, ça veut dire que vous n’avez pas posé la bonne question.
États de santé : ONLINE, DEGRADED, FAULTED, UNAVAIL, SUSPENDED
Les mots d’état ZFS sont courts parce qu’ils doivent tenir sur une console au pire moment de votre semaine. Voici comment les interpréter opérationnellement.
ONLINE
ONLINE signifie que le vdev/pool est accessible et que la redondance est intacte à ce niveau. Vous pouvez toujours avoir des compteurs d’erreurs qui s’accumulent sur un disque tout en restant ONLINE. “ONLINE with errors” est un état réel du monde et c’est un signal d’avertissement pour votre futur vous.
DEGRADED
DEGRADED signifie que ZFS a perdu une partie de la redondance mais peut encore servir les données. Dans un mirror, un côté peut être manquant/faulted et le mirror sera DEGRADED. Dans RAIDZ, un disque (RAIDZ1) ou deux (RAIDZ2) peuvent être manquants et le vdev RAIDZ reste vivant, jusqu’à ce qu’il ne le soit plus.
Opérationnellement : DEGRADED est l’endroit où vous avez encore du temps, mais votre budget temps est inconnu. Il dépend de la charge, du temps de reconstruction et de l’état des périphériques restants.
FAULTED
FAULTED signifie généralement que ZFS a déterminé que le périphérique ou le vdev est suffisamment cassé pour ne plus pouvoir être utilisé en toute sécurité. Parfois c’est un disque. Parfois c’est le chemin vers le disque. Parfois c’est un contrôleur entier qui est sorti pour un café et n’est jamais revenu.
UNAVAIL
UNAVAIL signifie que ZFS ne peut pas accéder au périphérique. Le disque peut avoir disparu, l’OS peut l’avoir renommé, l’expander SAS peut mal se comporter, ou multipath a changé d’identité. UNAVAIL avec “cannot open” est un classique : ZFS a essayé, l’OS a répondu “non”.
SUSPENDED
SUSPENDED est l’état “arrêter le monde”. ZFS suspendra les I/O quand continuer risquerait une corruption pire ou quand il voit des échecs I/O répétés. Ce n’est pas un moment “effacez les erreurs et poursuivez” ; c’est un moment “stabilisez le système”.
READ/WRITE/CKSUM : les compteurs qui paient votre salaire
Les trois compteurs dans zpool status sont le moyen le plus rapide de distinguer “disque en fin de vie” de “mauvais câble” de “rayons cosmiques” de “caprice de pilote”. Ils sont aussi souvent mal compris.
READ errors
Une READ error signifie que le périphérique n’a pas renvoyé les données demandées par ZFS. Cela peut être une erreur média, un timeout, une réinitialisation de bus ou un problème de chemin. Si le vdev a de la redondance, ZFS peut récupérer les données ailleurs, puis (souvent) les réécrire pour guérir. Mais la présence de READ errors est un signal fort que quelque chose dans la pile est peu fiable.
WRITE errors
Une WRITE error signifie que ZFS a tenté d’écrire et que le périphérique n’a pas accepté. Cela peut indiquer un média défaillant, un problème de contrôleur, ou que le périphérique a disparu en plein vol. Des WRITE errors répétées sont alarmantes parce qu’elles précèdent souvent la disparition complète d’un périphérique.
CKSUM errors
Les erreurs de checksum sont ZFS faisant ce pour quoi il a été conçu : détecter des données qui ne correspondent pas au checksum attendu. Une CKSUM error n’est pas “ZFS est cassé” ; c’est “ZFS a attrapé quelque chose qui serait de la corruption silencieuse ailleurs”.
Les erreurs CKSUM pointent typiquement vers :
- RAM défectueuse (moins fréquent avec ECC, plus fréquent sans).
- Câblage/backplane/expander défectueux provoquant des inversions de bits ou des frames perdues.
- Problèmes de firmware/driver renvoyant des données erronées sans erreurs I/O (oui, ça arrive).
- Disque défaillant renvoyant des données corrompues qui passent quand même les vérifications internes du disque.
Le grand indice : si vous voyez des CKSUM errors sans READ/WRITE errors, suspectez le chemin de transport ou la mémoire avant de blâmer le disque.
Deuxième blague, parce qu’on l’a méritée : Une erreur de checksum, c’est ZFS qui dit poliment “J’ai trouvé un mensonge.” C’est l’équivalent stockage de surprendre votre GPS vous suggérant calmement de rouler dans un lac.
La ligne “errors :” : quand “No known data errors” est un piège
Cette dernière ligne est un résumé de si ZFS croit qu’il y a eu une corruption non réparée. Vous pouvez avoir un pool avec un risque significatif tout en affichant “No known data errors”. Scénarios courants :
- Corruption réparée : ZFS a détecté des données mauvaises, les a réparées à partir de la redondance, et maintenant tout est cohérent. L’événement compte encore parce qu’il indique un problème de fiabilité sous-jacent.
- Perte transitoire de périphérique : Un disque a disparu pendant une charge élevée, les compteurs ont augmenté, puis il est revenu. Les données peuvent être intactes ; la redondance a pu être stressée. Votre prochain reboot peut être celui où ça ne revient plus proprement.
- Scrub pas récent : Si vous n’avez pas scrubbé depuis des mois, “No known data errors” signifie juste “nous n’avons pas regardé à fond.” ZFS vérifie les checksums à la lecture ; des blocs froids peuvent rester non vérifiés longtemps.
Événements, scrubs, resilvers et la chronologie de la douleur
zpool status affiche une petite chronologie : l’état “scan” et parfois quelques événements récents. Mais l’art opérationnel réel consiste à corréler cela avec les logs système et votre historique de changements. Quand les erreurs ont-elles commencé ? Quelqu’un a-t-il remplacé un câble ? Le firmware a-t-il été mis à jour ? Un scrub a-t-il démarré juste après un job batch chargé ?
Deux mécaniques clés à retenir :
- Scrub lit tous les blocs et vérifie les checksums ; avec de la redondance il peut réparer la corruption silencieuse. Le scrub est votre audit périodique.
- Resilver reconstruit la redondance après qu’un périphérique a été remplacé/rattaché/onlined. Le resilver est un travail de récupération, souvent effectué tout en servant la charge en direct.
La vitesse de resilver et de scrub n’est pas seulement la “vitesse du disque”. Elle dépend de la fragmentation, du recordsize, de la compression, de la charge concurrente, et de si vous traitez RAIDZ (reconstruction par parité) versus mirrors (copie simple). Dans le monde réel, la différence entre un resilver de 2 heures et un resilver de 2 jours fait la différence entre un “ticket de routine” et une “réunion de crise avec la direction”.
Faits intéressants et contexte historique (6–10 points)
- ZFS a été conçu pour détecter la corruption silencieuse de bout en bout avec des checksums stockés séparément des données—ainsi il peut attraper les erreurs introduites par les disques, les contrôleurs ou le transport.
- Le “scrub” n’est pas juste une fonctionnalité agréable ; il a été intégré parce que les disques peuvent renvoyer des données corrompues mais valides longtemps après l’écriture.
- Le modèle vdev (stripe across vdevs) est la raison pour laquelle ajouter un seul vdev RAIDZ augmente la capacité mais crée aussi un nouveau domaine de défaillance pouvant mettre le pool hors service.
- RAIDZ était la réponse de ZFS au problème du write hole que les implémentations RAID-5 classiques pouvaient subir lors d’écritures partielles et de coupures de courant.
- Les compteurs d’erreurs ZFS concernent les échecs observés, pas les prédictions SMART ; vous pouvez avoir un disque “SMART parfait” causant de vrais problèmes I/O ZFS à cause d’un mauvais câble.
- Ashift existe parce que les disques mentent sur la taille de leur secteur ; ZFS a besoin d’une hypothèse d’alignement pour éviter des pénalités read-modify-write.
- Les vdevs spéciaux (metadata/petits blocs sur dispositifs rapides) ont changé la donne de la performance—mais ont aussi introduit une nouvelle façon de perdre un pool s’ils sont mal utilisés sans redondance.
- L2ARC et SLOG ont été largement mal compris au début ; beaucoup d’incidents sont survenus en les traitant comme des “améliorations de vitesse” obligatoires plutôt que comme des outils spécifiques aux charges.
- L’“auto-guérison” de ZFS dépend de la redondance ; sans elle, ZFS peut toujours détecter la corruption mais peut ne pas pouvoir la réparer—la détection seule reste néanmoins précieuse pour la forensique.
Playbook de diagnostic rapide (vérifier d’abord, ensuite, puis)
Ceci est la séquence “j’ai cinq minutes avant que la réunion ne devienne une revue d’incident”. L’objectif est de classifier rapidement le problème : risque de disponibilité, risque d’intégrité des données, ou risque de performance.
Première étape : classifier le domaine de défaillance depuis la topologie
cr0x@server:~$ sudo zpool status -xv
pool 'tank' is not healthy
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.Interprétation : -x vous indique si ZFS pense que le pool est sain ; -v donne des détails. Si un vdev de niveau supérieur est DEGRADED/FAULTED, votre risque est pool-wide. Si un seul périphérique feuille dysfonctionne à l’intérieur d’un vdev redondant, vous avez une fenêtre pour agir.
Deuxième étape : lire les compteurs comme un détective
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb UNAVAIL 12 3 0 cannot openInterprétation : READ/WRITE sur un périphérique manquant indique souvent qu’il présentait des erreurs avant de disparaître. CKSUM à 0 suggère que le périphérique tombe complètement en panne, pas qu’il corrompe silencieusement—toujours mauvais, mais d’un autre type de mauvais.
Troisième étape : décider si vous poursuivez l’intégrité ou la performance
Si le pool est ONLINE mais que les applications sont lentes, ne fixez pas zpool status comme s’il vous devait des excuses. Utilisez-le pour confirmer qu’il n’y a pas de resilver/scrub actif et pas de tempête d’erreurs, puis pivotez vers la latence et la profondeur de file d’attente.
cr0x@server:~$ sudo zpool iostat -v 1 5
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 12.3T 3.2T 210 980 18.4M 92.1M
raidz1-0 12.3T 3.2T 210 980 18.4M 92.1M
sdc - - 70 340 6.1M 30.2M
sdd - - 68 320 6.0M 29.1M
sde - - 72 320 6.3M 32.8M
-------------------------- ----- ----- ----- ----- ----- -----Interprétation : Si un disque traîne, vous verrez souvent des ops/bande passante inégales. Si tout est uniformément occupé mais que la latence est élevée, la charge peut être sync-heavy, à petits blocs, ou souffrir d’un recordsize/volblocksize inadapté.
Tâches pratiques : commandes + interprétation (12+)
Voici des choses concrètes à faire dans un shell quand le pool tente de vous raconter une histoire. Pour chaque tâche : exécutez la commande, lisez la sortie, et décidez de la prochaine action.
Task 1: Quick health check across all pools
cr0x@server:~$ sudo zpool status -x
all pools are healthyInterprétation : Parfait pour les checks cron et les tableaux de bord. Si cela indique unhealthy, suivez immédiatement avec zpool status -v pour les détails.
Task 2: Full forensic view with device paths and error details
cr0x@server:~$ sudo zpool status -vP tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 0 days 01:10:22 with 0 errors on Mon Dec 23 02:11:40 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
/dev/disk/by-id/ata-A... ONLINE 0 0 0
/dev/disk/by-id/ata-B... ONLINE 0 0 0
errors: No known data errorsInterprétation : Utilisez -P pour afficher les chemins complets ; préférez les chemins by-id pour éviter les surprises de renommage de périphériques. Si vous voyez /dev/sdX dans un pool de production, envisagez de migrer vers des identifiants stables quand vous aurez un créneau.
Task 3: Confirm what ZFS thinks each disk is (GUID-level truth)
cr0x@server:~$ sudo zpool status -g tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
11465380813255340816 ONLINE 0 0 0
13955087861460021762 ONLINE 0 0 0Interprétation : Les GUIDs sont la vérité d’identification interne de ZFS. Utile quand les noms de périphériques changent ou que multipath joue à la chaise musicale.
Task 4: Map a missing vdev to the OS’s view of disks
cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE,MOUNTPOINT
NAME SIZE MODEL SERIAL WWN TYPE MOUNTPOINT
sda 3.6T HGST_HUS726T4... K8G... 0x5000cca2... disk
sdb 3.6T HGST_HUS726T4... K8H... 0x5000cca2... disk
nvme0n1 1.8T Samsung_SSD... S5G... eui.002538... diskInterprétation : Si zpool status montre un disque UNAVAIL mais que lsblk ne le liste pas, vous avez probablement un souci physique/chemin : câble, backplane, HBA, expander, alimentation, ou le disque est réellement mort.
Task 5: Online a device that came back (carefully)
cr0x@server:~$ sudo zpool online tank /dev/disk/by-id/ata-SAMSUNG_SSD_860_EVO_S4X...
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: resilvered 12.4G in 0 days 00:03:12 with 0 errors on Tue Dec 24 10:44:01 2025Interprétation : Si le périphérique était brièvement manquant, l’online peut déclencher un resilver. Si le périphérique clignote (disparaît et réapparaît), ne vous réjouissez pas ; remplacez le disque ou réparez le chemin avant qu’il ne tombe à nouveau en plein resilver.
Task 6: Clear error counters after fixing the root cause
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0Interprétation : Clearer les compteurs n’est pas “réparer ZFS.” C’est remettre l’odomètre à zéro après avoir réparé le moteur. Si vous clear sans corriger la cause, les erreurs reviendront—et vous aurez perdu la chronologie.
Task 7: Start a scrub and watch it like it owes you money
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Tue Dec 24 11:02:33 2025
1.32T scanned at 1.01G/s, 412G issued at 322M/s, 12.3T total
0B repaired, 3.27% done, no estimated completion timeInterprétation : Le débit du scrub peut être bien en dessous de la “vitesse disque” quand le pool est occupé. Si l’ETA du scrub est “no estimated completion time”, cela peut signifier que le système ne peut pas prédire à cause d’un taux variable, pas nécessairement qu’il est bloqué.
Task 8: Pause and resume a scrub (when production needs air)
cr0x@server:~$ sudo zpool scrub -p tank
cr0x@server:~$ sudo zpool status tank
scan: scrub paused since Tue Dec 24 11:10:44 2025
2.01T scanned, 0B repaired, 16.3% donecr0x@server:~$ sudo zpool scrub -w tank
cr0x@server:~$ sudo zpool status tank
scan: scrub in progress since Tue Dec 24 11:02:33 2025
2.05T scanned, 0B repaired, 16.6% doneInterprétation : Utile quand les scrubs se heurtent aux pics de charge. Mettre en pause n’est pas un substitut à la planification de capacité ; c’est un outil opérationnel pour éviter de transformer une maintenance en incident.
Task 9: Replace a failed disk in a mirror
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb FAULTED 64 0 0 too many errorscr0x@server:~$ sudo zpool replace tank sdb /dev/disk/by-id/ata-WDC_WD40EFRX-NEW_DISK
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:20:06 2025
412G scanned at 1.12G/s, 96.1G issued at 268M/s, 3.60T total
95.9G resilvered, 2.60% done, 0:23:55 to goInterprétation : Dans un mirror, le resilver est principalement une copie depuis le côté sain. Surveillez les nouvelles erreurs pendant le resilver ; un deuxième disque qui déraille pendant le resilver, c’est ainsi que “dégradé mais OK” devient “restauration depuis sauvegarde”.
Task 10: Replace a disk in RAIDZ (and understand the risk)
cr0x@server:~$ sudo zpool replace tank raidz1-0 sdd /dev/disk/by-id/ata-WDC_WD40EFRX-REPL
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Tue Dec 24 11:31:18 2025
2.14T scanned at 512M/s, 1.02T issued at 244M/s, 12.3T total
0B resilvered, 8.32% done, 11:42:10 to goInterprétation : Le resilver RAIDZ est une reconstruction, pas une simple copie, et peut être plus lent et plus stressant. Si vous êtes déjà en RAIDZ1 sur de gros disques, le temps de resilver est votre ennemi ; considérez la période dégradée comme une fenêtre à haut risque.
Task 11: Identify and interpret a “too many errors” situation
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 14
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/projects/build-cache.binInterprétation : C’est une classe d’urgence différente : ZFS vous dit qu’il y a des erreurs permanentes dans un objet spécifique. Cela signifie que la redondance n’était pas suffisante au moment de la lecture/réparation, ou que la corruption existait sur suffisamment de répliques. Votre prochaine étape est de restaurer ce fichier (ou dataset) depuis une source connue bonne, puis d’investiguer pourquoi les CKSUM errors se sont produites.
Task 12: Find which dataset and mountpoint own the damaged file
cr0x@server:~$ zfs list -o name,mountpoint
NAME MOUNTPOINT
tank /tank
tank/projects /tank/projectsInterprétation : Quand ZFS reporte un chemin, confirmez qu’il correspond au dataset attendu. Dans des environnements complexes avec des datasets imbriqués, cela vous aide à cibler l’impact et à choisir entre restaurer un seul fichier, un snapshot de dataset, ou quelque chose de plus large.
Task 13: Correlate pool health with recent kernel/storage events
cr0x@server:~$ sudo dmesg -T | tail -n 30
[Tue Dec 24 11:05:02 2025] ata9: hard resetting link
[Tue Dec 24 11:05:03 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 11:05:04 2025] sd 9:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Tue Dec 24 11:05:04 2025] blk_update_request: I/O error, dev sdb, sector 128Interprétation : Les réinitialisations de lien et les timeouts incriminent souvent le câblage, le backplane, ou le contrôleur autant que le disque. Si plusieurs disques derrière le même HBA montrent des resets au même moment, suspectez d’abord le composant partagé.
Task 14: Check ashift and vdev layout when performance is weird
cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree|type' -n | head -n 30
56: vdev_tree:
57: type: 'root'
73: type: 'mirror'
91: ashift: 12
118: ashift: 12Interprétation : ashift: 12 signifie secteurs 4K (2^12). Un ashift mal aligné peut causer une amplification d’écriture chronique. Vous ne pouvez pas changer ashift in-place pour des vdevs existants ; corriger ça demande une reconstruction/recréation, d’où l’importance de le diagnostiquer tôt.
Task 15: Validate that you’re using stable device IDs (prevent future “UNAVAIL” drama)
cr0x@server:~$ sudo zpool status tank | awk '/^ *[a-z]/{print $1}' | head
tank
mirror-0
sda
sdbcr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb' | head
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sda
lrwxrwxrwx 1 root root 9 Dec 24 10:01 ata-HGST_HUS726T4... -> ../../sdbInterprétation : Si votre pool est construit sur /dev/sdX, vous comptez sur l’ordre de découverte pour rester stable. C’est acceptable jusqu’au jour où ça ne l’est plus. Planifiez une fenêtre de maintenance pour remplacer les références par-id par des chemins by-id quand possible (souvent fait pendant les remplacements de disques, feuille par feuille).
Trois mini-récits du monde corporate (comment ça casse vraiment)
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Ils avaient une configuration “simple” : deux vdevs de niveau supérieur, chacun un RAIDZ1 de gros disques, mis en stripe dans un pool. La capacité avait fière allure dans un slide. L’hypothèse—partagée silencieusement entre les équipes—était que “perdre un disque c’est ok.” C’était vrai dans un sens étroit : perdre un disque par vdev RAIDZ1 est survivable.
Le premier disque est tombé un lundi matin. zpool status a indiqué DEGRADED, et l’équipe a agi vite : nouveau disque commandé (bien), remplacement planifié (bien), et un resilver a démarré en fin d’après-midi (aussi bien). Pendant le resilver, un deuxième disque dans l’autre vdev RAIDZ1 a commencé à lancer des CKSUM errors—rien de dramatique au début, juste un petit nombre qui ressemblait à du “bruit.” Quelqu’un a effacé les erreurs pour rendre le tableau de bord vert, parce que personne n’aime une case rouge dans la revue hebdomadaire.
Mardi, les erreurs du deuxième disque n’étaient plus du bruit. Sous la charge de reconstruction, des composants marginaux cessent d’être polis. Le disque est tombé, le deuxième vdev est devenu DEGRADED, et maintenant le pool n’était plus qu’à une défaillance d’une catastrophe—à travers deux vdevs différents. Un job batch a démarré (sans rapport, planifié et innocent), l’I/O a grimpé, et un troisième disque a eu un hoquet suffisamment long pour devenir UNAVAIL. C’en était fini : le pool a faulted parce qu’un vdev de niveau supérieur est devenu indisponible, et le pool ne vit que tant que son vdev le moins disponible le permet.
Le postmortem fut douloureux mais productif. La mauvaise hypothèse n’était pas “RAIDZ1 survit à un disque”, mais traiter le pool comme s’il avait un budget de parité unique. Dans un pool stripe, la parité est locale à chaque vdev ; les risques s’additionnent. La correction n’a pas été un script héros. Ce fut une correction de design : RAIDZ2 pour gros disques, scrubs réguliers, et traiter les CKSUM errors comme un incident de première classe, pas comme une métrique à effacer.
Mini-récit 2 : L’optimisation qui se retourne contre eux
Une autre entreprise, un autre péché : ils ont ajouté un device SLOG pour “accélérer les écritures.” La charge était un mix de bases de données et d’ingestion de logs, et quelqu’un avait lu suffisamment pour savoir “les écritures sync sont lentes ; SLOG aide.” Vrai, parfois. Ils ont installé un NVMe grand public parce qu’il avait de bons benchmarks et que l’achat n’aimait pas les prix “enterprise”.
Une semaine, les graphiques étaient superbes. La latence a chuté. L’équipe s’est félicitée et est passée à autre chose. Puis un événement d’alimentation a frappé le rack—rien de dramatique, juste un brownout rapide et une reprise. Les systèmes sont revenus, mais le pool n’était pas content. zpool status a montré le log vdev en FAULTED, et pire, le pool a refusé de s’importer proprement sur un nœud. Le “NVMe rapide” n’avait pas de protection contre la perte d’alimentation ; il acceptait des écritures qui ne furent jamais rendues durables.
C’est là que zpool status se lit comme un coroner : le log vdev n’était pas juste un “cache optionnel.” Pour les charges sync, le ZIL/SLOG fait partie du chemin transactionnel. Un SLOG qui ment peut transformer un crash propre en problème de cohérence. La récupération a impliqué de retirer et remplacer le device log, rejouer ce que ZFS pouvait, et valider l’intégrité au niveau applicatif. L’issue n’a pas été une perte totale de données, mais c’était le genre d’incident qui brûle la confiance.
La leçon qu’ils ont écrite (et finalement crue) : les améliorations de performance sont des changements au modèle de défaillance. Un device SLOG doit être traité comme une petite base de données : haute endurance, protection perte d’alim, et redondance si la plateforme le permet. Ils ont ensuite testé avec des coupures d’alimentation intentionnelles en labo. L’“optimisation” était réelle, mais seulement quand elle était conçue pour la production, pas pour un benchmark.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Le troisième récit n’est pas glamour. Il parle d’une équipe qui exécutait des scrubs mensuels, passait en revue les sorties de zpool status dans le cadre de l’hygiène on-call, et remplaçait les disques aux premiers signaux d’alerte au lieu d’attendre la panne complète. Ils gardaient aussi un petit stock de disques de remplacement identiques sur site. Personne n’a mis ça dans un communiqué de presse.
Un mois, un scrub a rapporté quelques erreurs de checksum réparées sur un seul disque. Le pool est resté ONLINE, et errors: No known data errors paraissait rassurant. Mais l’équipe a traité “repaired” comme “quelque chose a effectivement mal tourné.” Ils ont corrélé avec les logs kernel et trouvé des réinitialisations intermittentes de lien sur la même baie. Ils ont déplacé le disque vers une autre baie pendant une fenêtre planifiée ; les erreurs ont suivi la baie, pas le disque. C’est le genre de fait qu’on n’obtient que si on prend la peine de regarder.
Ils ont remplacé le connecteur du backplane et réinstallé les câbles. Puis ils ont lancé un autre scrub. Propre. Les compteurs d’erreurs sont restés à zéro. Un mois plus tard, un autre disque a échoué complètement—usure normale. Le pool s’est dégradé, un remplacement a été inséré, le resilver a été complété, et le business n’a rien remarqué.
La décision salvatrice n’était pas géniale. C’était la discipline ennuyeuse de scrubs, de revue et d’action sur des signaux faibles pendant que le système restait coopératif. Dans la vie en entreprise, la correction ennuyeuse est souvent la plus haute forme de compétence, et elle est rarement récompensée jusqu’au jour où elle prévient une panne.
Erreurs courantes (avec symptômes et corrections)
Mistake 1: Treating CKSUM errors as “disk is bad, replace it” without checking the path
Symptômes : CKSUM incrémente sur un ou plusieurs disques ; READ/WRITE restent proches de zéro ; les disques passent les checks SMART basiques ; les erreurs corrèlent avec des pics de charge ou des mouvements de câbles.
Correction : Vérifiez dmesg pour des réinitialisations/timeouts de lien ; inspectez/remplacez les câbles SATA/SAS ; réenfoncez les disques ; vérifiez la stabilité du firmware/driver HBA. Si les erreurs suivent la baie ou le port du contrôleur plutôt que le disque, ne perdez pas de temps à RMA des disques innocents.
Mistake 2: Clearing errors to make monitoring green
Symptômes : zpool clear a été lancé à répétition ; les compteurs reviennent ; personne ne peut répondre à “quand ça a commencé ?”
Correction : Conservez les preuves. Capturez zpool status -vP, les logs pertinents et les timestamps avant d’effacer. Effacez seulement après avoir traité la cause probable et de préférence après qu’un scrub confirme la stabilité.
Mistake 3: Building pools on /dev/sdX and acting surprised when devices move
Symptômes : Après un reboot ou un changement matériel, un disque apparaît UNAVAIL bien qu’il soit présent ; les lettres de périphériques ont changé ; l’import devient confus.
Correction : Utilisez /dev/disk/by-id de manière cohérente. Si vous avez hérité d’un pool construit sur sdX, planifiez de “migrer” les périphériques feuilles lors de remplacements en utilisant les chemins by-id dans zpool replace.
Mistake 4: Assuming RAIDZ resilver is “just copying” and scheduling it during peak hours
Symptômes : Le resilver prend beaucoup plus de temps que prévu ; la latence applicative explose ; un autre disque commence à lancer des erreurs sous stress.
Correction : Traitez le resilver RAIDZ comme un travail lourd de reconstruction. Réduisez la charge concurrente si possible, planifiez des fenêtres de rebuild, et envisagez d’ajouter de la redondance (RAIDZ2) pour les gros disques où les fenêtres de reconstruction sont longues.
Mistake 5: Misunderstanding “No known data errors” as “no problem”
Symptômes : Le pool reste ONLINE, mais READ/WRITE/CKSUM comptent augmentent ; des scrubs réparent des données occasionnellement ; erreurs applicatives intermittentes.
Correction : Étudiez la tendance. Un bloc réparé n’est pas une crise, mais c’est un signal. Lancez un scrub, vérifiez les logs, et suivez si les erreurs se concentrent sur un seul périphérique ou chemin.
Mistake 6: Adding a special vdev or SLOG without redundancy or validation
Symptômes : Après la perte d’un périphérique, le pool devient inutilisable ou subit un effondrement de performance sévère ; problèmes d’import inattendus ; charges metadata-heavy à l’arrêt.
Correction : Les vdevs spéciaux devraient être redondants s’ils contiennent des métadonnées/petits blocs dont le pool dépend. Le SLOG doit être sûr face à la perte d’alimentation et adapté aux charges d’écritures sync. Validez les scénarios de défaillance en labo.
Listes de contrôle / plan pas-à-pas
Checklist A: When you see DEGRADED
- Capturez les preuves : sortie
zpool status -vPet timestamps. - Identifiez le niveau dégradé : disque feuille, mirror/raidz vdev, ou vdev de niveau supérieur.
- Vérifiez les compteurs : sont-ce des erreurs READ/WRITE (I/O) ou CKSUM (intégrité/chemin) ?
- Confirmez la visibilité OS :
lsblketdmesgpour resets/timeouts. - Si le périphérique est présent mais offline/unavail : tentez un
zpool onlineune fois après stabilisation du câblage/alimentation. - Si le périphérique est véritablement en échec :
zpool replaceavec un chemin by-id stable. - Surveillez le resilver dans
zpool status; guettez de nouvelles erreurs sur d’autres disques. - Après resilver : lancez un scrub pendant une fenêtre contrôlée.
- Ce n’est qu’ensuite : envisagez
zpool clearpour réinitialiser les compteurs pour la détection future.
Checklist B: When you see CKSUM errors but pool is ONLINE
- Ne remplacez pas le matériel à l’aveugle. D’abord, capturez
zpool status -vP. - Vérifiez si plusieurs disques derrière un même HBA/expander montrent des incréments CKSUM.
- Inspectez
dmesg -Tpour resets de lien, erreurs de bus, ou timeouts. - Réinstallez/remplacez les câbles ; réenfoncez le disque ; essayez une autre baie.
- Lancez un scrub pour forcer la vérification et la réparation :
zpool scrub. - Si CKSUM persiste sur le même disque après remédiation du chemin : remplacez le disque.
Checklist C: When performance is bad but pool looks healthy
- Confirmez qu’aucun scrub/resilver n’est en cours : ligne scan de
zpool status. - Vérifiez l’activité pool/vdev :
zpool iostat -v 1. - Cherchez un disque lent qui déséquilibre un vdev : ops/bw inégales dans iostat.
- Vérifiez la pression d’écritures sync : comportement applicatif et paramètres dataset ZFS (sync, logbias).
- Validez ashift et la disposition :
zdb -Cpour ashift et hypothèses de design vdev. - Ensuite seulement envisagez des “améliorations de performance” (SLOG, vdev spécial, plus de vdevs)—et modélisez d’abord l’impact en cas de défaillance.
FAQ
1) If the pool is DEGRADED, is my data already corrupted?
Pas nécessairement. DEGRADED signifie généralement que la redondance est réduite (un disque manquant/faulted) mais que les données peuvent encore être servies depuis les répliques/parité restantes. Le risque est qu’une seconde défaillance dans le même vdev puisse entraîner une perte de données ou la perte du pool, selon la disposition.
2) What’s the difference between READ/WRITE errors and CKSUM errors?
Les READ/WRITE errors sont des échecs I/O : le périphérique n’a pas complété l’opération. Les CKSUM errors signifient que ZFS a reçu des données mais qu’elles ne correspondent pas au checksum attendu—souvent impliquant une corruption en transit, un firmware, ou un média qui renvoie de mauvaises données.
3) Can I just run zpool clear to fix a degraded pool?
Non. zpool clear efface les compteurs d’erreurs et certains états d’erreurs ; il ne ressuscite pas des disques manquants ni ne répare les causes sous-jacentes. Utilisez-le après avoir corrigé le problème et vouloir des compteurs neufs pour le monitoring.
4) Why does zpool status show “No known data errors” when counters are non-zero?
Parce que les compteurs peuvent refléter des erreurs transitoires qui ont été récupérées via la redondance ou des erreurs qui n’ont pas entraîné de corruption permanente. C’est néanmoins un signal qu’il y a de l’instabilité et qu’il faut enquêter.
5) Should I replace a disk as soon as I see any errors?
Remplacez immédiatement pour les READ/WRITE errors persistantes ou un disque qui tombe hors ligne. Pour des CKSUM isolées, suspectez d’abord le câblage/backplane/HBA et vérifiez avec les logs et un scrub. Remplacez le disque si les erreurs persistent après remédiation du chemin.
6) Why is my RAIDZ resilver so slow?
Le resilver RAIDZ peut impliquer la reconstruction de la parité sur de nombreux blocs, et il concurrence la charge live. La fragmentation et les petits blocs aggravent le phénomène. Les mirrors resilveront généralement plus vite car ils copient depuis une réplique survivante.
7) What does “too many errors” mean in zpool status?
ZFS a jugé qu’un périphérique est suffisamment peu fiable pour le faulter. Cela peut être dû à des échecs I/O répétés, des timeouts, ou des événements de corruption. La bonne réponse est d’identifier si le disque est défaillant ou si le chemin l’est, puis remplacer/réparer en conséquence.
8) Is it safe to hot-swap drives while the pool is online?
Souvent oui, si votre matériel et OS le supportent et que votre procédure est rigoureuse. Le risque n’est pas seulement l’échange—c’est identifier le mauvais disque, retirer le mauvais, ou déclencher un backplane défaillant dans une panne plus large. Vérifiez les chemins by-id avant de retirer quoi que ce soit.
9) If zpool status lists a specific file with permanent errors, what should I do?
Considérez cela comme une perte de données pour cet objet. Restaurez le fichier depuis une source connue bonne (sauvegarde, réplication, reconstruction d’artifact), puis scrubez et investiguez pourquoi la redondance n’a pas pu le guérir (erreurs sur plusieurs périphériques, corruption antérieure, ou redondance insuffisante).
Conclusion
zpool status n’est pas un test de bonne humeur. C’est une preuve. La topologie vous dit ce qui peut tomber en panne. Les états vous disent ce qui est déjà tombé en panne. Les compteurs vous disent comment ça a échoué. Et la ligne scan vous dit ce que ZFS est en train d’en faire.
Lisez-le comme un analyste médico-légal et vous arrêterez de deviner. Vous saurez quand un disque meurt, quand un câble ment, quand un scrub est en retard, et quand une “amélioration de performance” a discrètement réécrit votre modèle de défaillance. En production, c’est la différence entre une maintenance de routine et une leçon très coûteuse.