ZFS zpool status -v : trouver le fichier exact corrompu

novembre 14, 2025 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Quand ZFS annonce qu’il a trouvé une corruption, il est étonnamment précis — à condition de poser les bonnes questions. Le piège est que la première chose que vous verrez n’est généralement pas « /home/alice/report.xlsx est mauvais », mais l’état du pool, un vdev et des compteurs de checksum qui ont l’air d’avoir été conçus par quelqu’un qui déteste dormir.

Cet article explique comment transformer zpool status -v d’un voyant rouge effrayant en une liste exploitable : ce qui est cassé, où ça se trouve, si ZFS l’a réparé, et comment extraire le(s) fichier(s) affecté(s) pour les restaurer ou les recopier en toute confiance. Nous le ferons comme en production : triage rapide d’abord, enquête approfondie ensuite, et prévention en permanence.

Ce que `zpool status -v` signifie réellement

À un niveau élevé, zpool status répond : « Le pool est-il sain ? » et « Quel périphérique est impliqué ? ». Ajouter -v fait la différence entre « quelque chose ne va pas » et « ces fichiers spécifiques sont connus comme mauvais maintenant ».

Mais voici ce que beaucoup oublient : zpool status -v ne promet pas systématiquement un nom de fichier propre. Il affiche des chemins seulement pour les erreurs permanentes que ZFS peut associer à des fichiers de données ou de métadonnées. Si ZFS a réparé les données pendant un scrub (en utilisant la redondance), le fichier peut ne jamais apparaître parce qu’il n’a jamais été endommagé de façon permanente. Si l’erreur se situe dans des métadonnées qui ne peuvent pas être mappées vers un chemin de fichier (ou décodées sans une inspection approfondie), vous verrez des numéros d’objet, ou pire, seulement « Permanent errors have been detected » sans liste utile.

Regardez les erreurs ZFS en trois catégories :

Corrigible : Une lecture a renvoyé des données incorrectes, mais ZFS avait une autre copie (mirror/RAIDZ) et a guéri l’erreur.
Incorrigible mais détectable : ZFS sait que le checksum ne correspond pas, mais il n’a pas de bonne copie. C’est là que vous commencez à voir les « erreurs permanentes ».
Opérationnel : timeouts, échecs I/O, déconnexions. Ceux-ci n’impliquent pas nécessairement une corruption, mais peuvent y conduire s’ils provoquent des écritures partielles sur des appareils non atomiques ou des chemins instables.

Deux blagues, comme promis, parce que vous en aurez besoin :

Blague n°1 : ZFS ne « perd » pas les données — il les garde juste à un emplacement dont vous ne pouvez plus prouver l’existence.

Blague n°2 : La seule chose plus persistante que les checksums ZFS est le VP qui demande si ce n’est « qu’un simple reboot ».

Lire les parties importantes de la sortie status

Voici un point de départ typique :

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
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, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Tue Dec 24 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/media/exports/2024-archive.tar
        tank/vmstore/vm-112-disk-0.qcow2

Ce qui compte :

state : « DEGRADED » peut signifier qu’un disque est manquant ou que des erreurs existent. « ONLINE » ne veut pas dire « tout va bien », cela signifie « présent ».
Colonnes READ/WRITE/CKSUM : read/write sont des échecs I/O ; cksum signifie « données renvoyées mais incorrectes ». Ce dernier est souvent là où la corruption silencieuse apparaît.
scan : résultats de scrub/resilver. « 0 errors » dans la ligne scrub ne signifie pas toujours « aucun dommage n’est jamais arrivé », cela signifie « le scrub n’a pas trouvé d’issues non corrigées à ce moment ».
errors : la liste « Permanent errors… » est de l’or. Elle est aussi incomplète lorsque les métadonnées sont impliquées.

Faits et contexte historique utiles

Ce ne sont pas des anecdotes pour faire joli — chacun influe sur ce que vous ferez ensuite.

ZFS a été conçu pour se méfier du stockage. Les checksums sont end-to-end : les données sont vérifiées après leur lecture depuis le disque, pas seulement lors de l’écriture.
Les « erreurs CKSUM » impliquent souvent le chemin, pas seulement le disque : câbles SATA, HBAs, backplanes, firmware d’expander et alimentation peuvent tous corrompre des bits ou faire tomber des commandes.
Les scrubs sont des audits d’intégrité proactifs. Ils lisent chaque bloc et vérifient les checksums ; les resilvers ne reconstruisent que ce qui est nécessaire après un événement périphérique.
ZFS conserve plusieurs couches de métadonnées. Certaines corruptions affectent un fichier ; d’autres affectent les métadonnées qui mappent les blocs aux fichiers. Ces dernières sont plus difficiles à afficher sous forme de chemin.
Les pointeurs de blocs incluent checksums et emplacement physique, ce qui permet à ZFS de détecter des données erronées même si le disque renvoie « succès ».
Des copies peuvent exister sans mirror : ZFS supporte des copies multiples de métadonnées (et optionnellement de données) via des propriétés comme copies=2. Cela modifie le comportement de réparation.
« ashift » est définitif (pour ce vdev). Un mauvais alignement de taille de secteur peut augmenter l’amplification d’écriture et solliciter davantage les appareils — parfois c’est la cause lente de corruptions ultérieures.
La compression change le rayon d’impact. Les blocs compressés font que les offsets logiques de fichier ne correspondent pas 1:1 aux blocs physiques, donc votre réponse « quelle partie est corrompue ? » peut être « un enregistrement », pas « un secteur ».
ZFS peut guérir à la lecture. Sur des pools redondants, la lecture d’un bloc corrompu peut déclencher une réparation avant même qu’un scrub soit lancé.

