Erreurs de checksum ZFS sur Proxmox : disque ou câble — comment le prouver

décembre 26, 2025 • février 3, 2026 • Lecture : 28 min • Views: 8

Cet article vous a aidé ?

Vous administrez un serveur Proxmox. ZFS a été ennuyeusement fiable (la meilleure forme de stockage). Puis un matin, vous le voyez : CKSUM qui augmente dans zpool status. Le pool est toujours en ligne, les VM démarrent encore, et votre esprit commence déjà à marchander : « C’est probablement juste un artefact de scrub. »

Non. Les erreurs de checksum ZFS sont ZFS qui fait son travail : vous dire qu’il a lu des octets qui ne correspondaient pas à ce qu’il avait précédemment écrit. Votre tâche est de prouver où la corruption s’est produite : sur le plateau/NAND, dans l’électronique du disque, dans le câble, dans le backplane, ou dans le HBA. Deviner, c’est acheter la mauvaise pièce deux fois.

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

ZFS stocke des checksums pour les blocs et les vérifie lors de la lecture. Si le checksum ne correspond pas, ZFS signale une erreur de checksum. C’est une déclaration sur les données au moment de la lecture, pas une confession du disque. Le disque peut retourner « succès » tout en renvoyant de mauvais octets ; ZFS le remarque quand même.

Voici la nuance importante :

Les erreurs de checksum sont des défaillances d’intégrité bout en bout. La corruption peut provenir du média sur disque, du firmware du disque, du contrôleur, du câble, du backplane, de l’expander, de la RAM, du DMA, ou d’un problème du noyau/du pilote.
ZFS peut souvent les réparer automatiquement si la redondance existe (mirror/RAIDZ) et que la copie saine peut remplacer la mauvaise copie. C’est pourquoi vous pouvez voir des erreurs de checksum sans impact visible sur les applications — jusqu’à ce que vous en voyiez.
Ce n’est pas la même chose qu’une erreur de lecture. Une erreur de lecture signifie « je n’ai pas pu lire le secteur ». Une erreur de checksum signifie « j’ai lu quelque chose, mais ce n’est pas ce que vous aviez écrit auparavant ».

Si vous utilisez des mirrors ou RAIDZ, ZFS peut souvent vous dire quel membre de vdev a fourni les mauvaises données. C’est votre point de départ. Mais « quel dispositif a livré les mauvais octets » n’est pas toujours « quel dispositif est défectueux ». Les câbles et les HBA se trouvent entre les deux et adorent échouer de manière intermittente.

Une citation à garder : « La seule fiabilité réelle est la fiabilité que vous mesurez. » — John Allspaw (idée paraphrasée)

Playbook de diagnostic rapide (premier/deuxième/troisième)

En production, vous n’avez pas le temps de devenir philosophe sur l’entropie. Vous avez besoin d’un chemin rapide vers les causes probables, puis vous collectez des preuves jusqu’à pouvoir justifier un remplacement de pièce.

Premier : confirmer l’étendue et si ZFS a réparé quelque chose

Le pool est-il dégradé, ou montre-t-il seulement des erreurs historiques ?
Les erreurs augmentent-elles en ce moment, ou sont-elles figées à un seul nombre ?
Est-ce que zpool status -v liste des chemins de fichiers (métadonnées) ou seulement des comptes ?

Second : corréler les erreurs ZFS avec les erreurs de transport du noyau

Cherchez des resets de lien ata, des I/O error, des commandes frozen, des phy reset SAS, ou des données de sense SCSI autour des mêmes moments que les scrubs/resilvers.
Si vous voyez une instabilité du transport, votre « disque défectueux » peut en réalité être un câble, un slot de backplane ou un port HBA.

Troisième : utiliser les journaux SMART/NVMe pour séparer défaillance média et défaillance de transport

La défaillance média se manifeste par des secteurs réalloués/pending/uncorrectable (HDD) ou des erreurs d’intégrité média (NVMe).
La défaillance de transport se manifeste par des erreurs CRC (SATA), des resets/timeout de lien (SAS/SATA), mais peut laisser propres les compteurs SMART média.

Puis vous décidez : swapper le câble/slot d’abord (bon marché, rapide) ou remplacer le disque d’abord (aussi rapide, mais plus risqué si c’est en réalité le slot et que vous « infectez » le remplacement).

