Erreurs de somme de contrôle ZFS : ce qu’elles signifient et que faire en premier

Ce que signifient réellement les erreurs de checksum (et ce qu’elles ne signifient pas)

Quand ZFS écrit un bloc, il calcule une somme de contrôle et la stocke dans les métadonnées (pas juste à côté du bloc de données au même endroit où une seule défaillance pourrait corrompre les deux). Plus tard, quand ZFS lit ce bloc, il recompute la somme et la compare à ce qu’il attend.

Une erreur de checksum signifie : les octets renvoyés par le chemin de stockage sont différents de ce que ZFS a précédemment écrit. ZFS a réussi à lire quelque chose — simplement pas la bonne chose.

Une erreur de checksum n’implique pas automatiquement : « le disque est défectueux. » Cela signifie « les données sont corrompues quelque part entre les plateaux/NAND et ZFS. » Ce « quelque part » inclut :

• Le média du disque ou son contrôleur (défaillance classique)
• Câble SATA/SAS, connecteur, backplane, expander (dépressivement courant)
• Firmware/driver du HBA (surtout autour des resets et timeouts)
• Problèmes d’alimentation (brownouts, alimentations marginales, connecteur d’alim lâche)
• Corruption mémoire (l’ECC aide ; sans ECC, la situation devient… pimentée)
• Instabilité CPU/IMC due à l’overclocking ou undervolting (oui, même sur serveurs)

Si la redondance existe (mirror/RAIDZ) et que ZFS peut récupérer une copie saine depuis un autre périphérique, il réparera les données lors d’un scrub ou d’une lecture. C’est la partie que tout le monde apprécie dans ZFS. La partie qu’on ignore est l’implication : si vous continuez à voir des erreurs de checksum, le système reçoit de manière répétée des données corrompues. La réparation est un pansement, pas une solution.

Ne confondez pas non plus ces trois compteurs :

• READ errors : le périphérique n’a pas pu lire les données (erreur I/O). C’est généralement un disque, un câble ou un HBA.
• WRITE errors : ZFS n’a pas pu écrire (erreur I/O) ou le périphérique a rejeté un écrit. Souvent matériel aussi.
• CKSUM errors : les données sont revenues, mais elles étaient incorrectes. C’est là que « disque défectueux » concurrence « chemin défectueux ».

Voici une règle d’opinion : considérez les erreurs de checksum comme un incident de production jusqu’à preuve du contraire. Elles commencent souvent par « quelques-unes ». Elles restent rarement à ce niveau.

Blague #1 (courte, pertinente) : Les erreurs de checksum ZFS sont comme une alarme incendie qui peut aussi vous dire quelle pièce brûle. Vous ne devriez quand même pas l’ignorer parce que la cuisine « a l’air bien ».

Pourquoi ZFS détecte ce que d’autres systèmes de fichiers manquent

ZFS effectue une vérification de bout en bout par somme de contrôle. Cette expression est souvent employée, mais la conséquence opérationnelle est simple : ZFS se méfie de votre matériel par défaut. Historiquement, la plupart des piles faisaient confiance aux disques pour soit renvoyer les bonnes données, soit signaler une erreur. En réalité, les périphériques renvoient parfois des données erronées sans lever d’erreur I/O. C’est la « corruption silencieuse », et c’est pourquoi les erreurs de checksum existent en tant que catégorie.

ZFS sait aussi comment réparer ce qu’il détecte — si vous lui avez fourni de la redondance. Un mirror peut lire de l’autre côté. RAIDZ peut reconstruire avec la parité. Sans redondance, ZFS ne peut que dire « ce bloc est mauvais » et vous obtenez la moins amusante des erreurs : l’erreur honnête.

Opérationnellement, la sévérité de ZFS est un cadeau. Elle transforme un « bug mystérieux d’application » en « le stockage a renvoyé des octets corrompus ». Mais elle vous oblige aussi à faire le travail : vous devez décider si la source est le disque, le bus, la mémoire ou le logiciel.

Une remarque pratique : les erreurs de checksum peuvent apparaître longtemps après la corruption initiale. Les mauvaises données peuvent rester inchangées pendant des semaines. Ensuite un scrub (ou une sauvegarde) les lit et ZFS se plaint enfin. L’erreur est réelle ; le timing est juste impoli.

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Premier : déterminer l’étendue et si ZFS peut s’auto-réparer

• Le pool est-il DEGRADED ou se contente-t-il de rapporter des erreurs ?
• Les erreurs augmentent-elles en ce moment ou sont-elles historiques ?
• Sont-elles confinées à un seul périphérique, un seul vdev, ou réparties ?
• Y a-t-il de la redondance (mirror/RAIDZ) qui peut réparer ?