Mode opératoire pour diagnostic rapide

Voici l’ordre que j’utilise quand je suis de garde et que le pool vient de passer au jaune — ou que l’équipe applicative hurle parce qu’une image VM ne démarre pas.

1) Confirmez l’étendue : pool entier ou dataset/fichier unique ?

cr0x@server:~$ sudo zpool status -v
  ...

Interprétation : Si vous voyez « Permanent errors… » avec des chemins de fichiers, vous avez déjà une liste cible. Si vous ne voyez que des erreurs de périphérique ou « too many errors », vous êtes en mode « stabilité d’abord » : arrêtez l’hémorragie avant de cartographier pour la forensique.

2) Décidez si c’est corruption ou connectivité

cr0x@server:~$ sudo zpool status tank
  ...
        NAME                        STATE     READ WRITE CKSUM
        ata-WDC...                  ONLINE       0     0    54

Interprétation : Un compteur CKSUM qui augmente avec des READ/WRITE faibles signifie souvent que des données erronées sont renvoyées (media disque, contrôleur, câble). Des compteurs READ/WRITE en hausse ou un périphérique OFFLINE/FAULTED indiquent davantage des resets de lien, de l’alimentation ou un disque en fin de vie.

3) Vérifiez si un scrub l’a déjà corrigé

cr0x@server:~$ sudo zpool status -v tank
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Tue Dec 24 03:10:11 2025

Interprétation : « Repaired X » signifie que ZFS a trouvé des blocs mauvais et les a corrigés grâce à la redondance. Si les données ont été réparées, relancez la charge de travail fautive et voyez si le problème a disparu. Si vous avez encore des « Permanent errors », la redondance n’a pas suffi pour ces blocs.

4) Identifiez le domaine de faute : un disque, un HBA, une voie backplane ?

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD80 | head
  ...

Interprétation : Si les erreurs se concentrent sur des disques derrière le même contrôleur ou expander, suspectez le composant partagé. Si c’est un disque répétitivement, suspectez le disque lui-même (ou son emplacement/câble).

5) Si le pool est instable, stabilisez-le avant la cartographie approfondie

Si des périphériques se déconnectent, ne lancez pas d’archéologie zdb sophistiquée en premier. Réparez le câblage, remplacez le disque, arrêtez les resets. Un scrub sur un disque instable peut transformer du « récupérable » en « permanent » en multipliant les lectures échouées.

Tâches pratiques : commandes + interprétation (12+)

Voici des tâches que j’ai réellement effectuées sous pression. Chacune inclut ce que la sortie signifie et la décision qu’elle devrait entraîner.

Tâche 1 : Obtenir la vue haute fréquence du pool

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Interprétation : -x n’affiche que les pools ayant des problèmes ; -v ajoute la liste des fichiers si disponible. Si vous obtenez « healthy », arrêtez les investigations. Sinon, poursuivez.

Tâche 2 : Récupérer le status verbeux d’un pool spécifique

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
...
errors: Permanent errors have been detected in the following files:

        tank/projects/build-cache/index.sqlite

Interprétation : Même « ONLINE » peut signifier qu’une corruption de données est survenue. Si les applications « may be affected », traitez-le comme « sont affectées jusqu’à preuve du contraire ».

Tâche 3 : Trouver quand les erreurs ont commencé (historique d’événements)

cr0x@server:~$ sudo zpool events -v | tail -n 30
  ...

Interprétation : Cherchez des événements de retrait de périphérique, des erreurs de checksum, ou le début/fin de resilver. Cela se corrèle souvent avec des fenêtres de maintenance, des mises à jour du noyau, ou quelqu’un qui « range les câbles ».

Tâche 4 : Lancer (ou relancer) un scrub intentionnellement

cr0x@server:~$ sudo zpool scrub tank

Interprétation : Le scrub est le sérum de vérité d’intégrité. Lancez-le quand le pool est stable. Si vous êtes en plein incident, lancer un scrub immédiatement peut être la bonne décision — sauf si vous suspectez une instabilité matérielle, auquel cas corrigez cela d’abord.

Tâche 5 : Surveiller la progression du scrub sans deviner