Faits et contexte intéressants (parce que l’histoire se répète)

Le checksum bout en bout de ZFS était une réaction à la « corruption silencieuse des données » dans les piles traditionnelles où le système de fichiers faisait confiance aveuglément au disque.
Les compteurs CRC ATA UDMA existent parce que, même dans les années 1990, les ingénieurs acceptaient que les câbles et connecteurs sont des éléments de défaillance, pas des accessoires.
Les backplanes SAS d’entreprise ont introduit des expanders et davantage de connecteurs — plus de flexibilité, plus d’endroits où l’intégrité du signal peut être marginale.
Les câbles SATA grand public varient énormément en qualité ; certains sont essentiellement décoratifs, surtout à 6 Gb/s avec des tolérances serrées.
Les scrubs ZFS sont volontairement ennuyeux : ils lisent tout et vérifient les checksums, ce qui explique pourquoi ils découvrent souvent les liaisons faibles en premier.
Les mensonges du cache d’écriture sont plus anciens que votre carrière : un disque/contrôleur peut accuser réception d’un write puis le perdre. Les checksums ZFS détectent les conséquences à la lecture.
Le comportement des HDD CMR vs SMR peut créer de forts pics de latence I/O qui ressemblent à des timeouts ; les timeouts peuvent déclencher des resets qui ressemblent à un « câble défectueux », même quand le disque est simplement surchargé.
La RAM ECC compte parce que ZFS utilise intensivement la RAM ; la corruption en RAM peut devenir des « erreurs de checksum » plus tard. C’est plus rare que les câbles, mais pas mythique.

Cadre de preuves : où la corruption peut se produire

Quand ZFS affiche des erreurs de checksum pour /dev/sdX, vous devez décider qui accuser :

Le média du disque (surface/cellules NAND)
L’électronique/firmware du disque
Le transport (câble SATA, câble SAS, connecteurs)
Le backplane/expander (slot, pistes, puce expander)
Le HBA/contrôleur (port, firmware, erreurs PCIe)
L’hôte (RAM, problèmes PCIe, alimentation, pilote noyau)

L’astuce est d’éviter l’échec classique de logique : « ZFS a blâmé le disque, donc le disque est défectueux. » ZFS n’a pas de planche Ouija. Il a un nœud de périphérique et ce que ce chemin a livré au moment de la lecture.

À quoi ressemble généralement « le disque est mauvais » : SMART montre des secteurs réalloués/pending/uncorrectable ; les erreurs persistent même lorsqu’on déplace le disque vers un nouveau port/câble ; les erreurs ZFS suivent le même disque physique après des déplacements.

À quoi ressemble généralement « câble/slot est mauvais » : les compteurs média SMART sont propres, mais le UDMA CRC augmente (SATA) ou les logs du noyau montrent des resets de lien ; remplacer/déplacer le câble/slot fait cesser les erreurs, même avec le même disque.

Blague #1 (courte, pertinente) : Un câble SATA capricieux est le genre de « haute disponibilité » que vous n’avez pas demandée — il échoue seulement quand vous regardez.

Tâches pratiques (commandes, sorties, décisions)

Voici les tâches que j’exécute réellement sur des hôtes Proxmox/Debian. Chacune inclut ce que vous recherchez et quelle décision elle oriente. Exécutez-les dans l’ordre si possible ; sautez si la production est en feu.

Task 1 — Capturer une base propre : état du pool avec détails

cr0x@server:~$ sudo 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 0B in 02:11:43 with 3 errors on Sun Dec 22 03:12:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     3
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : ZFS a constaté des mismatches de checksum sur un appareil et les a corrigés grâce à la redondance (mirror). Le pool est toujours en ligne.

Décision : Traitez cela comme un signal d’intégrité réel. Commencez le travail de corrélation avant d’effacer les compteurs. Ne remplacez rien tant que les erreurs n’augmentent pas rapidement ou que le pool n’est pas dégradé.

Task 2 — Identifier le chemin exact du dispositif utilisé par ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFZX
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdc

Ce que cela signifie : Vous pouvez mapper les noms des membres ZFS à /dev/sdX pour la corrélation SMART et des logs du noyau.