Second : classer le mode de défaillance par motif

• Disque unique, CKSUM en hausse avec un historique propre de câblage/backplane : suspectez le disque ou son emplacement.
• Plusieurs disques sur le même HBA/backplane montrent des CKSUM : suspectez le câble/backplane/expander/HBA.
• CKSUM sans READ/WRITE et instabilité système étrange : suspectez la RAM/CPU/firmware.
• Erreurs uniquement pendant scrub/resilver : suspectez du matériel marginal sous charge soutenue (disque, câble, expander, HBA, alimentation).

Troisième : collecter des preuves avant de « réparer » quoi que ce soit

• Capturez zpool status -v, zpool events -v et les journaux système autour des timestamps.
• Consignez les identifiants des périphériques : /dev/disk/by-id compte plus que sdX.
• Récupérez les données SMART / NVMe et les journaux d’erreurs.
• Si plusieurs périphériques montrent des erreurs, cartographiez-les jusqu’à la chaîne physique (port HBA → expander → emplacement backplane).

Puis — et seulement alors — commencez à remplacer des pièces ou à réinsérer des câbles. Sinon vous effacez les traces et laissez le mystère au prochain intervenant.

Tâches pratiques : commandes, sorties et décisions

L’objectif ici n’est pas d’exécuter des commandes par confort. C’est d’en extraire une décision. Chaque tâche inclut : la commande, ce que signifie la sortie, et ce que vous faites ensuite.

Task 1: Get the current truth from ZFS

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 128K in 0 days 00:12:31 with 0 errors on Tue Dec 24 01:10:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

errors: No known data errors

Sens : Un périphérique affiche 14 erreurs de checksum, mais ZFS a réparé des données pendant le scrub et il y a « No known data errors ». Cela implique que la redondance a fonctionné.

Décision : Traitez le chemin du périphérique comme suspect. Enquêtez sur le matériel, mais vous n’êtes pas encore en territoire « restauration depuis sauvegarde » immédiat.

Task 2: Confirm whether errors are still increasing

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

Sens : Même nombre qu’avant. C’est bon : cela suggère un événement historique plutôt qu’un flux de corruption en cours.

Décision : Poursuivez la collecte de preuves. Si le compteur augmente pendant une charge ou un scrub, passez au dépannage physique et considérez un remplacement probable.

Task 3: Pull device identity and avoid the sdX trap

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'WDC_WD80EFAX|ata-WDC'
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ -> ../../sdc

Sens : Vous avez des identifiants stables mappés aux noms noyau sdb/sdc. Les noms noyau peuvent changer après un reboot ; les noms dans /dev/disk/by-id sont généralement stables.

Décision : Utilisez les chemins by-id pour les remplacements et la documentation. Si vous retirez le mauvais disque, ZFS s’en souviendra.

Task 4: Check ZFS events for the timeline

cr0x@server:~$ zpool events -v | tail -n 20
Dec 24 01:06:12.900760000 sysevent.fs.zfs.checksum
  pool = tank
  vdev_path = /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ
  vdev_guid = 1234567890123456789
  vdev_state = 0
  vdev_read_errors = 0
  vdev_write_errors = 0
  vdev_checksum_errors = 14
Dec 24 01:10:18.112233000 sysevent.fs.zfs.scrub_finish
  pool = tank
  scrub_repaired = 131072
  scrub_errors = 0

Sens : L’événement checksum est survenu pendant le scrub. Il a réparé 128K et s’est terminé sans erreurs non corrigées.

Décision : Cherchez ce qui a changé à ce moment : travaux de câblage, mises à jour de firmware, événements d’alimentation, I/O soutenue, ou reset de contrôleur.

Task 5: Look for controller resets and link errors in system logs

cr0x@server:~$ sudo journalctl -k --since "2025-12-24 00:45" --until "2025-12-24 01:30" | egrep -i "ata|sas|scsi|reset|link|error" | tail -n 20
Dec 24 01:05:44 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x400100 action 0x6 frozen
Dec 24 01:05:44 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 24 01:05:44 server kernel: ata7: SError: { UnrecovData Handshk }
Dec 24 01:05:45 server kernel: ata7: hard resetting link
Dec 24 01:05:50 server kernel: ata7: link is slow to respond, please be patient (ready=0)
Dec 24 01:05:51 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 24 01:05:51 server kernel: sd 6:0:0:0: [sdc] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=7s