cr0x@server:~$ watch -n 5 "sudo zpool status tank | sed -n '1,25p'"
Every 5.0s: sudo zpool status tank | sed -n '1,25p'

  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:10:11 2025
        612G scanned at 1.20G/s, 110G issued at 220M/s, 4.21T total
        0B repaired, 2.61% done, 0:52:01 to go

Interprétation : « scanned » vs « issued » vous indique si le scrub est contraint par l’I/O. Si « issued » est bas, vous pourriez être limité par la latence du vdev, le comportement SMR, ou un throttling.

Tâche 6 : Effacer les erreurs (uniquement après avoir compris ce que vous effacez)

cr0x@server:~$ sudo zpool clear tank

Interprétation : Cela réinitialise les compteurs et l’état « known bad » ; cela ne répare pas magiquement les données. Utilisez-le après avoir remplacé le matériel ou après avoir restauré/remplacé des fichiers corrompus afin de vérifier si les erreurs réapparaissent.

Tâche 7 : Vérifier si « CKSUM » continue d’augmenter

cr0x@server:~$ sudo zpool status tank | awk 'NR==1,NR==40 {print}'
  ...

Interprétation : Prenez deux instantanés dans le temps. Si CKSUM s’incrémente au repos, suspectez du matériel/firmware. Si cela n’arrive que sous fortes lectures, suspectez du media marginal ou des erreurs du contrôleur sous charge.

Tâche 8 : Vérifier la santé du périphérique (SMART) pour le fautif

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "realloc|pending|uncorrect|crc|error|self-test"
  199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       23
  197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0

Interprétation : Les erreurs UDMA CRC hurlent « câble/backplane/chemin contrôleur », pas « media disque ». Des secteurs réalloués/en attente suggèrent un disque défaillant. Aucun indicateur n’est parfait ; servez-vous-en pour décider quoi remplacer en priorité.

Tâche 9 : Vérifier les logs noyau pour resets et erreurs I/O

cr0x@server:~$ sudo dmesg -T | egrep -i "zfs|sd.*error|ata.*error|reset|I/O error|checksum" | tail -n 40
  ...

Interprétation : Si vous voyez des resets de lien, des timeouts de commande, ou des resets de bus autour du moment où ZFS a détecté la corruption, le « fichier corrompu » est le symptôme, pas la maladie.

Tâche 10 : Obtenir les mountpoints des datasets et confirmer que le chemin est réel

cr0x@server:~$ zfs list -o name,mountpoint,compression,recordsize -r tank | head -n 20
NAME                     MOUNTPOINT              COMPRESS  RECORDSIZE
tank                     /tank                   lz4       128K
tank/media               /tank/media             lz4       1M
tank/vmstore             /tank/vmstore           lz4       128K

Interprétation : Si zpool status -v liste tank/vmstore/..., vous devez savoir où cela se trouve sur disque (/tank/vmstore) et quel recordsize/compression peut impliquer pour la récupération au niveau applicatif.

Tâche 11 : Vérifier que le fichier est lisible de bout en bout (et déclencher la guérison si redondant)

cr0x@server:~$ sudo dd if=/tank/media/exports/2024-archive.tar of=/dev/null bs=4M status=progress
  2147483648 bytes (2.1 GB, 2.0 GiB) copied, 4 s, 536 MB/s
  ...

Interprétation : Si la lecture échoue ou se bloque, vous avez confirmé l’impact. Sur des pools redondants, une lecture peut aussi initier une réparation ; après une lecture réussie, vérifiez si les compteurs CKSUM ont changé.

Tâche 12 : Si vous avez des snapshots, restaurer juste le fichier

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                          CREATION
tank/media@autosnap_2025-12-24_0300  Tue Dec 24 03:00 2025
tank/media@autosnap_2025-12-23_0300  Mon Dec 23 03:00 2025

cr0x@server:~$ sudo cp -a /tank/media/.zfs/snapshot/autosnap_2025-12-24_0300/exports/2024-archive.tar /tank/media/exports/2024-archive.tar

Interprétation : C’est souvent la réparation la plus rapide : remplacer le fichier corrompu par une version connue bonne. Pour un disque VM, vous préférerez peut‑être restaurer sous un nouveau nom et faire des vérifications d’intégrité avant l’échange.

Tâche 13 : Si pas de snapshots, vérifier un réplica ou recopier depuis la source