Décision : Utilisez les noms dans /dev/disk/by-id dans les commandes ZFS (stables) et ne mappez à /dev/sdX que pour le diagnostic.

Task 3 — Récupérer les erreurs récentes du noyau pour ce disque (le transport SATA/SAS se trahit)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i "sdb|ata|scsi|sas|link reset|I/O error" | tail -n 30
Dec 26 02:41:12 server kernel: ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 02:41:12 server kernel: ata6: SError: { CommWake DevExch PhyRdyChg }
Dec 26 02:41:12 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Dec 26 02:41:12 server kernel: ata6: hard resetting link
Dec 26 02:41:13 server kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error

Ce que cela signifie : Vous observez des resets de lien et une erreur de lecture. Cela peut être un disque, mais l’instabilité du transport est fortement suggérée par les resets répétés/commandes frozen.

Décision : Si vous voyez beaucoup de resets de lien et du bruit SError, planifiez un test de déplacement de câble/slot. Mais vérifiez aussi SMART pour de vraies erreurs média, car les deux peuvent être vrais.

Task 4 — Vérifier la santé SMART et les compteurs qui séparent « média » et « transport » (HDD/SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Serial Number|SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count"
Serial Number:    WD-ABC123XYZ
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   199   000    Old_age   Always       -       12

Ce que cela signifie : Les compteurs média sont propres (0), mais des erreurs CRC existent. Les erreurs CRC sont des problèmes classiques de câble/connecteur/backplane pour SATA.

Décision : Remplacez le câble SATA ou déplacez le disque vers un autre slot/port de backplane en premier. Ne RMA pas un disque parfaitement sain parce qu’un câble à 3€ a un caractère.

Task 5 — Pour NVMe, vérifier les journaux d’erreurs et les erreurs média (vocabulaire différent)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i "critical_warning|media_errors|num_err_log_entries|temperature|percentage_used"
critical_warning                    : 0x00
temperature                         : 42 C
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : NVMe ne rapporte pas d’erreurs média. Cela ne l’innocente pas totalement, mais réduit la probabilité d’une dégradation NAND réelle.

Décision : Si des erreurs de checksum ZFS apparaissent sur NVMe avec des stats média propres, regardez de plus près les erreurs PCIe, l’alimentation, le firmware et le slot de la carte mère.

Task 6 — Vérifier les erreurs PCIe/AER (surtout pour les HBA et NVMe)

cr0x@server:~$ sudo journalctl -k --since "7 days ago" | egrep -i "AER|pcie|Corrected error|Uncorrected" | tail -n 40
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: [ 0] RxErr

Ce que cela signifie : Les erreurs de couche physique peuvent se manifester par des bizarreries de stockage. « Corrected » ne veut pas dire « sans conséquence » ; cela signifie « nous l’avons remarqué et corrigé, jusqu’à ce que ce ne soit plus possible ».

Décision : Si ces erreurs se corrèlent avec des erreurs ZFS, envisagez de reseater le HBA/NVMe, d’essayer un autre slot, de mettre à jour le firmware et de vérifier l’alimentation/les températures.

Task 7 — Lancer un scrub ZFS et observer si les erreurs de checksum augmentent pendant des lectures soutenues

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 09:31:12 2025
        1.32T scanned at 682M/s, 920G issued at 475M/s, 6.12T total
        0B repaired, 0.00% done, 03:45:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     5
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

Ce que cela signifie : Le compteur CKSUM augmente pendant le scrub. C’est une défaillance active, pas une résidu historique.

Décision : Cessez de traiter cela comme du ménage. Planifiez une atténuation immédiate : réduire la charge, préparer un chemin de remplacement et commencer à isoler le transport (swap câble/slot) ou le disque (remplacement) selon les preuves.

Task 8 — Effacer les compteurs seulement après avoir capturé des preuves

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:43 with 0 errors on Thu Dec 26 12:05:01 2025
config:

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

Ce que cela signifie : Les compteurs sont réinitialisés. Utile pour suivre une récidive, terrible si vous l’avez fait avant de collecter les logs.

Décision : N’effacez qu’après avoir sauvegardé la sortie de zpool status -v et les extraits pertinents de journalctl. Si les erreurs reviennent rapidement, vous avez la preuve d’un problème en cours.

Task 9 — Vérifier les autotests SMART (ils ne sont pas parfaits, mais admissibles comme preuve)

cr0x@server:~$ sudo smartctl -t long /dev/sdb
Please wait 728 minutes for test to complete.
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Self-test execution|# 1|error"
Self-test execution status:      241 (The previous self-test routine completed with a read failure)
# 1  Extended offline    Completed: read failure       90%     54123         12345678

Ce que cela signifie : Un test long a rencontré une erreur de lecture. C’est un fort indicateur d’un problème de disque/média, pas seulement un câble. (Les câbles peuvent encore causer des échecs de lecture, mais l’enregistrement SMART d’un échec de lecture tend à impliquer le disque.)

Décision : Si les tests longs échouent, priorisez le remplacement du disque. Vérifiez quand même le câblage si les CRC augmentent aussi, car un câble défectueux peut faire paraître coupable un disque sain.

Task 10 — Pour SATA, surveiller `UDMA_CRC_Error_Count` dans le temps (il ne doit pas croître)

cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12
cr0x@server:~$ sleep 60
cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       14

Ce que cela signifie : Les erreurs CRC ont augmenté pendant que le système tournait. Ce n’est presque jamais le « média du disque ». C’est l’intégrité du signal : câble, connecteur, ou backplane.

Décision : Remplacez le câble, reseat les connecteurs, changez de port/slot. Après le changement, le compteur CRC devrait cesser d’augmenter. Il ne se remettra pas à zéro, mais il devrait se stabiliser.

Task 11 — Mapper le disque à un emplacement physique (pour ne pas échanger la mauvaise pièce à 2h du matin)

cr0x@server:~$ sudo lsblk -o NAME,SERIAL,MODEL,SIZE,WWN,HCTL
NAME   SERIAL         MODEL         SIZE WWN                HCTL
sdb    WD-ABC123XYZ   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e4 5:0:0:0
sdc    WD-DEF456UVW   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e5 6:0:0:0

Ce que cela signifie : Vous avez des numéros de série et HCTL. Avec des HBA/backplanes, HCTL aide à mapper un port/slot. Avec SAS, vous pouvez aller plus loin en utilisant les adresses SAS.

Décision : Étiquetez les tiroirs/câbles. Si vous ne pouvez pas mapper physique → logique de manière fiable, vous finirez par remplacer un disque sain et garder le disque défectueux.

Task 12 — Vérifier la topologie SAS et les événements de lien (pour HBA/backplanes SAS)

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Serial|PHY|Link Rate|Error"
Enclosure# : 1
Slot #     : 4
Serial No  : WD-ABC123XYZ
PHY Error Count : 19
Negotiated Link Rate : 6.0 Gbps

Ce que cela signifie : Les erreurs PHY et les problèmes de négociation de lien impliquent le transport ou le chemin expander/backplane. Un seul slot montrant des erreurs alors que les autres sont propres est une flèche lumineuse pointant vers le slot/câblage.

Décision : Déplacez le disque vers un autre slot sur le même enclosure/backplane. Si les erreurs suivent le disque, c’est le disque. Si les erreurs restent avec le slot, c’est le slot/backplane/câblage/ligne HBA.

Task 13 — Vérifier les statistiques d’erreur SATA dans sysfs (utile quand SMART est bruyant ou incomplet)

cr0x@server:~$ for h in /sys/class/ata_link/link*/ata_link/*/dev*/../.. 2>/dev/null; do :; done
cr0x@server:~$ sudo grep -R . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link5/sata_spd:6.0 Gbps
/sys/class/ata_link/link6/sata_spd:6.0 Gbps

Ce que cela signifie : Vous pouvez confirmer la vitesse du lien et parfois constater des rétrogradations après des resets. Un lien qui tombe de 6.0 à 3.0 Gbps de manière répétée sous charge est suspect.

Décision : Si les rétrogradations se corrèlent aux erreurs, traitez-le comme un problème de câblage/backplane. Remplacez/reseatez, puis vérifiez la stabilité.

Task 14 — Lire intensivement le disque suspect (avec précaution) et surveiller les logs

cr0x@server:~$ sudo dd if=/dev/sdb of=/dev/null bs=8M status=progress
118111600640 bytes (118 GB, 110 GiB) copied, 25 s, 4.7 GB/s
240019120128 bytes (240 GB, 224 GiB) copied, 55 s, 4.4 GB/s
^C
cr0x@server:~$ sudo journalctl -k --since "5 minutes ago" | egrep -i "sdb|ata|reset|I/O error" | tail -n 20
Dec 26 09:52:41 server kernel: ata6: hard resetting link
Dec 26 09:52:45 server kernel: ata6.00: configured for UDMA/133
Dec 26 09:52:46 server kernel: blk_update_request: I/O error, dev sdb, sector 123456789 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Ce que cela signifie : Sous des lectures soutenues, le lien a reset et des erreurs I/O réapparaissent. Ce n’est pas « ZFS qui dramatise ». C’est la stabilité du transport ou du disque qui casse sous charge.

Décision : Si dd déclenche de manière fiable des resets de lien, vous pouvez reproduire la faute. Reproduisez une fois avant et une fois après avoir changé le câble/slot. Cela vous donnera une « preuve », pas des impressions.

Task 15 — Vérifier l’intégrité mémoire (rare, mais catastrophique si c’est la cause)

cr0x@server:~$ sudo dmesg -T | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
[Thu Dec 26 07:11:32 2025] EDAC MC0: 1 CE memory scrubbing error on CPU#0Channel#1_DIMM#0

Ce que cela signifie : Des erreurs ECC corrigibles sont enregistrées. Ce n’est pas une condamnation immédiate, mais cela signifie que la plateforme n’est pas impeccable. Les systèmes non-ECC ne vont pas le journaliser ; ils vont juste corrompre et sourire.

Décision : Si vous voyez de l’activité MCE/EDAC et des erreurs ZFS sur plusieurs vdevs/appareils, élargissez la portée au RAM/CPU/carte mère avant de remplacer une pile de « disques défectueux ».

Task 16 — Quand vous décidez de remplacer, faites-le à la manière ZFS (et conservez les preuves)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68... /dev/disk/by-id/ata-WDC_WD80EFZX-NEW123
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 10:12:40 2025
        1.88T scanned at 512M/s, 1.02T issued at 278M/s, 6.12T total
        1.02T resilvered, 16.66% done, 05:12:11 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          mirror-0                                        ONLINE       0     0     0
            replacing-0                                   ONLINE       0     0     0
              ata-WDC_WD80EFZX-68...                      ONLINE       0     0     0
              ata-WDC_WD80EFZX-NEW123                     ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...                        ONLINE       0     0     0

Ce que cela signifie : Resilver reconstruit la redondance. Surveillez les nouvelles erreurs de checksum pendant le resilver ; le resilver est un test de contrainte qui met souvent en évidence des câbles marginaux.

Décision : Si des erreurs de checksum apparaissent sur le disque nouveau immédiatement, arrêtez d’accuser les disques. Commencez à blâmer le port, le câble, la lane expander ou le HBA.

Trois mini-récits du monde de l’entreprise (comment ça déraille)

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

Une entreprise de taille moyenne exécutait Proxmox sur quelques serveurs de commodité. Pools de boot ZFS en mirror, RAIDZ pour le stockage VM. Un hôte a commencé à afficher des erreurs de checksum sur un seul disque. L’ingénieur d’astreinte a fait ce que tout le monde fait sous stress : il a remplacé le disque. Les erreurs se sont arrêtées. Tout le monde est retourné dormir.

Deux semaines plus tard, les erreurs de checksum sont revenues — cette fois sur le disque de remplacement. Cela a déclenché l’hypothèse « lot de disques défectueux ». Un autre remplacement a suivi. Même histoire : calme pendant un moment, puis retour des erreurs.

L’hypothèse erronée était subtile : « Si l’erreur apparaît sur le disque, le disque est la cause. » Ils n’ont jamais vérifié les compteurs CRC SATA. Ils n’ont jamais regardé dmesg pour des resets de lien. Le slot physique partageait un câble qui avait été fortement plié lors d’une maintenance précipitée.

Quand ils ont finalement remplacé le câble et déplacé le disque à une autre position de backplane, le compteur CRC a immédiatement cessé d’augmenter. Les disques originaux « mauvais », testés ailleurs, étaient en fait corrects. L’entreprise avait payé trois disques et perdu une nuit de sommeil parce qu’elle avait traité un problème de transport comme un problème de média.

La leçon retenue : ZFS disait la vérité (« de mauvais octets sont arrivés »), mais il ne disait pas toute la vérité (« où ils se sont abîmés »). Il faut interroger le chemin.

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

Une grande équipe plateforme interne voulait des rebuilds plus rapides et de meilleures performances VM. Ils ont ajouté un HBA avec plus de ports et sont passés du SATA direct à un backplane expander SAS pour simplifier le câblage. Le rack paraissait plus propre. La feuille d’inventaire paraissait plus propre. Tout le monde aime le propre.

Puis les temps de scrub sont devenus imprévisibles. Certains scrubs tournaient à pleine vitesse ; d’autres traînaient. Quelques hôtes ont montré des erreurs de checksum intermittentes, toujours « corrigées », jamais « fatales ». C’est le type de problème de stockage le plus dangereux parce qu’il habitue les gens à l’ignorer.

L’« optimisation » était qu’ils utilisaient des mini-SAS de qualité mixte et les faisaient passer serrés autour de la distribution d’alimentation. L’expander plus de longues courses de câble a réduit les marges de signal. Sous I/O peak (scrubs + snapshots VM), le chemin buggait occasionnellement. ZFS a fait son boulot : il a détecté la divergence, a récupéré les bonnes données depuis la parité/mirror et a guéri. La plateforme avait l’air fine — jusqu’au jour où un second disque du même vdev est tombé hors ligne pendant un resilver et la fenêtre de récupération est devenue étroite et stressante.

Ils l’ont résolu par des moyens ennuyeux : câbles de meilleure qualité, routage moins serré, et déplacer le HBA sur un slot avec moins d’erreurs PCIe corrigées. Les performances sont restées bonnes. Plus important, les scrubs sont redevenus cohérents et les erreurs de checksum ont cessé d’apparaître comme des allergies saisonnières.

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

Une équipe liée à la finance exécutait Proxmox avec des mirrors ZFS pour des bases de données critiques. Leur environnement n’était pas fancy, mais ils avaient l’habitude : scrubs planifiés mensuellement, et un runbook interne exigeant « résultats de scrub + deltas SMART » à examiner.

Un mois, le rapport de scrub a montré deux erreurs de checksum sur un membre mirror. Pas des centaines. Juste deux. SMART semblait propre sauf pour un compteur CRC qui avait augmenté d’un. Rien d’autre. Aucun ticket utilisateur. La tentation était de hausser les épaules.

Le runbook a forcé l’étape suivante : capturer les preuves, remplacer le câble, relancer un scrub sous 48 heures, et comparer. Après le remplacement du câble, le CRC a cessé d’augmenter. Le scrub s’est terminé proprement. Ils ont laissé le disque en place.

Trois mois plus tard, le même hôte a eu un événement d’alimentation (maintenance UPS qui a mal tourné). Les disques ont tenu, mais ce vieux câble aurait probablement rendu la récupération plus compliquée. Au lieu de cela, le pool est revenu propre. L’équipe n’a pas « sauvé la journée » par des actions héroïques. Elle l’a sauvée en étant ennuyeuse et régulière.

Erreurs courantes : symptôme → cause racine → correction

C’est là que la plupart des threads sur les checksums ZFS meurent : symptômes vagues et remplacements de pièces en mode cargo-cult. Voici des patterns spécifiques qui apparaissent sur des hôtes Proxmox.

1) CKSUM augmente pendant le scrub, SMART média a l’air parfait