Sens : Le noyau a vu une erreur de lien SATA et a effectué un reset. C’est un signal fort pour câblage/backplane/interface disque — surtout si cela se répète.

Décision : Si vous voyez des resets de lien liés à la même baie, commencez par la couche physique : réinsérez/remplacez le câble, déplacez le disque vers un autre emplacement, ou échangez le câble breakout.

Task 6: Check SMART health (SATA/SAS via smartctl)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       23

Sens : Les erreurs CRC (UDMA_CRC_Error_Count) pointent vers une corruption en transit — câble/backplane — et non vers un défaut média. Les secteurs réalloués/pending sont à zéro, ce qui affaiblit le diagnostic « plateau qui meurt ».

Décision : Réparez d’abord le transport : câble/backplane/emplacement. Si les CRC continuent d’augmenter après remédiation physique, alors pensez au disque ou au contrôleur.

Task 7: Run a short SMART self-test and read results

cr0x@server:~$ sudo smartctl -t short /dev/sdc
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Self-test execution status|SMART Self-test log" -A5
Self-test execution status:      (  0) The previous self-test routine completed without error.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9123         -

Sens : Le disque a passé son auto-test. Cela n’innocente pas le disque, mais oriente plutôt la suspicion vers câble/backplane/contrôleur si les erreurs persistent.

Décision : Si les erreurs ZFS continuent d’augmenter et que SMART est propre sauf pour les CRC, cessez d’accuser le disque et commencez à échanger câbles/emplacements.

Task 8: For NVMe, check SMART and error logs (nvme-cli)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 2

Sens : NVMe rapporte media_errors et des entrées dans le journal d’erreurs. Les media_errors sont graves ; un petit nombre d’entrées dans le journal peut être bénin selon le type, mais c’est une preuve.

Décision : Si media_errors > 0 ou si le journal d’erreurs montre des problèmes répétés d’intégrité des données, planifiez un remplacement. Les NVMe ont tendance à échouer rapidement et sans nostalgie.

Task 9: Identify which vdev type you’re dealing with (affects urgency)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       14.5T  9.12T  5.38T        -         -    21%    62%  1.00x  ONLINE  -
  mirror-0  7.25T  4.56T  2.69T        -         -    19%    62%      -  ONLINE
  mirror-1  7.25T  4.56T  2.69T        -         -    23%    62%      -  ONLINE

Sens : Mirrors : bons pour l’auto-réparation et les resilvers rapides. RAIDZ : comportement différent, fenêtres de reconstruction plus longues, profil de risque différent.

Décision : Si vous êtes en RAIDZ avec de gros disques, soyez plus agressif sur la remédiation précoce parce que la fenêtre de resilver/scrub est plus longue et expose les composants marginaux plus longtemps.

Task 10: Scrub intentionally, not as a reflex

cr0x@server:~$ sudo zpool scrub tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:40:02 2025
        1.27T scanned at 3.10G/s, 912G issued at 2.23G/s, 9.12T total
        0B repaired, 9.76% done, 0:59:31 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0    14

errors: No known data errors

Sens : Le scrub met la totalité du chemin sous contrainte. Si les erreurs augmentent pendant le scrub, vous reproduisez le problème (utile pour le diagnostic, mauvais pour le matériel fragile).

Décision : Lancez les scrubs quand vous pouvez observer et capturer les logs. Ne lancez pas un scrub et n’allez pas dormir à moins d’aimer les pages surprises.

Task 11: Clear errors only after remediation

cr0x@server:~$ sudo zpool clear tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0

errors: No known data errors

Sens : Les compteurs sont remis à zéro. Cela ne corrige rien. Cela rend juste le tableau de bord silencieux.

Décision : Effacez après avoir réinséré des câbles, échangé des emplacements, remplacé un disque, mis à jour un firmware, ou autrement modifié l’environnement. Puis observez si les erreurs réapparaissent.

Task 12: Replace a disk the ZFS way (mirror example)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Wed Dec 25 02:05:11 2025
        612G scanned at 1.45G/s, 210G issued at 512M/s, 9.12T total
        210G resilvered, 2.25% done, 4:58:40 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          mirror-0                                        ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC             ONLINE       0     0     0
            replacing-1                                   ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ           ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE           ONLINE       0     0     0

errors: No known data errors

Sens : ZFS est en train de resilver. Si des erreurs de checksum surviennent pendant le resilver, c’est diagnostique : votre chemin est instable sous I/O soutenue.

Décision : Surveillez journalctl -k en parallèle. Si des resets de lien ou des erreurs de transport apparaissent, mettez en pause et corrigez le câblage/HBA avant de terminer le remplacement.