cr0x@server:~$ sudo rsync -avh --inplace --checksum /mnt/source/2024-archive.tar /tank/media/exports/2024-archive.tar
sending incremental file list
2024-archive.tar
          4.21T 100%  1.05GB/s    1:04:10 (xfr#1, to-chk=0/1)

Interprétation : --checksum force une vérification au-delà des timestamps ; --inplace est controversé sur les systèmes copy-on-write, mais peut être adapté quand vous voulez réécrire des blocs sans créer une seconde copie complète. Utilisez-le avec prudence (voir la section erreurs).

Tâche 14 : Remplacer proprement un disque défaillant

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80...-old /dev/disk/by-id/ata-WDC_WD80...-new
cr0x@server:~$ sudo zpool status tank
  scan: resilver in progress since Wed Dec 25 02:11:12 2025
        310G scanned at 1.05G/s, 92.1G issued at 320M/s, 4.21T total
        0B resilvered, 2.19% done, 3:40:21 to go

Interprétation : Le remplacement réduit le risque sous-jacent. Il ne corrige pas automatiquement les blocs déjà corrompus sauf si la redondance existe et que le pool peut les reconstruire lors des lectures de scrub/resilver.

Tâche 15 : Utiliser les checksums ZFS pour vérifier un dataset (sanity rapide)

cr0x@server:~$ sudo zfs set readonly=on tank/media
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zfs set readonly=off tank/media

Interprétation : Mettre temporairement un dataset en lecture seule réduit l’activité d’écriture pendant l’investigation et empêche une application d’écraser des preuves. Ne le faites pas sur des datasets applicatifs en production sans coordination.

Cartographier les erreurs du pool jusqu’au fichier exact (flux réel)

Si zpool status -v imprime déjà des chemins, félicitations — vous êtes en avance sur le cas habituel. Vous devez néanmoins répondre à trois questions :

Le fichier est-il réellement corrompu maintenant, ou a-t-il été réparé ?
La corruption est-elle limitée à ce fichier, ou signe-t-elle d’un problème plus profond ?
Quelle est l’action de récupération la plus rapide et sûre ?

Quand `zpool status -v` vous donne des chemins de fichiers

ZFS listera les chemins qu’il peut associer à des erreurs permanentes. Pour chaque chemin listé :

Tentez de le lire de bout en bout (ou au moins la portion critique).
Si redondant, voyez si la lecture déclenche la réparation (surveillez CKSUM et les scrubs suivants).
Restaurer depuis le snapshot ou recopier depuis la source.
Effacer les erreurs et relancer un scrub pour confirmer que le pool est propre.

Exemple de boucle de vérification :

cr0x@server:~$ sudo zpool status -v tank
errors: Permanent errors have been detected in the following files:
        tank/projects/build-cache/index.sqlite

cr0x@server:~$ sudo sqlite3 /tank/projects/build-cache/index.sqlite "PRAGMA integrity_check;"
*** in database main ***
On tree page 914 cell 27: Rowid 188394 out of order
database disk image is malformed

Interprétation : La base de données est réellement endommagée au niveau applicatif. ZFS a fait son travail en indiquant « ce fichier n’est pas fiable ». Votre mission est de restaurer/reconstruire la base, pas de discuter avec elle.

Quand `zpool status -v` NE vous donne PAS de chemins

C’est le cas le plus intéressant. Vous pourriez voir :

« Permanent errors have been detected… » sans liste
« too many errors »
erreurs attribuées à des métadonnées (parfois affichées comme <metadata> ou des IDs d’objet selon la plateforme)

Quand ZFS ne peut pas afficher un chemin, vous pouvez souvent cartographier la corruption vers des fichiers en utilisant des numéros d’objet et zdb. L’idée :

Identifier le dataset contenant les blocs mauvais (souvent suggéré dans status ou par l’impact applicatif).
Utiliser zdb pour inspecter les objets du dataset et localiser le(s) numéro(s) d’objet affecté(s).
Mapper les numéros d’objet vers des chemins (quand c’est possible) ou au moins identifier le type de fichier (zvol, dnode, répertoire, etc.).

Avertissement opérationnel important : zdb est puissant et tranchant. Utilisez les options lecture seule quand disponibles, exécutez-le hors pics si possible, et capturez la sortie pour relecture. Il ne devrait pas modifier le pool, mais en cas de crise vous ne voulez pas de surprises.

Tâche : Identifier les datasets et si la corruption affecte probablement un zvol

cr0x@server:~$ zfs list -t filesystem,volume -o name,type,used,volsize -r tank
NAME                 TYPE        USED  VOLSIZE
tank                 filesystem  3.21T  -
tank/media           filesystem  1.88T  -
tank/vmstore         filesystem  1.02T  -
tank/vmstore/vm-112  volume      120G  120G

Interprétation : Si la chose impactée est un volume (zvol), elle n’apparaîtra pas comme un fichier ordinaire de la même manière. Votre « fichier » peut être un périphérique bloc consommé par un hyperviseur ou une cible iSCSI.

Tâche : Vérifier si le chemin rapporté est dans un snapshot, clone, ou filesystem courant

cr0x@server:~$ sudo zpool status -v tank | sed -n '/Permanent errors/,$p'
errors: Permanent errors have been detected in the following files:
        tank/media/exports/2024-archive.tar

cr0x@server:~$ ls -lah /tank/media/exports/2024-archive.tar
-rw-r--r-- 1 root root 4.3T Dec 21 01:01 /tank/media/exports/2024-archive.tar

Interprétation : Validez que le fichier existe là où vous le pensez. Ça semble évident ; dans la vraie vie, les points de montage bougent, il y a des bind mounts, et quelqu’un insistera que c’est « sous /srv ».

Tâche : Utiliser `zdb` pour mapper un chemin vers des informations internes d’objet (avancé)

Sur beaucoup de systèmes OpenZFS, vous pouvez interroger zdb au sujet d’un chemin de fichier dans un dataset. Un schéma courant : trouver le dataset, puis requêter avec zdb pour localiser le dnode/objet.

cr0x@server:~$ sudo zdb -ddd tank/media | head -n 25
Dataset tank/media [ZPL], ID 52, cr_txg 1, 1.88T, 9.21M objects

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
         1    1   128K    1K  16.0K     512  1.50K  100.00  ZFS master node
         2    1   128K    1K  16.0K     512  14.5K  100.00  ZFS directory
  ...

Interprétation : Cela confirme le type de dataset (ZPL filesystem) et que zdb peut lire les métadonnées. Si zdb lui-même renvoie des erreurs I/O, arrêtez et stabilisez le matériel.

Tâche : Identifier l’inode/objet d’un fichier (approche portable)

cr0x@server:~$ stat -c 'path=%n inode=%i size=%s' /tank/media/exports/2024-archive.tar
path=/tank/media/exports/2024-archive.tar inode=188394 size=4639123456789

Interprétation : Sur ZFS, le numéro d’inode correspond souvent à un numéro d’objet interne (dnode) pour les filesystems ZPL. C’est le pont entre « chemin de fichier » et « objet 188394 » que vous verrez ailleurs.

Tâche : Explorer un objet spécifique avec `zdb` (cartographie forensique)

cr0x@server:~$ sudo zdb -dddd tank/media 188394 | sed -n '1,120p'
Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
188394    2   128K  128K  1.00M    512  4.21T   98.11  ZFS file
Bonus System attributes
  ZPL_SIZE 4639123456789
  ZPL_GEN  4821
Indirect blocks:
  ...

Interprétation : Si vous pouvez inspecter proprement l’objet, vous pouvez parfois aller plus loin et localiser quel(s) pointeur(s) de bloc échouent, ce qui aide à différencier « un seul secteur mauvais » d’un « problème généralisé ». Surtout : cela confirme que vous regardez la bonne chose.

Tâche : Prouver si la corruption est localisée ou systémique

cr0x@server:~$ sudo zpool status tank | egrep -A3 "NAME|raidz|mirror|ata-|nvme"
        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-WDC...-part1        ONLINE       0     0     0
            ata-WDC...-part1        ONLINE       0     0     2
            ata-WDC...-part1        ONLINE       0     0     0

Interprétation : « 2 CKSUM sur un disque » peut être un événement isolé de bit rot ou un petit problème de câble. « Des milliers sur plusieurs disques » est généralement l’infrastructure : HBA, backplane, firmware, alimentation, ou une mauvaise série de disques.

Tâche : Si les erreurs sont sur un seul vdev de premier niveau, comprendre le rayon d’impact

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        21.8T  16.2T  5.6T        -         -    22%    74%  1.00x  ONLINE
  raidz1-0  21.8T  16.2T  5.6T        -         -    22%    74%

Interprétation : Les pools à vdev unique sont courants. Si ce vdev a des problèmes, l’intégrité du pool entier en dépend. Les pools multi-vdev peuvent isoler la défaillance, mais ajoutent aussi de la complexité opérationnelle.

Tâche : Vérifier si des vdevs spéciaux ou des périphériques metadata sont impliqués

cr0x@server:~$ sudo 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
            ...
        special
          mirror-1                  ONLINE       0     0     0
            nvme-SAMSUNG...         ONLINE       0     0     0
            nvme-SAMSUNG...         ONLINE       0     0     0

Interprétation : Si un vdev special échoue (metadata/petits blocs), vous pouvez voir des symptômes de « fichiers aléatoires » qui semblent terrifiants. Traitez les vdevs special comme critiques. Si un vdev special échoue et que vous n’avez pas de redondance, le pool peut être effectivement perdu même si les disques de données sont sains.

Tâche : Si vous suspectez une RAM défaillante ou une corruption mémoire transitoire

cr0x@server:~$ sudo zpool status -v tank
  status: One or more devices has experienced an error resulting in data corruption.
  ...

Interprétation : ZFS n’est pas immunisé contre une RAM défaillante. L’ECC aide. Sans ECC, vous pouvez utiliser ZFS, mais vous devriez être plus paranoïaque : des erreurs checksum répétables sur différents disques sans un chemin matériel clair peuvent être un indice. Corrélez avec les logs système, les crashes et d’autres anomalies.

Trois mini-récits du monde corporate

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

Une entreprise avec laquelle j’ai travaillé avait une règle « simple » : si zpool status dit ONLINE, le stockage est OK. Cette règle était dans un runbook, et finit par être promue de « raccourci utile » à « politique ».

Un matin, une image VM ne démarrait pas. Les logs de l’hyperviseur montraient des erreurs I/O ; le nœud de stockage montrait le pool ONLINE. Le responsable d’incident a donc déclaré la couche stockage « nettoyée » et a poussé l’équipe virtualisation à « réparer l’invité ». Classique jeu de patate chaude, mais avec plus de canaux Slack.

Quelqu’un a finalement lancé zpool status -v (pas juste zpool status) et a obtenu une erreur permanente listant le fichier .qcow2 exact. Le pool était ONLINE parce que les vdevs étaient présents ; les données n’étaient pas saines car le pool avait des échecs checksum non récupérables sur quelques blocs.

La fausse hypothèse n’était pas « ZFS ment ». C’était « ONLINE signifie sain ». ONLINE signifie « le pool est accessible ». Cela ne garantit pas que chaque octet est intact. Après cet incident, l’équipe a changé la règle : le stockage est « vert » uniquement si zpool status -xv est propre et si le dernier scrub s’est terminé sans erreurs non corrigées.

La réparation était ennuyante : restaurer le disque VM depuis le snapshot de la nuit précédente, puis scrub le pool et remplacer le chemin matériel suspect. La leçon est restée parce que c’était coûteux : la VM avait été « réparée » en réinstallant des paquets pendant deux heures avant que quelqu’un ne prouve que l’image disque était corrompue.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un autre endroit a décidé que les scrubs étaient « trop coûteux » pendant les heures ouvrables. Ils avaient des charges analytiques et ne voulaient pas que la bande passante de lecture soit consommée par des scans d’intégrité. Ils ont donc déplacé les scrubs à une cadence mensuelle et les ont fortement limités.

Sur le papier, cela semblait responsable : moins de scrubs, moins d’I/O, des tableaux de bord plus heureux. Dans la pratique, la fenêtre de détection s’est étirée. Un câble SAS marginal a commencé à produire des erreurs checksum intermittentes. Rien ne plantait. Le pool continuait de guérir ce qu’il pouvait. Et parce que les scrubs étaient rares, le problème est resté invisible assez longtemps pour qu’un second disque développe de réelles erreurs médias.

Au moment du scrub mensuel, il a trouvé des blocs non récupérables disséminés sur plusieurs datasets. zpool status -v listait quelques fichiers, mais des dommages de métadonnées faisaient que certaines erreurs n’étaient pas mappées proprement à des chemins. La récupération est devenue un mélange sale de restauration de snapshots, vérification de bases de données et explication à la direction pourquoi « on a RAIDZ, donc on est safe » n’est pas une phrase souhaitable dans un postmortem.

L’optimisation n’était pas seulement le calendrier — c’était la confiance qu’elle créait. Ils traitaient le scrub comme une option. Les scrubs sont plus proches d’« tests d’alarme incendie ». Ils sont disruptifs jusqu’au jour où vous en aurez besoin, et alors vous souhaiterez les avoir faits régulièrement.

La suite : ils sont revenus à des scrubs hebdomadaires, ont ajusté la vitesse du scrub selon les SLOs de latence, et ont commencé à alerter sur tout delta CKSUM non nul par jour. Le plus drôle est que le cluster a tourné plus vite après, parce que les erreurs de lien sous-jacentes ont été corrigées et les retries ont cessé de faire chuter la latence.

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

Le cas de corruption le plus réussi que j’ai vu était presque anti-climatique. Un nœud de stockage a rapporté quelques erreurs CKSUM et zpool status -v listait deux fichiers : une archive exportée et un petit segment WAL Postgres.

L’équipe avait l’habitude — certains l’appelaient paranoïaque — de prendre des snapshots fréquents et de répliquer les datasets critiques. Ce n’était pas sophistiqué : nommage cohérent, politiques de rétention, tests de restauration périodiques. Ce genre de chose que personne ne célèbre parce que ça n’ajoute pas de fonctionnalités.

Ils ont fait le basique : ont mis en pause le job d’ingestion touchant le dataset, ont restauré les deux fichiers depuis un snapshot pris une heure plus tôt, et ont lancé un scrub pour valider qu’il n’y avait pas d’autres erreurs non corrigées. Ils ont aussi extrait SMART et ont vu des erreurs UDMA CRC sur un disque, remplacé le câble pendant une fenêtre de maintenance, et ont vu le compteur CKSUM cesser de bouger.

Pas de spelunking héroïque avec zdb. Pas de « peut-être que le filesystem va se réparer ». Juste une hygiène disciplinée. La revue post-incident a duré 20 minutes parce qu’il n’y avait pas beaucoup de drame à raconter, ce qui est la meilleure sorte de revue.

Si vous voulez une morale : les snapshots ne préviennent pas la corruption, mais ils transforment la corruption en une nuisance. Et en entreprise, une nuisance, c’est pratiquement une victoire.

Erreurs courantes : symptômes et corrections

Erreur 1 : Effacer les erreurs avant de restaurer les fichiers

Symptôme : Vous lancez zpool clear, le status semble propre, puis l’application relit le fichier et échoue de nouveau plus tard — ou vous perdez la trace des fichiers affectés.

Correction : Traitez la liste « Permanent errors » comme un artefact d’incident. Copiez-la dans votre ticket, restaurez/remplacez les fichiers, puis effacez et lancez un scrub pour confirmer. Effacer sert à vérifier la récurrence, pas à nier le problème.

Erreur 2 : Supposer que CKSUM signifie « disque défectueux » (ça peut être, mais pas toujours)

Symptôme : Vous remplacez un disque, le resilver se termine, et les erreurs CKSUM continuent d’augmenter — parfois sur le disque de remplacement.

Correction : Vérifiez les câbles SATA/SAS, backplanes, HBAs, firmware d’expander et stabilité d’alimentation. Consultez SMART pour UDMA CRC et les logs noyau pour des resets de lien.

Erreur 3 : Scrubber sur matériel instable

Symptôme : Un disque lâche de manière intermittente ; vous scrubez ; après vous avez plus d’erreurs permanentes qu’avant.

Correction : Stabilisez d’abord. Le scrub lit toute la surface. Si le chemin est instable, vous forcez le système à toucher le point faible à répétition. Remplacez câble/HBA/disque, puis scrubez.

Erreur 4 : Confondre « repaired 0B » avec « aucune corruption n’a eu lieu »

Symptôme : Le scrub indique « 0B repaired », mais vous voyez toujours des erreurs permanentes ou de la corruption applicative.

Correction : « 0B repaired » peut signifier soit « rien n’était mauvais » soit « rien n’a pu être réparé ». Vérifiez toujours la section « errors: » et les compteurs d’erreurs des périphériques.

Erreur 5 : Ignorer l’impact des metadata / vdevs special

Symptôme : Des fichiers aléatoires sur différents datasets échouent ; zpool status -v est parcellaire ou bizarre ; les performances deviennent erratiques.

Correction : Vérifiez si des vdevs special existent et s’ils sont sains. Traitez-les comme critiques. Si un vdev special échoue sans redondance, le pool peut être perdu même si les disques de données semblent bien.

Erreur 6 : Traiter un fichier disque VM comme un fichier normal pendant la récupération

Symptôme : Vous restaurez un .qcow2 ou une image raw « en place » pendant que la VM tourne ; plus tard vous obtenez une corruption subtile du filesystem invité.

Correction : Quiescez la VM, restaurez dans un nouveau fichier, lancez des vérifications côté invité si possible, puis swappez. Les images VM sont volumineuses, actives et sensibles aux workflows de restauration partielle.

Erreur 7 : Activer une « optimisation » sans comprendre les patterns d’écriture

Symptôme : Après avoir modifié recordsize, compression, ou utilisé rsync --inplace, vous observez plus de fragmentation, des scrubs plus longs, ou des pics de latence inattendus.

Correction : Traitez l’optimisation des performances comme une demande de changement : mesurez, stagez, et rollbackez si nécessaire. Les workflows d’intégrité dépendent d’un comportement I/O prévisible.

Listes de contrôle / plan étape par étape

Checklist A : Plan de réponse « je viens de voir de la corruption »

Capturer les preuves : zpool status -v, zpool events -v, extraits de dmesg.
Déterminer si le pool est stable (périphériques qui ne basculent pas). Si instable, prioriser la stabilisation matérielle.
Si zpool status -v liste des fichiers, inventoriez-les et classez : DB/VM critiques en premier.
Lancer ou planifier un scrub (quand stable). Surveiller la progression et les erreurs.
Restaurer/remplacer les fichiers corrompus depuis snapshots ou source amont.
Effacer les erreurs (zpool clear) uniquement après remédiation.
Relancer un scrub pour valider et surveiller les compteurs de régression.
Analyser la cause matérielle : SMART, câblage, firmware contrôleur, événements d’alimentation.

Checklist B : Étapes pour trouver « le fichier exact »

Lancer zpool status -v. Si vous obtenez des chemins, arrêtez — vous les avez déjà.
Si pas de chemins, identifier le vdev/disque affecté via les compteurs d’erreurs.
Identifier le dataset probable par l’impact applicatif (quel mountpoint/app voit les erreurs) et en revoyant l’historique d’événements.
Utiliser stat sur les fichiers suspects pour obtenir inode/numéros d’objet.
Utiliser zdb pour inspecter dataset et objets ; confirmer les types d’objet.
Quand vous avez un fichier/objet suspect, tenter des lectures contrôlées pour confirmer.
Récupérer depuis snapshot/réplica ; valider l’intégrité applicative (checks DB, tests d’archive, boot VM).

Checklist C : Vérification post-corrective

zpool status -xv doit être propre.
Le scrub se termine avec 0 errors.
Les compteurs CKSUM cessent d’augmenter après reprise des charges normales.
SMART et logs noyau ne montrent plus de resets/timeouts.
Les tests de restauration prouvent que les backups/snapshots sont valides.

FAQ

1) Est-ce que `zpool status -v` affiche toujours le nom de fichier exact ?