Symptôme : zpool status montre CKSUM qui grimpe ; Reallocated/Pending/Uncorrectable sont zéro.
Cause probable : câble SATA ou connecteur de backplane provoquant des erreurs CRC ; ou erreurs PHY SAS.
Correction : Remplacez le câble, reseatez les deux extrémités, changez de port/slot, puis relancez un scrub et confirmez que les compteurs CRC/PHY cessent d’augmenter.

2) Un disque montre CKSUM, puis le disque de remplacement montre CKSUM dans la même baie

Symptôme : Vous avez remplacé le disque ; les erreurs reviennent sur le nouveau.
Cause probable : baie lane backplane défectueuse, port expander, ou port HBA défaillant.
Correction : Gardez le nouveau disque, déplacez-le dans une baie différente ; placez un disque sain connu dans la baie suspecte comme test si possible. Si les erreurs restent avec la baie, réparez/remplacez le backplane ou changez de port HBA.

3) Erreurs CHECKSUM sur plusieurs disques en même temps

Symptôme : Plusieurs périphériques dans différents vdevs montrent des augmentations CKSUM autour du même instant.
Cause probable : Systémique : problème HBA, erreurs PCIe, instabilité d’alimentation, RAM/MCE, ou chemin partagé expander/backplane.
Correction : Regardez les logs AER/MCE, le firmware HBA, l’alimentation/PSU, et les chemins expander partagés. Ne remplacez pas en rafale plusieurs disques sans réduire le composant partagé.