Task 13: Use zdb only when you’re ready to be precise

cr0x@server:~$ sudo zdb -bbbbbb tank 2>/dev/null | head -n 20
Dataset tank [ZPL], ID 50, cr_txg 4, 1.62G, 1021 objects, rootbp DVA[0]=<0:1c3f4a8000:200> ...

Sens : zdb est destiné à la forensique approfondie, pas au pistage occasionnel. Il peut aider à identifier quels blocs sont affectés quand vous avez des « known data errors ».

Décision : Utilisez-le si vous faites face à des erreurs non réparables et que vous devez décider quelles données restaurer, ou pour valider des hypothèses sur la corruption des métadonnées vs fichiers.

Task 14: Check memory health signals (ECC and kernel reports)

cr0x@server:~$ sudo journalctl -k | egrep -i "mce|edac|ecc|machine check" | tail -n 20
Dec 25 00:12:08 server kernel: EDAC MC0: 1 CE memory error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)

Sens : Les erreurs ECC corrigées (CE) signifient que la RAM se comporte mal mais est corrigée. Cela peut toujours corréler avec des erreurs de checksum et de l’instabilité.

Décision : Traitez les événements ECC répétés comme un incident matériel. Planifiez le remplacement du DIMM et cessez d’accuser les disques pour ce que la RAM corrompt en amont.

Task 15: Inspect ZFS properties that affect corruption visibility

cr0x@server:~$ zfs get checksum,compression,recordsize,atime tank
NAME  PROPERTY     VALUE     SOURCE
tank  checksum     on        default
tank  compression  lz4       local
tank  recordsize   128K      local
tank  atime        off       local

Sens : Le checksumming est activé (bien). La compression ne cause pas d’erreurs de checksum, mais elle change les patterns I/O et peut exposer du matériel faible lors de lectures/écritures intenses.

Décision : Ne « corrigez » pas les erreurs de checksum en modifiant les propriétés du dataset. Corrigez le chemin matériel. ZFS est le messager, pas le coupable.

Task 16: Map physical topology (SAS example) to find shared components

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Device is a Hard disk|SAS Address|State" -A2
Enclosure#                             : 1
  Slot#                                : 4
    Device is a Hard disk
    State                              : Optimal
  Slot#                                : 5
    Device is a Hard disk
    State                              : Optimal

Sens : Quand plusieurs disques affectés partagent une enclosure/backplane/expander, la cartographie de topologie transforme des « erreurs aléatoires » en « point unique de défaillance ».

Décision : Si les erreurs se corrèlent par enclosure/port, priorisez le composant partagé (câble, expander, backplane, HBA) plutôt que d’échanger les disques.

Guide d’interprétation : disque vs câble vs RAM vs firmware

Pattern A: One device, checksum errors climb slowly, SMART shows reallocations/pending sectors

Coupable probable : le disque. Si les secteurs réalloués augmentent ou des secteurs en attente apparaissent, le média est en train de lâcher ou le disque ne peut plus lire correctement d’anciennes données.

Que faire : remplacez le disque. Ne négociez pas. En vdev mirror vous avez de l’air ; en RAIDZ vous avez des mathématiques, pas de pitié.

Pattern B: One device, checksum errors + SMART UDMA CRC errors

Coupable probable : la couche de transport. Les erreurs CRC pointent souvent vers câble/backplane/connecteur. Avec des expanders SAS, cela peut être une voie marginale.

Que faire : réinsérez et remplacez le câble ; déplacez le disque dans une autre baie ; si vous utilisez du SATA dans un backplane serveur, vérifiez l’ajustement et la tension. Ensuite effacez les erreurs et observez.

Pattern C: Multiple devices across one HBA/backplane show checksum errors

Coupable probable : composant partagé : HBA, expander, backplane, alimentation, ou bug de firmware. ZFS vous dit que la corruption est systémique, pas une tragédie disque-unique.

Que faire : corrélez les disques affectés à une chaîne de ports spécifique. Échangez le câble SAS. Mettez à jour le firmware du HBA vers une version connue stable. Vérifiez les rails d’alimentation et l’assise du backplane.

Pattern D: Checksum errors with no disk-level errors, plus kernel MCE/EDAC reports

Coupable probable : instabilité mémoire/plateforme CPU. Les checksums ZFS protègent l’intégrité sur disque, mais une mauvaise RAM peut corrompre les données avant qu’elles soient checksummées ou après lecture en mémoire.