Non. Il affiche les chemins de fichiers quand ZFS peut mapper des erreurs permanentes à un fichier dans un filesystem ZPL. Si la corruption touche les métadonnées, affecte des objets non mappés, concerne un zvol, ou si ZFS ne peut pas résoudre le chemin en toute sécurité, vous n’aurez pas de nom de fichier ou seulement des références de type objet.

2) Quelle est la différence entre READ, WRITE et CKSUM ?

READ/WRITE sont des échecs I/O (le périphérique n’a pas pu lire/écrire correctement). CKSUM signifie que le périphérique a renvoyé des données avec succès, mais que celles-ci ne correspondaient pas au checksum attendu — souvent en lien avec une corruption silencieuse ou un mauvais chemin (câble/HBA/backplane).

3) Si ZFS a réparé les données pendant un scrub, dois-je faire quelque chose ?

Oui : il faut trouver la cause racine. Une réparation signifie que la redondance vous a sauvé cette fois. Vérifiez les compteurs des périphériques, SMART et les logs. Un événement réparé peut être un coup de bol cosmique ; des réparations répétées indiquent un problème matériel en train d’apparaître.

4) Dois-je lancer un scrub immédiatement après avoir vu des erreurs ?

Si le chemin matériel est stable, oui — le scrub vous donne la vérité et peut réparer. Si les périphériques basculent ou si vous voyez des resets/timeouts, stabilisez d’abord ; scruber du matériel instable peut augmenter le nombre de lectures non récupérables.