4) Le compteur CKSUM est non-zéro mais n’augmente jamais

Symptôme : Le compteur CKSUM historique reste constant pendant des semaines.
Cause probable : Événement transitoire passé : perte d’alimentation, un câble agité une fois, un hic du contrôleur ponctuel.
Correction : Effacez les compteurs après avoir capturé les preuves ; surveillez. Si ça revient, traitez comme actif. Sinon, consignez et passez à autre chose.

5) « No known data errors » mais tout le monde panique quand même

Symptôme : ZFS dit qu’il a réparé des erreurs ; aucun fichier listé.
Cause probable : La redondance a fonctionné. Mais cela indique toujours des problèmes de fiabilité sous-jacents.
Correction : Enquêtez sur le transport/média. N’ignorez pas. C’est votre système d’alerte précoce qui vous rend service.

6) Les erreurs apparaissent après que vous ayez changé recordsize, compression, ou activé un « tweak » de performance

Symptôme : Le timing suggère que la config a provoqué la corruption.
Cause probable : Ce n’est pas directement le réglage ZFS. Le plus souvent, cela a augmenté la pression I/O et exposé un câble/disque marginal qui ne défaillit que sous un débit soutenu.
Correction : Reproduisez sous charge ; vérifiez les erreurs de transport ; réparez le composant marginal. Ensuite décidez si le réglage est toujours pertinent pour votre charge.