Que faire : traitez comme un incident matériel de plateforme. Vérifiez que l’ECC est activé. Lancez un test mémoire en maintenance. Arrêtez l’overclock. Remplacez les DIMM avec des erreurs corrigées récurrentes.

Pattern E: Errors appear only after firmware updates or kernel upgrades

Coupable probable : interactions driver/firmware, comportement de profondeur de file d’attente, gestion d’alimentation, ou régression. Ce n’est pas glamour, mais cela arrive.

Que faire : revenez en arrière si possible, ou migrez vers une version corrigée. Conservez les preuves (events, logs). Ne « corrigez » pas en supprimant les erreurs.

Une citation, parce que l’exploitation est surtout une affaire d’humilité : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Blague #2 (courte, pertinente) : Effacer les erreurs ZFS sans corriger la cause revient à éteindre le voyant moteur en retirant l’ampoule. Cela réduit bien le bruit du tableau de bord.

Trois mini-histoires d’entreprise (étrangement familières)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’équipe a hérité d’un nœud de stockage qui « avait quelques erreurs de checksum depuis des mois. » La note de l’administrateur précédent indiquait que c’était un « disque connu mauvais » et « pas urgent parce que RAIDZ. » Cela semblait plausible, donc c’est resté au bas du backlog avec toutes les autres choses plausibles.

Puis un scrub de routine a démarré un dimanche matin. À mi-chemin, les erreurs de checksum ont commencé à augmenter sur deux disques différents du même vdev. L’on-call a remplacé d’abord le « disque connu mauvais », en s’attendant à ce que les erreurs s’arrêtent. Elles ne l’ont pas fait. En fait, pendant le resilver, un troisième disque a commencé à enregistrer des resets de transport. Le pool est alors devenu dégradé et furieux.

L’hypothèse erronée était subtile : ils supposaient que les erreurs de checksum se comportent comme des secteurs réalloués SMART — spécifiques au disque et locaux. Mais les erreurs de checksum ZFS sont souvent spécifiques au chemin. Après une heure frénétique à échanger des disques, quelqu’un a enfin vérifié les logs noyau et a remarqué des resets de lien répétés sur le même port SAS.

La cause racine s’est révélée être un câble breakout SAS marginal qui avait été plié d’une manière qui avait l’air correcte en photo et désastreuse en physique. Le câble fonctionnait sous faible charge et échouait sous scrub/resilver soutenu. Une fois remplacé, le « mauvais disque » n’était plus mauvais. L’équipe a retenu la leçon : une erreur de checksum est une preuve de corruption, pas un verdict sur un disque spécifique.

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

Une autre entreprise menait une initiative performance : réduire le temps de scrub et les fenêtres de sauvegarde. Ils ont augmenté le parallélisme dans leurs jobs de sauvegarde et réglé la pile stockage pour le débit. Les scrubs terminaient plus vite, les tableaux de bord semblaient plus verts, et tout le monde félicitait le tableur.

Un mois plus tard, des erreurs de checksum ont commencé à apparaître pendant les scrubs sur plusieurs pools — surtout sur des systèmes avec des expanders plus anciens. Les lectures étaient désormais plus agressives et plus concurrentes. Les expanders ont commencé à montrer leur âge : petits flaps de lien, retries, et événements de corruption subtils que ZFS a détectés comme des mismatches de checksum.

L’optimisation n’a pas « causé » la corruption à partir de rien. Elle a transformé un système marginal en échec reproductible. Auparavant, l’environnement ne soutenait jamais suffisamment longtemps ce pattern I/O pour exposer la faiblesse. Maintenant il le faisait, et de préférence pendant les heures de pointe.

La correction n’a pas été de réduire la performance pour toujours. Ils ont déplacé les scrubs vers une fenêtre plus calme, réduit la concurrence pendant les scrubs, mis à jour les firmwares d’expander quand c’était sûr, et remplacé le matériel le plus mauvais. Mais la correction la plus importante a été culturelle : le tuning de performance exige désormais un plan de test de fiabilité, pas seulement un graphique de débit.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Dans une entreprise, l’équipe stockage avait une habitude qui semblait bureaucratique : chaque trimestre ils lançaient un scrub, exportaient le dernier rapport de scrub, et archivaient les sorties zpool status -v avec les logs noyau de la fenêtre. Ils étiquetaient aussi les baies de disque avec les sérials by-id. C’était ennuyeux. C’était aussi exactement ce qu’on veut pendant un incident réel.