5) Quelle est la façon la plus rapide de « réparer » un fichier listé comme corrompu ?

Le restaurer depuis un snapshot (/path/.zfs/snapshot/...) ou le recopier depuis une source connue bonne. Ensuite effacer les erreurs et scruber pour valider. Pour les bases de données et images VM, faites aussi des vérifications au niveau applicatif.

6) Un mauvais câble SATA/SAS peut-il vraiment causer des erreurs de checksum ?

Absolument. C’est une des causes les plus fréquentes que l’on minimise. Le compteur UDMA CRC de SMART et les logs noyau sur les resets de lien sont des signaux forts. Remplacez le câble, réinsérez les connecteurs et vérifiez le backplane.

7) Si je remplace le disque, le fichier corrompu sera-t-il automatiquement réparé ?

Seulement si la redondance permet la reconstruction du bloc mauvais et que le pool lit et répare ce bloc (scrub/heal-on-read). Si le pool n’avait pas de bonne copie (ou si la corruption existait sur toutes les copies), remplacer le matériel ne ressuscitera pas les données — il vous faudra snapshots/backups.

8) Pourquoi `zpool status` dit parfois « applications are unaffected » quand il liste des erreurs ?

Cette ligne apparaît généralement quand ZFS a détecté et corrigé un problème (ou croit l’avoir fait). Traitez-la comme « pas d’échecs I/O immédiats observés par les applications », pas comme une garantie. Si des erreurs permanentes existent, certaines données sont non fiables.