Blague #2 (courte, pertinente) : Les pannes de stockage sont comme les réunions — si vous ne prenez pas de notes, vous les répéterez.

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

Checklist A — Prouver « disque » vs « câble/slot » avec un minimum de downtime

Capturer les preuves : sauvegardez la sortie de zpool status -v et l’extrait de logs du noyau autour de la dernière fenêtre de scrub/resilver.
Vérifier les compteurs SMART média : reallocated, pending, offline uncorrectable (HDD) ou media errors (NVMe).
Vérifier les compteurs de transport : UDMA_CRC_Error_Count SATA ; erreurs PHY SAS ; resets/timeouts de lien dans le noyau.
Effacer les erreurs ZFS : uniquement après capture des preuves.
Échanger le suspect le moins cher en premier : remplacez le câble SATA/SAS ou déplacez le disque vers une autre baie/port.
Relancer un scrub (ou un test de lecture contrôlé) : confirmez si les erreurs réapparaissent et si les compteurs CRC/PHY augmentent.
Si les erreurs suivent le disque à travers les ports : remplacez le disque.
Si les erreurs restent avec le port/baie : réparez le backplane/ligne HBA/câblage ; envisagez des mises à jour firmware HBA et des changements de slot PCIe.

Checklist B — Si le pool est dégradé (arrêtez de diagnostiquer, commencez à stabiliser)