Une nuit, les erreurs de checksum ont grimpé sur un membre mirror. Parce qu’ils avaient des artefacts de référence, ils ont su deux choses immédiatement : le disque n’avait jamais montré d’erreurs CRC auparavant, et la baie avait un historique de resets de lien il y a deux ans avec un disque différent. Même baie. Disque différent. Même famille de symptômes.

Ils ont échangé le câble de la baie pendant une fenêtre de maintenance, effacé les erreurs, et lancé un scrub contrôlé en regardant les logs. Aucune nouvelle erreur. Ils ont laissé le disque en place et l’ont gardé sous observation. S’ils avaient suivi l’instinct par défaut — remplacer le disque — ils auraient gaspillé du temps, de l’argent, et probablement déclenché plus de perturbations.

Le résumé pour la direction était aussi ennuyeux : « Nous avons réparé un interconnect défectueux et validé l’intégrité. » Pas de drame, pas d’exploits, juste un système qui tient ses promesses. C’est le métier.

Erreurs courantes : symptôme → cause racine → fix

1) « Les erreurs de checksum augmentent, donc remplacez le disque immédiatement »

Symptôme : CKSUM incrémente, mais SMART montre des UDMA CRC croissants et pas de réallocations.

Cause racine : corruption du câble/backplane/connecteur, pas défaillance du média.

Fix : remplacez/réinsérez les câbles, déplacez le disque vers une autre baie, vérifiez les connecteurs du backplane ; puis scrub et observez.

2) « Nous avons effacé les erreurs et elles ont disparu, donc c’est résolu »

Symptôme : Quelqu’un a exécuté zpool clear ; le tableau de bord est calme pendant une semaine.

Cause racine : les compteurs ont été remis à zéro ; la cause sous-jacente demeure. Vous venez de perdre les tendances.

Fix : traitez zpool clear comme une étape post-remédiation avec des scrubs de suivi et de la surveillance.

3) « Les erreurs sont apparues après un scrub, donc le scrub a causé la corruption »

Symptôme : La première fois que quelqu’un a remarqué les erreurs, c’était pendant un scrub.

Cause racine : le scrub a lu les données et découvert une corruption existante ou a stressé du matériel marginal en révélant ses défauts.

Fix : continuez les scrubs ; changez quand/comment vous scrubez ; réparez le matériel faible et vérifiez avec des scrubs contrôlés.

4) « Le pool est ONLINE, donc les données sont saines »

Symptôme : Le pool affiche ONLINE mais les compteurs CKSUM des périphériques sont non-nuls.

Cause racine : la redondance a masqué la corruption, mais la corruption a bien eu lieu.

Fix : enquêtez, remédiez, et confirmez qu’il n’y a pas de nouvelles erreurs sous charge. ONLINE n’est pas un certificat de santé complet.

5) « Plusieurs disques ont des erreurs de checksum, donc nous avons eu plusieurs pannes disque »

Symptôme : Plusieurs disques du même châssis montrent des incréments CKSUM dans la même heure.

Cause racine : composant partagé (HBA, expander, backplane, PSU) défaillant.

Fix : cartographiez la topologie ; ciblez le point commun ; vérifiez les logs pour des resets ; échangez les câbles et testez.

6) « ZFS est trop sensible ; désactivez les checksums »

Symptôme : Quelqu’un suggère de désactiver la vérification par checksum ou d’ignorer les événements.

Cause racine : mauvaise compréhension : ZFS détecte une corruption réelle que votre pile auparavant ignorait.

Fix : conservez le checksumming ; réparez le chemin matériel ; améliorez la surveillance et les fenêtres de maintenance.

7) « Les erreurs ECC corrigées sont sans danger »

Symptôme : Les logs EDAC montrent des erreurs corrigées ; le stockage voit des soucis de checksum occasionnels.

Cause racine : les erreurs corrigées peuvent être un signal d’alerte précoce. Des erreurs non corrigées peuvent suivre ; la stabilité peut déjà être compromise.

Fix : planifiez le remplacement des DIMM, vérifiez l’assise, mettez à jour BIOS/microcode si pertinent, et validez avec des tests de charge.

8) « Nous pouvons garder un pool dégradé pendant des jours pendant le dépannage »

Symptôme : Un vdev RAIDZ est dégradé et quelqu’un veut attendre la procurement.

Cause racine : exposition prolongée : une défaillance supplémentaire et vous restaurez depuis la sauvegarde.

Fix : priorisez le rétablissement de la redondance immédiatement — pièces de rechange, remplacements temporaires, ou migration de workloads.

Listes de vérification / plan pas à pas

Étapes de triage (faire dans cet ordre)

