À 02:17, quelqu’un demande : « Le stockage affiche des erreurs. Je peux juste exécuter zpool clear ? » C’est l’équivalent UNIX de demander si on peut arrêter l’alarme incendie en enlevant la pile. Parfois c’est acceptable. Parfois c’est la manière de transformer une panne récupérable en un événement qui ruine une carrière.
zpool clear n’est pas magique, et ce n’est pas de la maintenance. C’est un balai. Servez-vous-en pour nettoyer des dégâts connus et déjà corrigés. Ne l’utilisez pas pour masquer une plomberie cassée.
Ce que zpool clear fait réellement (et ce qu’il ne fait pas)
zpool clear remet à zéro les compteurs d’erreurs et certains états de faute enregistrés par ZFS pour un pool ou un vdev spécifique. C’est tout. Il ne « répare pas les données ». Il ne « répare pas le disque ». Il ne « retire pas la corruption ». Il ne garantit même pas que le pool restera sain les cinq minutes suivantes.
Considérez ZFS comme ayant deux couches de vérité :
- Réalité physique : ce que les disques, HBA, expanders, câbles, backplanes et contrôleurs peuvent réellement fournir.
- Observation enregistrée : ce que ZFS a observé (erreurs, tentatives, mismatches de checksum) et comptabilisé.
zpool clear réinitialise l’observation enregistrée. Il n’affecte pas la réalité physique. Si la réalité physique est toujours défaillante, ZFS recommencera simplement le comptage — souvent immédiatement, parfois quelques secondes après la réinitialisation. Si vous effacez et que les compteurs restent à zéro sous charge, vous avez probablement corrigé quelque chose et vous rendez le statut du pool lisible à nouveau. Si vous effacez et que les compteurs remontent en flèche, vous venez de confirmer un problème actif.
De plus : effacer peut faire passer un pool de DEGRADED/FAULTED à ONLINE si le périphérique sous-jacent redevient accessible et que la faute était transitoire. C’est pratique. C’est aussi la manière dont on « prouve » par erreur qu’un chemin instable est bon parce qu’il a marché une minute.
Le rôle des compteurs d’erreurs dans les opérations ZFS
ZFS utilise des compteurs par vdev (READ, WRITE, CKSUM) et des machines d’état (ONLINE, DEGRADED, UNAVAIL, FAULTED) pour aider à répondre à deux questions :
- Les données sont-elles en danger maintenant ?
- Si oui, s’agit‑il d’un problème de périphérique, de chemin ou d’une vraie corruption sur disque ?
Effacer les compteurs est une étape d’hygiène après avoir répondu aux deux questions et atténué la cause. Ce n’est pas la première étape.
Idée paraphrasée, attribuée : « L’espoir n’est pas une stratégie. »
— souvent citée par les praticiens de la fiabilité/opérations (idée paraphrasée).
Faits et contexte utiles en salle de guerre
- ZFS a été conçu pour détecter la corruption silencieuse — la classe de bugs et de flips de bits que votre contrôleur RAID ignore joyeusement tout en renvoyant « succès ». C’est pour cela que les erreurs de checksum importent plus qu’une bannière « degraded » qui fait peur.
- Le checksum de bout en bout n’était pas courant quand ZFS a été conçu au début des années 2000 ; ZFS a poussé l’idée que le stockage doit vérifier ce qu’il sert, pas seulement ce qu’il stocke.
- Le concept de « scrub » est volontairement proactif : c’est un travail planifié « lire tout et vérifier », pas un fsck réactif après un crash. C’est ainsi que ZFS trouve les secteurs dégradés avant que vous n’en ayez besoin.
- Les compteurs READ/WRITE/CKSUM sont par vdev et persistants à travers les redémarrages jusqu’à effacement. Cette persistance est utile pour repérer les tendances et terrible pour les gens qui paniquent devant des chiffres anciens.
- Un seul mismatch de checksum ne signifie pas automatiquement une perte de données sur des vdevs redondants (mirror/raidz). Cela signifie souvent que ZFS a détecté une mauvaise copie et l’a réparée à partir d’une bonne — vous a sauvé discrètement.
- La « gestion des fautes » de ZFS s’est inspirée de la pensée serviceability : il essaie de vous indiquer quel composant remplacer, pas seulement que « quelque chose ne va pas ». C’est utile, mais pas omniscient face aux câbles et aux backplanes.
- Beaucoup d’« erreurs disque » sont en réalité des problèmes de transport : réinitialisations de liens SATA/SAS, expanders marginaux, disques mal enfoncés, problèmes d’alimentation. ZFS ne peut pas deviner qu’un câble boude.
- Sur les piles dérivées de Solaris, FMA s’intégrait à ZFS. Sur Linux, vous avez un écosystème différent (ZED, udev, logs noyau), donc le diagnostic nécessite souvent de corréler les sources.
- L’arrivée de gros disques bon marché a rendu les erreurs de secteurs latentes opérationnelles. Les scrubs et la planification de la redondance sont devenus indispensables à mesure que les temps de rebuild augmentaient et que les probabilités d’URE devenaient défavorables.
Interpréter READ/WRITE/CKSUM comme un adulte
zpool status vous donne trois compteurs par périphérique :
- READ : le périphérique a retourné une erreur I/O en lecture, a expiré, ou a échoué à fournir des blocs.
- WRITE : le périphérique a échoué à écrire des blocs (ou à accuser réception des écritures).
- CKSUM : le périphérique a retourné des données, mais ZFS a calculé un mismatch de checksum — les données reçues ne correspondent pas à ce qui avait été écrit.
En pratique :
- Les erreurs READ/WRITE pointent souvent vers un périphérique incapable d’effectuer des I/O de façon fiable, ou vers un problème de chemin (HBA, expander, câble, alimentation). Elles apparaissent généralement dans les logs du noyau. Elles peuvent faire passer des vdevs hors ligne.
- Les erreurs CKSUM sont la catégorie « silencieusement terrifiante ». Elles peuvent être causées par un disque mourant, oui. Elles peuvent aussi venir d’un transport instable, d’une RAM défaillante (moins fréquent avec ECC mais possible), d’un firmware bizarre, ou de contrôleurs qui font des choses « utiles ». ZFS vous dit : j’ai reçu des octets, mais je ne leur fais pas confiance.
Ce que vous devez mentalement associer des compteurs aux actions
Voici un guide de terrain qui correspond à ce que font les ingénieurs expérimentés enastreinte, pas à ce qu’ils affirment faire :
- CKSUM sur un seul disque, petit compteur, n’augmente plus : probablement un événement transitoire ou réparé. Lancer un scrub, corréler les logs, puis effacer si vous avez remédié (reseat, remplacer câble, mise à jour firmware, etc.).
- CKSUM qui augmente pendant un scrub ou sous charge : problème d’intégrité actif. Ne pas effacer. Trouver le composant. Remplacer des éléments jusqu’à ce que le compteur arrête d’augmenter.
- Erreurs READ/WRITE avec réinitialisations/expirations : traiter comme une instabilité du chemin/périphérique. ZFS peut continuer à servir, mais votre budget de résilience fond.
- Erreurs sur plusieurs disques derrière un même HBA/expander : ne lancez pas une frénésie de remplacements de disques. C’est comme ça qu’on obtient « nouveaux disques, mêmes erreurs ». Suspectez l’infrastructure partagée.
Quand il est correct d’effacer les erreurs
zpool clear est approprié lorsque l’état d’erreur est périmé, que la cause sous-jacente a été traitée, et que vous avez besoin de compteurs propres pour vérifier la stabilité à venir.
Utilisez-le après avoir réparé quelque chose de mesurable
Bonnes raisons :
- Vous avez remplacé un disque défectueux, le resilver est terminé et le pool est sain mais affiche encore d’anciens compteurs. Effacez pour remettre le tableau à zéro.
- Vous avez reseaté un disque ou remplacé un câble/backplane SATA/SAS, et vous voulez vérifier que les erreurs ne réapparaissent pas pendant un scrub.
- Vous avez eu un événement d’alimentation ponctuel (hiccup PDU, perte de puissance du châssis) qui a causé des erreurs I/O transitoires ; après avoir confirmé la stabilité matérielle, effacez pour éviter de vivre avec la « honte historique ».
- Vous avez corrigé une mauvaise configuration (firmware incorrect, mode contrôleur, configuration multipath) et vous voulez prouver la correction en surveillant les compteurs sous charge.
Utilisez-le pour rendre la supervision sensée à nouveau
Beaucoup de systèmes de supervision déclenchent des alertes sur des compteurs d’erreurs non nuls. Si vous avez fait le travail — scrub, remédiation, validation — laisser des compteurs antiques en place habitue votre organisation à ignorer les alertes. Effacer devient une remise à zéro opérationnelle : « à partir de ce moment, les nouvelles erreurs signifient de nouveaux incidents. »
Utilisez-le sur un périphérique spécifique quand vous isolez
Effacer le pool entier peut supprimer un contexte judiciaire utile. Préférez :
zpool clear poolnamequand vous avez fini et souhaitez tout réinitialiser.zpool clear poolname /dev/disk/by-id/...quand vous suivez un suspect et voulez un nouveau compteur pour ce chemin précis.
Quand il est stupide d’effacer les erreurs
Effacer les erreurs est stupide quand vous n’avez pas prouvé que le pool est stable, ou quand vous l’utilisez pour faire taire des symptômes au lieu de diagnostiquer la cause.
Ne pas effacer tant que les erreurs continuent d’augmenter
Si un scrub est en cours et que CKSUM augmente, effacer revient à changer le compteur kilométrique pendant que le moteur brûle. Vous perdrez la capacité de quantifier « à quel point » et « à quelle vitesse ». Gardez les chiffres. Ce sont des preuves.
Ne pas effacer pour « réparer » une corruption de données
Parfois zpool status affiche errors: Permanent errors have been detected. Ce n’est pas un problème de compteurs. C’est ZFS qui vous dit qu’il a trouvé des blocs qu’il n’a pas pu réparer à partir de la redondance. Effacer ne ressuscite pas les données. Cela cache l’avertissement jusqu’à ce qu’une lecture ultérieure déclenche la même douleur, mais côté application et plus coûteuse.
Ne pas effacer pour rendre un pool dégradé verdoyant
Un pool en DEGRADED a déjà consommé de la redondance. Si vous effacez et déclarez victoire sans remplacer le composant défaillant, vous pariez que le reste du vdev se comportera. Ce pari est statistiquement populaire et professionnellement regrettable.
Ne pas effacer avant d’avoir capturé le contexte
Effacer supprime la piste de miettes. Avant d’effacer, capturez :
zpool status -vzpool events -v(si disponible)- Les logs du noyau autour du moment où les erreurs se sont produites
smartctlpour les disques concernés
Première blague (courte, pertinente) : Effacer les erreurs ZFS sans diagnostic, c’est comme redémarrer le détecteur de fumée. Vous n’avez pas éteint le feu ; vous l’avez juste rendu plus discret.
Feuille de route pour un diagnostic rapide
Quand vous êtes en astreinte, vous n’avez pas le loisir d’entretenir une relation philosophique avec votre stockage. Voici comment arriver rapidement à « qu’est-ce qui est cassé ».
Première étape : établir si c’est actif ou historique
- Vérifiez
zpool statuset notez si les compteurs augmentent dans le temps. - Si un scrub/resilver est en cours, observez si les erreurs croissent pendant cette activité.
Deuxième étape : classer le mode de panne (périphérique vs chemin vs données)
- Si ce sont majoritairement des READ/WRITE avec timeouts dans les logs → suspecter un périphérique ou transport.
- Si c’est du CKSUM sans erreurs I/O → suspecter une corruption en transit (câble/HBA/expander/RAM) ou un disque renvoyant de mauvaises données.
- Si
Permanent errorsapparaît → traiter comme un événement de perte de données jusqu’à preuve du contraire.
Troisième étape : chercher un rayon d’impact partagé
- Les erreurs touchent-elles plusieurs disques sur le même HBA/port/expander ? C’est un composant partagé.
- Les erreurs touchent-elles un seul disque ? C’est généralement le disque, son emplacement ou son câble.
Quatrième étape : décider si vous pouvez continuer à servir
- vdev redondant, erreurs sur un seul périphérique, scrub qui répare proprement : vous pouvez souvent continuer à servir tout en planifiant un remplacement.
- vdev non redondant ou plusieurs périphériques du même RAIDZ qui posent problème : arrêtez de parier. Stabilisez d’abord.
Tâches pratiques : commandes, sorties, décisions
Ci‑dessous des tâches opérationnelles réelles à exécuter. Chaque entrée inclut : commande, ce que la sortie signifie, et la décision associée.
Task 1: Get the headline status (don’t squint)
cr0x@server:~$ sudo zpool status
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
scan: scrub repaired 0B in 02:41:13 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 UNAVAIL 8 2 0 cannot open
errors: Permanent errors have been detected in the following files:
tank/data/finance.dbCe que cela signifie : Ce n’est pas « seulement des compteurs ». Vous avez un disque indisponible et ZFS signale des erreurs permanentes sur un fichier précis.
Décision : Ne lancez pas zpool clear comme premier geste. Stabilisez le matériel (ramener le disque / remplacer), puis traitez le fichier corrompu (restauration depuis un réplica/sauvegarde ou reconstruction au niveau application).
Task 2: Get verbose detail on errors and files
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
scan: scrub repaired 0B in 02:41:13 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 UNAVAIL 8 2 0 cannot open
errors: Permanent errors have been detected in the following files:
tank/data/finance.dbCe que cela signifie : ZFS pointe vers un chemin de dataset spécifique. C’est exploitable.
Décision : Impliquez le propriétaire de l’application. Déterminez si le fichier peut être restauré ou reconstruit. Les travaux matériels et de données doivent avancer en parallèle.
Task 3: Confirm the disk is actually missing vs renamed
cr0x@server:~$ ls -l /dev/disk/by-id/ | grep JKL012
Ce que cela signifie : Pas de sortie suggère que l’OS ne voit pas du tout le périphérique (débranché, mort, lien bas, problème de contrôleur).
Décision : Vérifiez câblage/backplane/HBA. Si c’est une baie hot-swap, reseatez le disque. Si c’est une VM, vérifiez l’attachement du disque virtuel.
Task 4: Correlate with kernel logs (transport vs media)
cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|timeout|I/O error" | tail -n 20
[Wed Dec 24 02:01:44 2025] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x4050000 action 0x6 frozen
[Wed Dec 24 02:01:44 2025] ata9: SError: { CommWake DevExch }
[Wed Dec 24 02:01:45 2025] ata9.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 02:01:45 2025] blk_update_request: I/O error, dev sdi, sector 918273645 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Wed Dec 24 02:01:47 2025] ata9: hard resetting link
[Wed Dec 24 02:01:52 2025] ata9: link is slow to respond, please be patient (ready=0)
[Wed Dec 24 02:01:57 2025] ata9: SATA link down (SStatus 0 SControl 300)Ce que cela signifie : Les réinitialisations de lien et les liens tombés crient « transport/chemin » plus que « mauvais secteur ». Le disque peut encore être sain ; c’est le chemin qui est en faute.
Décision : Inspectez/replacez le câble, le port du backplane, ou la voie HBA. Ne remplacez pas le disque en premier sauf si vous avez d’autres preuves.
Task 5: Pull SMART to see if the disk is sick
cr0x@server:~$ sudo smartctl -a /dev/sdi | egrep -i "Reallocated|Pending|Uncorrect|CRC|SMART overall|Power_On_Hours" -n
5:SMART overall-health self-assessment test result: PASSED
83: 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
88:197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
89:198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0
102:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 47
109: 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 46712Ce que cela signifie : De nombreux CRC sans réallocations/pending sectors pointe vers du bruit sur le câble/backplane/contrôleur. Le média disque ne semble pas visiblement mauvais.
Décision : Réparez le chemin. Ensuite scrub. Puis envisagez d’effacer les compteurs.
Task 6: Identify which physical bay a by-id maps to
cr0x@server:~$ sudo lsblk -o NAME,SERIAL,MODEL,HCTL,SIZE,STATE | grep -E "sdi|JKL012"
sdi WD-JKL012 WDC WD80EFAX-68LHPN0 3:0:9:0 7.3T runningCe que cela signifie : HCTL vous donne host:channel:target:lun, utile avec des HBAs SAS et le mapping du châssis.
Décision : Utilisez HCTL et votre carte du châssis pour toucher le bon disque. Évitez le classique « on enlève le mauvais disque ».
Task 7: Confirm pool topology and ashift (future pain predictor)
cr0x@server:~$ sudo zpool get ashift,autoreplace,autotrim tank
NAME PROPERTY VALUE SOURCE
tank ashift 12 local
tank autoreplace off default
tank autotrim off defaultCe que cela signifie : ashift=12 correspond à des secteurs 4K ; correct. autoreplace=off signifie que remplacer un disque peut nécessiter des étapes explicites. autotrim off est typique pour les pools HDD.
Décision : Si vous attendez un comportement hot-swap, décidez si vous voulez activer autoreplace après avoir compris votre environnement. Ne le touchez pas en pleine incidentologie sauf si vous aimez les surprises.
Task 8: Run a scrub and watch whether counters increase
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Wed Dec 24 04:01:10 2025
1.23T scanned at 1.4G/s, 212G issued at 245M/s, 7.98T total
0B repaired, 2.59% done, 08:31:12 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 0
errors: No known data errorsCe que cela signifie : Le scrub progresse, le pool est stable, aucun compteur n’augmente. C’est un bon signe.
Décision : Si cela suit une remédiation (reseat/remplacement de câble), vous approchez du territoire « sûr pour effacer » une fois le scrub terminé.
Task 9: Check scrub result and repaired bytes
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 12M in 02:39:44 with 0 errors on Wed Dec 24 06:41:02 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 3
raidz1-0 ONLINE 0 0 3
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 3
errors: No known data errorsCe que cela signifie : Le scrub a réparé 12M (auto-réparé), mais le disque affiche encore des erreurs de checksum. Si ces erreurs sont historiques et n’augmentent pas, vous pouvez effacer après vous être assuré que la cause sous-jacente est corrigée.
Décision : Corrélez avec les logs durant le scrub. Si pas de nouvelles réinitialisations/timeouts et que SMART CRC cesse d’augmenter, effacez et surveillez.
Task 10: Clear a single device (surgical reset)
cr0x@server:~$ sudo zpool clear tank ata-WDC_WD80EFAX-68LHPN0_WD-JKL012
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 12M in 02:39:44 with 0 errors on Wed Dec 24 06:41:02 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 0
errors: No known data errorsCe que cela signifie : Les compteurs sont réinitialisés. Vous avez maintenant une référence propre.
Décision : Mettez le pool sous charge normale et revérifiez dans quelques heures/jours. Si les compteurs réapparaissent, la correction n’a pas tenu.
Task 11: Use zpool events to see recent ZFS fault activity
cr0x@server:~$ sudo zpool events -v | tail -n 25
TIME CLASS
Dec 24 2025 02:01:58.219388000 ereport.fs.zfs.io
vdev_path: /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_WD-JKL012
vdev_guid: 1234567890123456789
pool: tank
pool_guid: 9876543210987654321
ereport_payload:
zio_err: 5
zio_offset: 469124961280
zio_size: 131072
zio_objset: 54
zio_object: 1
zio_level: 0Ce que cela signifie : ZFS a journalisé un ereport I/O pour ce vdev. L’horodatage aide à corréler avec les logs noyau et les événements physiques.
Décision : Si les events s’arrêtent après remédiation, vous gagnez. S’ils continuent, escaladez pour isolation matérielle.
Task 12: Confirm the pool isn’t silently re-silvering or stuck
cr0x@server:~$ sudo zpool status -D tank
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
ata-WDC...JKL012 ONLINE 0 0 0
errors: No known data errorsCe que cela signifie : Aucun scan en cours, rien de différé.
Décision : Si vous attendiez un resilver et que vous ne le voyez pas, vous avez peut‑être remplacé la mauvaise chose ou ZFS n’a pas attaché le nouveau disque comme vous le pensiez.
Task 13: Replace a disk correctly (and avoid clearing too early)
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_WD-MNO345
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Wed Dec 24 07:10:04 2025
612G scanned at 1.1G/s, 118G issued at 211M/s, 7.98T total
118G resilvered, 1.44% done, 06:10:22 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
replacing-3 DEGRADED 0 0 0
ata-WDC...JKL012 UNAVAIL 0 0 0 cannot open
ata-WDC...MNO345 ONLINE 0 0 0 (resilvering)Ce que cela signifie : Le resilver est actif ; ZFS reconstruit la redondance sur le nouveau disque.
Décision : N’effacez pas pendant un resilver sauf si vous effacez des erreurs périmées après une résolution transitoire et que vous avez capturé des preuves. Laissez le resilver se terminer ; validez ensuite par un scrub.
Task 14: Clear pool-wide after a completed and validated remediation
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: resilvered 7.98T in 06:44:09 with 0 errors on Wed Dec 24 13:54:13 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
ata-WDC...MNO345 ONLINE 0 0 0
errors: No known data errorsCe que cela signifie : Référence propre après un remplacement/resilver réussi.
Décision : Programmez un rappel pour revérifier SMART et zpool status après un jour ouvrable et après le prochain scrub planifié.
Trois mini-récits d’entreprise tirés du réel
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
L’équipe stockage d’une entreprise de taille moyenne exécutait une charge mixte sur un pool RAIDZ2 : lectures analytiques, compactages nocturnes, et quelques datasets « temporaires » qui sont devenus permanents. Un matin, la supervision a commencé à pager sur des erreurs de checksum sur un seul disque. L’ingénieur d’astreinte a vu que le pool était toujours ONLINE et a décidé que c’était du vieux bruit. Il a exécuté zpool clear pour arrêter le spam de pages.
En quelques heures, le compteur de checksum est revenu — rapidement. Mais comme la page avait été « gérée », cela n’a pas eu beaucoup d’attention. La nuit suivante, un gros job de batch a poussé le système plus fort que le trafic diurne, et un second disque du même vdev a commencé à lancer des timeouts de lecture. Le pool est alors passé en DEGRADED. L’équipe a supposé qu’il s’agissait de « deux disques qui lâchent » et a lancé un processus standard de remplacement.
Ce qu’ils ont manqué : les deux disques étaient connectés via le même chemin d’expander SAS, et le firmware de l’expander avait un bug connu lié à la gestion d’alimentation des liens. Les erreurs de checksum initiales étaient un avertissement précoce. L’effacement a effacé la capacité à montrer que les erreurs augmentaient, et a aussi réinitialisé la chronologie des preuves dans les notes d’astreinte parce que personne n’a capturé zpool status -v et les logs d’abord.
Ils ont remplacé un disque. Le resilver a ramé avec des réinitialisations intermittentes. Ils ont remplacé le second disque aussi. Toujours instable. Puis un troisième disque a commencé à avoir des erreurs, et tout le monde a eu la terrible réalisation : ce n’était pas une série de disques défectueux. C’était l’infrastructure partagée.
La correction était ennuyeuse : désactiver le paramètre d’alimentation problématique, mettre à jour le firmware de l’expander lors d’une fenêtre de maintenance, et reseater un mini‑SAS marginal. Après ça, les erreurs ont cessé. Ils ont effacé les compteurs à nouveau — cette fois correctement — et les ont vus rester à zéro. Le coût n’était pas seulement matériel ; c’était la confiance. Les pages stockage ont été ignorées pendant des semaines ensuite, et c’est ainsi que les organisations accumulent des pannes futures comme de la dette de carte de crédit.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une autre organisation souhaitait accélérer les scrubs. Ils avaient un gros pool et une fenêtre de maintenance serrée, donc quelqu’un a ajusté le comportement du scrub au niveau système (les réglages exacts variaient selon la plateforme) et a planifié des scrubs pendant les heures ouvrées « parce que l’array est rapide ». Ça a marché en test.
En production, le scrub plus rapide a augmenté la pression de lecture sur un ensemble de disques vieillissants. Cette pression a exposé un HBA marginal et une piste douteuse sur le backplane. Rien de catastrophique — juste assez de retries et de réinitialisations de lien pour que ZFS commence à journaliser des erreurs de checksum sur plusieurs disques. Le pool est resté online, donc les tickets sont devenus « à surveiller ».
Puis l’équipe a fait la pire chose possible pour leur observabilité : ils effaçaient les erreurs chaque semaine après chaque scrub, parce que la direction n’aimait pas les tableaux de bord en rouge. Avec les compteurs constamment remis à zéro, il est devenu impossible de montrer la tendance qui indiquait que l’environnement se dégradait. Le système d’alerte précoce a été transformé en filtre cosmétique.
Finalement, une charge d’écriture lourde a coïncidé avec un scrub et un hic firmware, provoquant la chute temporaire d’un vdev. Le pool s’est redressé, mais une application a vu des erreurs transitoires et a commencé à reconstruire des index, martelant le stockage encore plus fort. L’incident n’était pas une explosion unique ; c’était une réaction en chaîne alimentée par « l’optimisation ».
Le postmortem a livré une leçon brute : la tuning de performance qui masque les signaux de fiabilité n’est pas une optimisation. C’est de la dette. Ils ont annulé le scrub agressif, déplacé les scrubs vers des fenêtres contrôlées, réparé le matériel partagé, et seulement alors utilisé zpool clear pour réinitialiser les baselines. La performance est revenue. Leur crédibilité aussi.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe de services financiers utilisait ZFS pour des services internes peu excitants. Ils avaient une règle : avant que quiconque exécute zpool clear, il faut attacher trois artefacts au ticket — zpool status -v, un extrait pertinent des logs noyau, et smartctl pour les disques impliqués. Aucune exception, pas de « réparation rapide ».
Un weekend, un pool a commencé à afficher un petit nombre d’erreurs de checksum sur un seul disque. Le système se comportait autrement normalement. L’ingénieur d’astreinte a suivi le rituel, a capturé les preuves, et a remarqué quelque chose de subtil : le rapport SMART montrait des CRC en augmentation, mais reallocated/pending sectors à zéro. Les logs noyau montraient des réinitialisations de lien sur un port spécifique.
Au lieu de remplacer le disque, il a déplacé le disque vers une autre baie et a changé le câble vers le backplane. Ensuite, il a lancé un scrub ; aucune nouvelle erreur n’est apparue. Ce n’est qu’alors qu’il a effacé les compteurs du périphérique. La supervision est restée calme pendant des mois.
Ce qui les a sauvés n’était pas du génie. C’était le refus de laisser « effacer les erreurs » remplacer le diagnostic. Le rituel a produit assez de données pour choisir le bon composant dès la première intervention, pendant une fenêtre de maintenance calme, sans marathon de resilver et sans risquer une seconde défaillance pendant la reconstruction.
Erreurs courantes : symptôme → cause → correction
Mistake 1: “Pool is ONLINE, so checksum errors don’t matter.”
Symptôme : Le pool est ONLINE, mais un disque a des CKSUM en augmentation.
Cause : La redondance masque la corruption ; ZFS répare les lectures, mais quelque chose renvoie de mauvais octets (disque ou chemin).
Correction : Corrélez avec dmesg et SMART ; cherchez des CRC et des réinitialisations de lien. Changez câble/port, ou remplacez le disque si SMART indique un problème média. Scrub pour valider. Effacez seulement après que le compteur cesse d’augmenter.
Mistake 2: Clearing errors to silence monitoring
Symptôme : Les alertes s’arrêtent après zpool clear, puis reviennent plus tard, souvent en pire.
Cause : La supervision avait raison ; vous avez supprimé la preuve et retardé le diagnostic.
Correction : Gardez les compteurs jusqu’à résolution. Si l’infatigabilité des alertes est réelle, ajustez la surveillance pour alerter sur le « taux d’augmentation » et l’état dégradé/faulted actif, pas uniquement sur des compteurs historiques non nuls.
Mistake 3: Replacing disks when the real issue is the HBA/expander
Symptôme : Plusieurs disques montrent des erreurs, souvent à travers différents vdevs, et les remplacements n’aident pas.
Cause : Composant partagé en défaut : HBA qui surchauffe, bug firmware d’expander, backplane mauvais, baisses d’alimentation.
Correction : Mappez les périphériques aux HBA/ports (HCTL), cherchez des patterns communs de réinitialisation dans les logs, et isolez en déplaçant un disque affecté vers un autre chemin contrôleur si possible. Remplacez/réparez le composant partagé.
Mistake 4: Treating “Permanent errors” as a counter problem
Symptôme : zpool status liste des fichiers spécifiques avec des erreurs permanentes.
Cause : ZFS n’a pas pu auto-réparer ces blocs (redondance insuffisante, fautes multiples, ou corruption persistante sur toutes les réplicas).
Correction : Restaurez les fichiers affectés depuis une sauvegarde/réplica ou reconstruisez au niveau application. Identifiez et corrigez le matériel/transport qui a causé la corruption. Effacer les compteurs ne répare pas le fichier.
Mistake 5: Clearing before capturing evidence
Symptôme : « C’est arrivé la nuit dernière mais on ne peut pas reproduire. »
Cause : Les compteurs/events/logs ont été tournés ou effacés, détruisant la corrélation.
Correction : Capturez zpool status -v, zpool events -v, et une fenêtre temporelle des logs avant toute action destructrice. Standardisez cela dans les runbooks d’incident.
Mistake 6: Confusing scrub with resilver and making the wrong call
Symptôme : L’équipe lance des scrubs en s’attendant à reconstruire la redondance après un remplacement, ou remplace des disques alors que le scrub était la vraie nécessité.
Cause : Scrub vérifie et répare ; resilver reconstruit sur un périphérique de remplacement/attachement. Objectifs et signaux différents.
Correction : Si un périphérique a été remplacé/reattached, confirmez que le resilver a lieu. Après le resilver, lancez un scrub pour valider. Effacez les erreurs après validation.
Checklists / plan pas à pas
Checklist A: “Can I run zpool clear now?”
- Avez-vous capturé la sortie de
zpool status -vpour le ticket ? - Les logs noyau montrent-ils les dernières erreurs I/O/réinitialisations pertinentes, et sont-elles expliquées ?
- Le pool est-il
ONLINEsans périphériques manquants ? - Un scrub a‑t‑il été exécuté depuis la correction, avec
0 errors? - Les indicateurs SMART sont-ils stables (CRC n’augmente pas, pas de pending/reallocated en croissance) ?
- Les compteurs d’erreurs n’augmentent-ils pas sous charge ?
Si vous ne pouvez pas répondre oui à la plupart de ces points, n’effacez pas. Si vous le pouvez, effacez chirurgicalement (niveau périphérique) quand c’est possible, puis surveillez.
Checklist B: Step-by-step incident response when zpool status shows errors
- Stabiliser : confirmez l’état du pool, la redondance, et si un vdev est hors ligne/unavail.
- Préserver les preuves : capturez
zpool status -v,zpool events -v, logs, SMART. - Classer : READ/WRITE vs CKSUM vs erreurs permanentes.
- Portée : disque unique vs plusieurs disques vs pattern de composant partagé.
- Atténuer : reseat/swap câble/port ; remplacer le disque seulement si indiqué.
- Valider : resilver (si applicable), puis scrub.
- Réinitialiser la baseline : effacez les erreurs seulement après validation.
- Surveiller : vérifiez le statut après 1h, 24h et après le prochain scrub ; suivez les deltas SMART.
Checklist C: Post-fix verification (the part people skip)
- Lancer un scrub (ou planifier immédiatement si le pool est grand et que vous avez besoin d’une fenêtre).
- Confirmer l’absence de nouvelles erreurs pendant le scrub.
- Confirmer que les compteurs restent stables pendant au moins un cycle de charge normal.
- Ce n’est qu’alors qu’il faut effacer les compteurs d’erreurs et clore l’incident.
Deuxième blague (courte, pertinente) : Le moyen le plus rapide pour rendre zpool status sain est zpool clear. Le deuxième plus rapide, c’est réparer le problème.
FAQ
1) Does zpool clear fix corruption?
Non. Il remet à zéro les compteurs d’erreurs enregistrés et peut effacer certains états de faute. La corruption se répare via la réparation par redondance lors des lectures/scrub, le resilver, ou en restaurant les données.
2) If I clear errors, can I lose data?
Effacer en soi ne supprime pas les données, mais cela peut vous faire manquer une panne en développement en supprimant la preuve. La perte de données survient plus tard, si vous ne remplacez pas le composant défectueux à temps.
3) When should I clear: before or after a scrub?
Après. Un scrub est votre preuve que le pool peut lire et vérifier les données de bout en bout. Effacer avant le scrub supprime la baseline que vous souhaitez comparer.
4) My pool shows checksum errors but “No known data errors.” Is that okay?
Cela peut être acceptable si les erreurs sont historiques et n’augmentent pas — ZFS les a peut‑être réparées. Ce n’est pas acceptable si le compteur de checksum est en hausse, surtout pendant un scrub ou de fortes lectures.
5) Why do checksum errors often implicate cables and HBAs?
Parce que le disque peut renvoyer des octets corrompus en transit ou à cause d’un chemin contrôleur instable. Les compteurs SMART CRC et les logs noyau signalant des réinitialisations de lien sont des indices fréquents.
6) Can I clear only one disk’s errors?
Oui, et souvent vous devriez. Utilisez zpool clear poolname vdev pour réinitialiser les compteurs du périphérique suspecté tout en préservant le contexte du pool.
7) What if errors return immediately after clearing?
C’est cadeau : cela signifie que vous avez un problème actif. Arrêtez d’effacer. Corrélez avec les logs et SMART, et isolez si c’est le disque ou le chemin/matériel partagé.
8) Is it safe to clear errors on a degraded pool?
Généralement non comme « correctif ». Si le pool est dégradé parce qu’un périphérique est manquant, effacer ne remplace pas la redondance. La seule raison sécurisée est après avoir restauré la disponibilité du périphérique et validé la stabilité.
9) How do I decide between replacing the disk and swapping the cable?
Si SMART montre des réallocations/pending/uncorrectables en hausse, remplacez le disque. Si SMART montre des erreurs CRC et que les logs montrent des réinitialisations de lien, priorisez le câble/port/chemin HBA. Si vous hésitez, changez d’abord le chemin ; c’est peu risqué et rapide.
10) Does clearing errors affect future diagnostics?
Oui. Vous perdez des compteurs historiques qui aidaient à montrer la tendance. C’est pourquoi il faut capturer des preuves d’abord et effacer uniquement après correction et validation.
Prochaines étapes à faire aujourd’hui
Si vous exploitez ZFS en production, arrêtez de traiter zpool clear comme un rituel et commencez à le considérer comme une réinitialisation contrôlée des preuves.
- Ajoutez une règle à vos runbooks : pas d’effacement tant que vous n’avez pas attaché
zpool status -v, logs pertinents et sortie SMART au ticket. - Apprenez à votre supervision à se soucier du changement, pas de la honte : alertez sur les compteurs qui augmentent, les états degraded/faulted, les erreurs de scrub, et les drop répétitifs de périphériques.
- Planifiez les scrubs comme des adultes : assez fréquents pour attraper les problèmes latents, mais contrôlés pour ne pas devenir votre pic de charge.
- Pratiquez les clears chirurgicaux : effacez un seul vdev quand vous isolez. Effacez le pool entier quand l’incident est vraiment clos et validé.
- Faites un exercice table-top : simulez des erreurs de checksum sur un disque et faites marcher l’équipe sur le playbook sans improviser avec
zpool clear.
Quand vous effacez, faites‑le avec une raison, une baseline et un plan de surveillance. Ce n’est pas de la superstition. C’est de l’exploitation.