Réduisez la charge : pausez les sauvegardes lourdes, la réplication et les scrubs agressifs.
Confirmez l’état de redondance : mirror vs RAIDZ, nombre de défaillances tolérées.
Exportez les preuves (état du pool, logs) quelque part de sûr.
Remplacez le composant le plus probablement défaillant selon les preuves, mais conservez l’ancien disque jusqu’à la fin du resilver et la validation par scrub.
Après le resilver, relancez un scrub. Pas de scrub, pas de confiance.

Checklist C — « Nous avons besoin de preuves pour les achats »

Montrer zpool status -v avec le membre exact et les compteurs CKSUM croissants.
Montrer les logs du noyau avec resets/timeouts de lien ou erreurs média liés à ce périphérique.
Montrer les deltas SMART : CRC en augmentation (câble) ou réalloués/pending en augmentation (disque).
Montrer le test A/B : après échange du câble/port, le problème s’arrête (câble) ou suit le disque (disque).

FAQ

1) Les erreurs de checksum ZFS signifient-elles toujours un disque en panne ?

Non. Ce sont des échecs d’intégrité. Les disques sont des coupables fréquents, mais les câbles, backplanes, HBAs, problèmes PCIe et la RAM peuvent tous produire le même symptôme.

2) Si SMART dit « PASSED », le disque peut-il quand même être mauvais ?