9) Que signifie « too many errors » ?

ZFS vous dit que le taux d’erreurs est suffisamment élevé pour que lister tout soit impraticable, ou que la situation se détériore activement. Concentrez-vous sur la stabilisation matérielle, lancer un scrub et trier les datasets impactés selon les symptômes applicatifs.

10) Puis-je utiliser `zpool clear` pour faire disparaître le message alarmant ?

Vous pouvez, mais c’est comme enlever la pile du détecteur de fumée parce qu’il est bruyant. Effacez après remédiation afin de détecter si les erreurs réapparaissent. Si vous effacez d’abord, vous perdez une trace importante.

Conclusion

zpool status -v est l’un des rares outils d’infrastructure à la fois honnête et utile : il vous dit ce que ZFS peut prouver, pas ce que vous voulez entendre. Quand il imprime une liste de fichiers, traitez cette sortie comme une checklist chirurgicale — vérifiez, restaurez, validez, puis effacez et re-scrubez. Quand il n’affiche pas de chemins, ne paniquez pas ; cela signifie généralement que la corruption touche des métadonnées ou est difficile à mapper, et c’est votre signal pour stabiliser le matériel et escalader l’inspection avec zdb et une logique au niveau objet.

Le gain opérationnel n’est pas seulement de trouver le fichier corrompu. C’est d’adopter une habitude : des scrubs fréquents adaptés à votre budget de latence, des snapshots que vous avez réellement testés, et de l’alerte sur un compteur CKSUM montant avant que cela ne devienne un titre de postmortem.