1. Capturer l’état : sauvegardez la sortie zpool status -v et horodatez-la. N’effacez rien pour l’instant.
2. Vérifier si les erreurs sont réparables : cherchez « errors: No known data errors » vs chemins/fichiers listés.
3. Vérifier la tendance : exécutez zpool status à nouveau après charge ou après 10–30 minutes. CKSUM augmente-t-il ?
4. Vérifier les événements : zpool events -v pour relier les erreurs à scrub/resilver/lectures normales.
5. Vérifier les logs noyau : recherchez resets, erreurs de lien, timeouts pendant la même fenêtre.
6. Vérifier SMART/NVMe : en particulier CRC, réallocations/pending, media errors, journaux d’erreurs.
7. Cartographier la topologie : les disques affectés partagent-ils un port/backplane/expander ? Si oui, suspectez le composant partagé.
8. Remédier physiquement : réinsérer/remplacer le câble, déplacer les baies, échanger le port HBA, vérifier les connexions d’alimentation.
9. Effacer les erreurs : seulement après un changement, puis lancez un scrub contrôlé ou une charge de lecture en observant.
10. Remplacer le matériel si nécessaire : disque, câble, expander, HBA, DIMM — selon les preuves.
11. Vérifier : terminer un scrub sans nouvelles erreurs ; vérifier que les logs sont calmes ; surveiller les compteurs pendant une semaine.
12. Documenter : ce qui a changé, quelles preuves l’appuyaient, et à quoi ressemble le « normal » désormais.

Quand remplacer le disque (mes critères directs)

• SMART montre une augmentation des secteurs réalloués, de secteurs en attente, ou des Offline_Uncorrectable.
• NVMe rapporte media_errors non nuls ou des entrées répétées d’erreurs d’intégrité dans le journal.
• Les erreurs de checksum continuent d’augmenter sur le même disque après avoir échangé câbles/ports et vérifié que les logs sont propres.
• Le disque est l’exception dans un mirror (l’autre côté est propre) et le motif d’erreur suit le disque quand il est déplacé dans une nouvelle baie.

Quand suspecter câblage/backplane/expander d’abord

• Les UDMA CRC errors SMART augmentent.
• Les logs noyau montrent des resets de lien, des resets PHY, ou des erreurs de transport.
• Plusieurs disques dans la même enclosure/chaîne de ports montrent des problèmes.
• Les erreurs apparaissent pendant des lectures séquentielles soutenues (scrub/resilver) plutôt que sous une charge aléatoire.

Quand suspecter RAM/CPU/plateforme

• Les logs EDAC/MCE montrent des erreurs mémoire corrigées ou non corrigées.
• Les erreurs de checksum apparaissent sur des périphériques sans topologie physique cohérente.
• Vous observez des crashes inexplicables, des panics, ou des problèmes de données en dehors de ZFS aussi.
• Le système utilise de la RAM non-ECC pour des workloads importants.

Faits intéressants et contexte historique (ce que l’on apprend après s’être fait brûler)

• Fait 1 : ZFS a été créé chez Sun Microsystems au début des années 2000 avec l’objectif explicite d’intégrité des données de bout en bout, pas seulement d’un « système de fichiers rapide ».
• Fait 2 : Les piles de stockage traditionnelles s’appuyaient souvent sur le disque pour détecter les lectures mauvaises via l’ECC secteur ; la corruption silencieuse peut passer outre et retourner « succès ».
• Fait 3 : ZFS stocke les checksums dans les métadonnées plutôt qu’à côté du bloc de données, réduisant la probabilité qu’une mauvaise écriture corrompe à la fois les données et leur checksum.
• Fait 4 : Les scrubs ne sont pas du « théâtre de maintenance ». Ils lisent systématiquement le pool pour faire surgir les erreurs latentes avant que votre job de restauration ne les découvre.
• Fait 5 : L’arrivée de très gros disques a rendu normales les fenêtres longues de rebuild/resilver, ce qui a accru l’importance de détecter et réparer tôt la corruption silencieuse.
• Fait 6 : Les erreurs CRC SATA sont un indice classique « ce n’est pas le disque » depuis des décennies ; elles impliquent l’intégrité du signal et les connecteurs plus que le média.
• Fait 7 : Certains des incidents d’erreurs de checksum les plus coriaces impliquent des expanders/backplanes car ils créent des défaillances corrélées sur de nombreux disques à la fois.
• Fait 8 : ZFS peut réparer des données corrompues de façon transparente sur des vdevs redondants, mais il incrémentera quand même les compteurs d’erreurs — parce que vous avez le droit de savoir que c’est arrivé.
• Fait 9 : L’état « ONLINE » du pool peut coexister avec des problèmes sous-jacents sérieux ; ZFS privilégie la disponibilité tout en signalant les problèmes d’intégrité pour que vous puissiez agir.