Oui. Le statut global SMART est un seuil bas. Regardez les attributs spécifiques (reallocated/pending/uncorrectable) et les résultats des autotests. Corrélez aussi avec les logs du noyau.

3) Quel est le meilleur signe unique d’un câble SATA défectueux ?

L’augmentation de UDMA_CRC_Error_Count. Une ou deux erreurs CRC historiques peuvent arriver ; un compteur qui continue d’augmenter sous charge est un connecteur en feu.

4) ZFS a réparé les erreurs. Puis-je les ignorer ?

Vous pouvez, mais vous dépensez la redondance comme si elle était gratuite. Aujourd’hui c’est un mismatch corrigeable ; demain c’est une seconde défaillance pendant un resilver. Enquêtez et corrigez la cause sous-jacente.

5) Dois-je lancer `zpool clear` immédiatement ?

Non. Capturez les preuves d’abord. Effacer tôt détruit la timeline et complique la preuve que la correction a fonctionné.

6) Pourquoi les erreurs apparaissent-elles pendant un scrub mais pas pendant l’activité VM normale ?

Le scrub force des lectures de surface complète et la vérification des checksums. C’est de l’I/O soutenu et une couverture large, ce qui expose le transport marginal et les médias faibles que les patterns d’accès normaux n’atteignent peut-être jamais.

7) Si je remplace le disque, quoi surveiller pendant le resilver ?

Surveillez les nouvelles erreurs de lecture/écriture/checksum sur n’importe quel membre, et surveillez les logs du noyau pour des resets. Le resilver est un test de contrainte pour toute la chaîne : disque, câble, HBA, expander, alimentation.

8) Les problèmes de RAM peuvent-ils ressembler à des erreurs de checksum disque ?

Oui. Une RAM défectueuse peut corrompre des données en mémoire avant qu’elles soient écrites ou après lecture. L’ECC réduit la probabilité et augmente l’observabilité via les logs EDAC/MCE.

9) La compression ou recordsize provoquent-elles des erreurs de checksum ?

Pas directement. Ces paramètres changent les patterns I/O et la charge CPU, ce qui peut déclencher des chemins matériels marginaux. Réparez la marginalité ; ne blâmez pas la compression juste parce que c’était le dernier changement.

10) Et si le pool est RAIDZ et que ZFS pointe un disque avec CKSUM ?

Traitez le cas de la même manière : vérifiez d’abord le transport/média pour ce disque. Mais souvenez-vous aussi que le resilver/scrub RAIDZ peut stresser tout le vdev ; surveillez attentivement les autres membres pendant le diagnostic.

Conclusion : prochaines étapes à faire aujourd’hui

Les erreurs de checksum ne sont pas un « problème ZFS ». Elles sont ZFS qui attrape le problème de quelqu’un d’autre avant vos applications. Votre mission est de transformer cet avertissement en un diagnostic défendable.

Faites ceci, dans cet ordre :

Capturez zpool status -v et la fenêtre de logs noyau pertinente.
Vérifiez les indicateurs média SMART/NVMe et les indicateurs de transport (CRC/PHY/resets).
Effacez les compteurs, puis reproduisez via un scrub ou une lecture contrôlée.
Échangez câble/slot/port d’abord quand les preuves pointent vers le transport (CRC/PHY, resets avec stats média propres).
Remplacez le disque quand les preuves média pointent vers le disque (test SMART long échoué, réalloués/pending/uncorrectable en hausse, erreurs qui suivent le disque).
Après toute correction, relancez un scrub. Si vous n’avez pas fait de scrub, vous n’avez pas vérifié.

Si vous suivez cette discipline, vous arrêterez de vous disputer avec des suppositions et vous irez dans la réserve de pièces avec des preuves. Les ingénieurs stockage aiment les preuves. C’est la seule chose qui survive à la prochaine revue d’incident.