FAQ

1) Les erreurs de checksum sont-elles toujours un signe de perte de données ?

Non. Si vous avez de la redondance et que ZFS rapporte « No known data errors », ZFS a probablement réparé les blocs mauvais. C’est quand même un signe de corruption quelque part, mais pas nécessairement une perte de données applicatives.

2) Quelle est la différence entre READ errors et CKSUM errors dans zpool status ?

Les READ errors signifient que le périphérique n’a pas pu fournir les données (échec I/O). Les CKSUM errors signifient qu’il a renvoyé des données qui ne correspondaient pas à la somme attendue. READ crie « je ne peux pas lire ». CKSUM murmure « j’ai lu quelque chose, mais c’est incorrect ».

3) Dois-je lancer un scrub immédiatement quand je vois des erreurs de checksum ?

En général oui — si vous pouvez le surveiller. Un scrub peut à la fois réparer et reproduire le problème sous charge, ce qui est excellent pour le diagnostic. Ne le lancez pas à l’aveugle dans une fenêtre risquée.

4) Est-il sûr d’exécuter zpool clear ?

C’est sûr au sens où cela ne supprime pas de données. C’est dangereux opérationnellement si vous l’utilisez pour masquer des preuves. Effacez après avoir remédié quelque chose, afin de pouvoir détecter une récurrence.

5) J’ai des erreurs de checksum sur un seul disque mirror. Puis-je les ignorer ?

Vous pouvez reporter le remplacement si le compteur est stable et que les preuves indiquent un événement ponctuel (comme un reset de lien transitoire). Vous ne devriez pas ignorer des augmentations récurrentes. Les mirrors pardonnent ; ils ne sont pas magiques.

6) La mauvaise RAM peut-elle provoquer des erreurs de checksum ZFS ?

Oui. Une RAM défectueuse peut corrompre les données en mémoire avant qu’elles ne soient écrites (ZFS calcule alors une checksum des données corrompues), ou corrompre après lecture. L’ECC réduit le risque et vous donne des preuves via EDAC/MCE.

7) Pourquoi les erreurs de checksum apparaissent-elles souvent pendant scrub/resilver ?

Parce que ces opérations lisent beaucoup de données et stressent tout le chemin I/O de façon continue. Les câbles marginaux, les expanders instables, et les disques limite détestent les charges soutenues et prévisibles.

8) Si SMART indique « PASSED », pourquoi ZFS rapporte-t-il des erreurs ?

Le « PASSED » SMART n’est pas un certificat de santé complet ; c’est un seuil minimal. ZFS mesure des résultats d’intégrité réels. Croyez le système qui valide les données de bout en bout.

9) Que faire si zpool status -v liste des fichiers avec erreurs ?

Cela signifie que ZFS a des known data errors qu’il n’a pas pu réparer. Votre arbre de décision change : identifiez les datasets impactés, restaurez depuis une sauvegarde/snapshot si possible, et adressez le matériel immédiatement.

10) Les erreurs de checksum signifient-elles que mon HBA est défectueux ?

Parfois. Si les erreurs se corrèlent sur plusieurs disques attachés au même port HBA ou apparaissent avec des resets/timeouts de contrôleur dans les logs, le HBA (ou son firmware/driver) monte rapidement dans la liste des suspects.

Étapes pratiques suivantes

Les erreurs de checksum sont ZFS qui fait son travail : détecter la corruption que le reste de la pile servirait joyeusement à vos applications. Votre travail consiste à transformer « CKSUM=14 » en une correction concrète.

1. Collectez d’abord les preuves : zpool status -v, zpool events -v, et les logs noyau autour des erreurs.
2. Classez le motif : périphérique unique vs multiples, scrub-seulement vs tout le temps, CRC vs réallocations, corrélation topologique.
3. Réparez la cause la plus probable (souvent câblage/backplane) avant d’échanger des disques à l’aveugle.
4. Effacez les erreurs seulement après un changement, puis lancez un scrub contrôlé en surveillant les logs.
5. Si les erreurs réapparaissent, remplacez le composant que les preuves désignent — disque, câble, expander, HBA ou DIMM — et vérifiez avec un scrub propre.

Si vous devez retenir une leçon opérationnelle : ne confondez pas ZFS qui signale un problème d’intégrité avec ZFS étant le problème. C’est le témoin. Traitez-le comme tel.