Surveillance SMART et ZFS : corréler les alertes de disque avec les erreurs ZFS

Un modèle mental : ce que ZFS sait vs ce que SMART sait

ZFS et SMART ne sont pas des rivaux. Ce sont deux témoins du même crime, postés à des coins de rue différents.
L’un a vu le visage du suspect. L’autre a entendu le crissement des pneus. Aucune histoire n’est complète seule.

ZFS : fondé sur des preuves, de bout en bout, et terriblement littéral

ZFS voit le monde à travers les opérations I/O et les sommes de contrôle. Quand ZFS lit un bloc, il valide la checksum.
Si la checksum ne correspond pas, ZFS appelle cela une erreur de checksum. Si le périphérique refuse de lire
ou d’écrire, ZFS appelle cela une erreur I/O. Si ZFS peut corriger des données corrompues grâce à la redondance (mirror/RAIDZ),
il incrémente des compteurs et continue, souvent pendant que vous dormez.

ZFS ne sait pas intrinsèquement pourquoi une lecture a échoué. Cela peut être la surface du plateau qui faillit. Cela peut être un port d’expander SAS défectueux.
Cela peut être un bug de firmware du contrôleur. Cela peut être un rayonnement cosmique. ZFS sait juste qu’il a demandé des données et qu’il a reçu quelque chose d’erroné.

SMART : prédictif, influencé par le fabricant, et parfois dramatique

SMART est un ensemble de compteurs auto-déclarés et de résultats de tests fournis par le firmware du disque. Il connaît les reallocations,
les secteurs en attente, les erreurs non corrigées, les erreurs CRC sur le lien SATA, et plus encore. Il peut lancer des auto-tests.
Il peut aussi masquer des problèmes via une « normalisation d’attribut » où la valeur brute compte mais la ligne “VALUE/WORST/THRESH”
essaie de vous rassurer jusqu’à ce qu’il soit trop tard.

SMART a aussi un gros angle mort : si le problème est en amont (câble, HBA, backplane, alimentation), le disque peut sembler sain
pendant que ZFS est noyé d’erreurs I/O. Ou SMART peut signaler des erreurs UDMA CRC qui hurlent « câble » tandis que les compteurs ZFS augmentent,
et vous serez tenté de RMA le disque parce que c’est satisfaisant émotionnellement.

La corrélation est la discipline qui consiste à se demander : ces signaux décrivent-ils le même mode de défaillance, et pointent-ils vers une action spécifique ?
C’est moins de la « surveillance » et plus un « contre-interrogatoire au tribunal ».

Une idée paraphrasée de Richard Cook (résilience opérationnelle) : Le succès en opérations vient de personnes qui s’adaptent continuellement à la complexité sous pression.

Faits intéressants et contexte historique

• ZFS a été conçu en tenant compte de la corruption silencieuse des données. Les checksums de bout en bout ont été une réaction aux piles de stockage qui supposaient que les disques « disaient généralement la vérité ».
• SMART précède les fonctions d’intégrité des systèmes de fichiers modernes. Il est apparu à une époque où l’OS avait très peu de visibilité sur le comportement interne du disque.
• Les attributs SMART ne sont pas standardisés en pratique. Les noms semblent cohérents ; le sens et l’échelle ne le sont souvent pas, surtout entre fabricants et générations de SSD.
• « UDMA CRC error count » est l’un des attributs les plus actionnables. Il indique souvent des problèmes de câblage/backplane plutôt qu’une défaillance du média.
• Les scrubs ZFS étaient controversés au début. On craignait que les scrubs « useraient » les disques ; en réalité, les scrubs sont la façon de découvrir des erreurs latentes avant qu’un rebuild n’impose le problème.
• Les premiers SMART des SSD étaient excessivement optimistes. Certains appareils indiquaient une santé quasi parfaite jusqu’à la panne ; la télémétrie NVMe moderne est meilleure mais pas infaillible.
• Les rebuilds RAID étaient autrefois « la partie effrayante ». Avec des disques multi-TB, les erreurs de lecture non récupérables pendant un rebuild sont devenues un risque pratique ; les scrubs et checksums ZFS aident à exposer les risques plus tôt.
• Les compteurs d’erreurs ZFS peuvent augmenter sans coupure visible pour l’utilisateur. Les lectures d’auto-réparation réparent silencieusement les données dans des vdevs redondants ; « pas de coupure » ne veut pas dire « pas de problème ».

La carte des signaux : alertes SMART ↔ erreurs ZFS

Commencez par les types d’erreurs ZFS (parce qu’elles sont liées à la correction des données)

• Erreurs de checksum : les données retournées par le périphérique ne correspondaient pas à la checksum attendue. Souvent des problèmes média, parfois corruption du contrôleur/câble, occasionnellement la RAM (si non-ECC et que vous avez la malchance).
• Erreurs de lecture / écriture : le périphérique a échoué l’I/O. Souvent des réinitialisations de lien, des timeouts, alimentation/câble, ou le périphérique qui abandonne.
• Retrait du périphérique / faulted : le système a perdu le périphérique. Pensez : alimentation SATA instable, reset d’expander, problème HBA, ou le disque qui se réinitialise.

Maintenant les attributs SMART qui méritent réellement votre attention

Les attributs SMART « utiles » sont ceux avec une signification physique claire et une corrélation décente avec la défaillance :
pending sectors, reallocated sectors, uncorrectable errors, et interface CRC errors.
La température compte aussi, mais surtout comme facteur de risque.

• Reallocated_Sector_Ct : secteurs que le disque a remappés. Non nul n’est pas une mort instantanée, mais une augmentation est une trajectoire.
• Current_Pending_Sector : secteurs qui n’ont pas pu être lus et attendent une réécriture pour remapper. C’est souvent l’attribut « perte de données imminente ».
• Offline_Uncorrectable / UNC : erreurs de lecture non corrigibles trouvées lors d’un scan hors-ligne ou des opérations normales.
• UDMA_CRC_Error_Count : corruption de données sur le lien (SATA). Presque toujours problème de câblage/backplane/connecteur, pas du média.
• SMART overall-health : utile quand il échoue ; peu fiable quand il passe.
• NVMe Media and Data Integrity Errors : un signal fort sur les dispositifs NVMe quand non nul et en augmentation.
• Power_On_Hours / Power_Cycle_Count : contexte. Des cycles d’alimentation fréquents corrèlent avec des pannes étranges et des problèmes de connecteur.

Schémas de corrélation sur lesquels vous pouvez parier votre week-end

Schéma A : erreurs de checksum ZFS + pending sectors (ou offline uncorrectables)

C’est le cas le plus clair. Le périphérique retourne de mauvaises données ou ne peut pas les lire de manière fiable. ZFS peut souvent les réparer grâce à la redondance,
mais votre travail est d’arrêter le pari. Lancer un scrub, collecter des preuves, remplacer le disque si les compteurs bougent.

Schéma B : erreurs I/O ZFS + UDMA CRC errors (SATA)

Ce n’est généralement pas le disque. C’est le chemin : câble, backplane, oxydation du connecteur, un splitter bon marché,
ou une baie « hot-swap » qui est plutôt « warm-swap si vous promettez de ne pas éternuer ».
Reseat/remplacez les câbles, changez de port, vérifiez l’alimentation. Si les CRC cessent d’augmenter, le disque est probablement sain.

Schéma C : périphérique ZFS faulted/retiré + SMART propre

Pensez alimentation et transport. Les disques peuvent disparaître sous une alimentation marginale, des resets d’expander ou des bugs de firmware HBA.
SMART n’enregistrera pas toujours cela parce que le disque n’a pas échoué en interne ; il a juste été arraché de la réalité.

Schéma D : SMART « PASSED » + erreurs de checksum ZFS

SMART overall-health est un instrument grossier. Certains disques ne déclarent pas la défaillance avant que la situation ne soit déjà critique.
Traitez les checksums ZFS comme prioritaires pour la correction des données, puis creusez dans les attributs SMART bruts et les logs de transport.

Schéma E : pas d’erreurs ZFS, alertes SMART en hausse

C’est là que les gens deviennent paresseux. ZFS n’a pas encore observé de données incorrectes. SMART vous dit que le disque fait
un effort supplémentaire pour se maintenir. Si les attributs SMART sont les « vrais » (pending/uncorrectable),
planifiez un remplacement contrôlé. Si c’est juste des pics de température ou une unique reallocation vieille de plusieurs années, surveillez étroitement.

Blague #1 : SMART, c’est comme le voyant de contrôle du moteur : parfois c’est catastrophique, parfois votre bouchon de réservoir est mal fermé, et dans tous les cas vous êtes en retard au travail.

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

Premier : découvrez ce dont ZFS se plaint

1. Exécutez zpool status -xv et lisez-le comme un contrat. Cherchez les compteurs READ, WRITE, CKSUM et tout message « trop d’erreurs ».
2. Identifiez le périphérique et le vdev exacts (par ID persistant, pas la roulette /dev/sdX).
3. Vérifiez si les erreurs augmentent encore (exécutez le status à nouveau après un peu d’I/O, ou après une minute). Les erreurs historiques statiques sont différentes des erreurs en cours.

Deuxième : décidez si ça sent le média vs le transport vs l’hôte

1. Suspicion média : erreurs de checksum sur un disque, pending/uncorrectable/reallocated SMART en hausse, auto-test échoué.
2. Suspicion transport : erreurs I/O, resets de périphérique, erreurs CRC, plusieurs disques sur le même port de backplane, logs kernel montrant des réinitialisations/timeouts de lien.
3. Suspicion hôte : erreurs sur de nombreux vdevs en même temps, resets HBA, messages PCIe AER, instabilité mémoire, bugs de firmware.

Troisième : choisissez une action sûre qui réduit rapidement le risque

1. Si la redondance est intacte : lancer un scrub pour forcer les lectures ; collecter SMART ; planifier le remplacement ou les travaux de câblage pendant les heures ouvrables.
2. Si la redondance est compromise (RAIDZ/mirror déjà dégradé) : stoppez les expériences. Minimisez la charge, appliquez une stratégie sérieuse de sauvegarde/snapshot, et remplacez d’abord le coupable le plus probable.
3. Si le périphérique clignote : stabilisez le transport (reseat/remplacez câble, changez de port) avant de resilver. Resilvering via un lien instable, c’est juste de l’art performance.

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

Ci-dessous des tâches pratiques que vous pouvez exécuter sur un hôte Linux ZFS typique (OpenZFS). Chaque tâche inclut : une commande, un extrait réaliste de sortie,
ce que cela signifie, et la décision à prendre. Faites-les dans l’ordre quand vous êtes d’astreinte. Faites-les au ralenti quand vous ne l’êtes pas.

Task 1: Confirm whether any pool is unhappy

cr0x@server:~$ zpool status -x
pool 'tank' is healthy
pool 'backup' has experienced errors

Signification : -x n’affiche que les problèmes. « Healthy » ne signifie pas « parfait », ça signifie qu’il n’y a pas de fautes connues nécessitant une action.

Décision : Si un pool n’est pas healthy, passez immédiatement à un status complet et verbeux et commencez à collecter des preuves avant de redémarrer quoi que ce soit.

Task 2: Get the detailed ZFS view (your primary source)

cr0x@server:~$ zpool status -xv backup
  pool: backup
 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:30 with 2 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                                     STATE     READ WRITE CKSUM
        backup                                   ONLINE       0     0     0
          raidz1-0                               ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ7...     ONLINE       0     0     2
            ata-WDC_WD80EFAX-68LHPN0_VKJ8...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9...     ONLINE       0     0     0

errors: No known data errors

Signification : Deux erreurs de checksum sont survenues et ont été corrigées. « No known data errors » signifie que ZFS pense avoir réparé ou isolé les dégâts.

Décision : Traitez les erreurs de checksum corrigées comme un avertissement. Ne réinitialisez pas encore les compteurs ; corrélez d’abord avec SMART et les logs de transport.

Task 3: Map the ZFS device ID to the OS block device

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7*
lrwxrwxrwx 1 root root 9 Dec 26 01:12 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX -> ../../sdc

Signification : L’ID persistant pointe actuellement vers /dev/sdc. Demain ce pourrait être différent.

Décision : Utilisez les chemins /dev/disk/by-id pour toutes les opérations de remplacement ZFS. Notez la correspondance slot/numéro de série pendant que vous êtes calme.

Task 4: Check SMART overall-health (quick but not decisive)

cr0x@server:~$ sudo smartctl -H /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Signification : Le disque ne déclare pas de défaillance. Ce n’est pas la même chose que « le disque est sain ».

Décision : Poursuivez avec les attributs bruts et les journaux d’erreurs. Ne laissez pas « PASSED » annuler les checksums ZFS.

Task 5: Pull SMART attributes that correlate with media failure

cr0x@server:~$ sudo smartctl -A /dev/sdc
=== START OF READ SMART DATA SECTION ===
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Signification : Des secteurs en attente et des erreurs non correctibles existent. C’est un disque qui n’a pas pu lire de manière fiable deux secteurs.

Décision : Si ce disque est dans un vdev redondant : planifiez son remplacement. Si c’est un pool sur disque unique : sauvegardez maintenant, puis remplacez. Lancez aussi un self-test long pour confirmation, mais n’attendez pas qu’il « s’aggrave ».

Task 6: Read the SMART error log (often shows the pattern)

cr0x@server:~$ sudo smartctl -l error /dev/sdc
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 42110 hours
  When the command that caused the error occurred, the device was active or idle.
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  00000000f3a1c2  ...  UNC

Signification : UNC indique une erreur de lecture non correctible à un LBA spécifique. Cela correspond aux pending/uncorrectable et aux problèmes de checksum ZFS.

Décision : Remplacez le disque selon votre calendrier, pas celui du disque. Avant le remplacement, lancez un scrub pour forcer ZFS à toucher autant de surface que possible.

Task 7: Run a SMART long test (evidence, not therapy)

cr0x@server:~$ sudo smartctl -t long /dev/sdc
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 780 minutes for test to complete.

Signification : Le disque va scanner le média. Cela peut révéler d’autres erreurs UNC.

Décision : Si le pool est dégradé ou si la charge est sensible à la latence, planifiez l’opération. Si vous avez déjà des secteurs en attente, vous n’avez pas besoin de ce test pour autoriser le remplacement.

Task 8: Check SMART self-test results

cr0x@server:~$ sudo smartctl -l selftest /dev/sdc
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       10%     42112         16062914
# 2  Short offline       Completed without error       00%     42001         -

Signification : Le test long a rencontré une erreur de lecture. C’est aussi proche que SMART devient d’une déclaration sous serment.

Décision : Remplacez le disque. Si vous avez des pièces de rechange, faites-le maintenant. Si l’approvisionnement est lent, au moins migrez les datasets critiques hors de ce vdev ou ajustez les plans de redondance.

Task 9: Look for transport/link issues in kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]|sas|reset|link|I/O error|blk_update_request' | tail -n 20
[Tue Dec 24 02:12:11 2025] ata7: hard resetting link
[Tue Dec 24 02:12:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 02:12:12 2025] ata7.00: configured for UDMA/133
[Tue Dec 24 02:12:12 2025] blk_update_request: I/O error, dev sdc, sector 16062914 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Tue Dec 24 02:12:13 2025] ata7.00: failed command: READ FPDMA QUEUED

Signification : Resets de lien + échecs de lecture. Cela peut être le disque ou le câble ; combinez avec SMART pour décider. Avec des UNC/pending présents, le disque est suffisamment coupable.

Décision : Si les CRC sont à zéro mais que des UNC existent, remplacez le disque. Si les CRC augmentent, réparez aussi le câblage ; vous pouvez avoir les deux.

Task 10: Check UDMA CRC specifically (classic “don’t RMA the cable”)

cr0x@server:~$ sudo smartctl -A /dev/sdd | egrep 'UDMA_CRC_Error_Count|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       41

Signification : Des erreurs CRC sont survenues sur le lien SATA. Si ce nombre augmente au fil du temps, votre chemin de transport corrompt ou perd des trames.

Décision : Reseat/remplacez le câble SATA, vérifiez les connecteurs du backplane, inspectez les splitters d’alimentation, et envisagez de déplacer le disque vers un autre port. Ne remplacez pas le disque uniquement pour des erreurs CRC sauf si d’autres preuves indiquent une défaillance média.

Task 11: Identify which physical slot a disk is in (stop guessing)

cr0x@server:~$ sudo udevadm info --query=all --name=/dev/sdc | egrep 'ID_SERIAL=|ID_SERIAL_SHORT=|ID_PATH=|DEVLINKS='
E: ID_SERIAL=WDC_WD80EFAX-68LHPN0_VKJ7XXXX
E: ID_SERIAL_SHORT=VKJ7XXXX
E: ID_PATH=pci-0000:3b:00.0-ata-7
E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX /dev/disk/by-path/pci-0000:3b:00.0-ata-7

Signification : Vous pouvez mapper le disque à un port contrôleur via by-path. Dans un châssis avec des baies étiquetées, cela vous évite d’extraire le mauvais disque.

Décision : Documentez la cartographie (serial → baie). Si vous ne pouvez pas mapper de manière fiable, vous n’opérez pas du stockage ; vous jouez avec le matériel.

Task 12: Run a scrub (controlled truth-finding)

cr0x@server:~$ sudo zpool scrub backup
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:05 2025
        1.12T scanned at 1.05G/s, 410G issued at 384M/s, 16.2T total
        0B repaired, 2.50% done, 11:42:16 to go

Signification : scrub force les lectures et la vérification des checksums. Si un disque est marginal, les scrubs provoquent souvent les erreurs que vous devez voir.

Décision : Si les erreurs augmentent pendant le scrub sur un seul périphérique, préparez le remplacement. Si des erreurs apparaissent sur plusieurs disques du même boîtier, suspectez le transport/l’alimentation/HBA.

Task 13: Inspect ZFS error details for affected files (when ZFS knows)

cr0x@server:~$ zpool status -v backup
  pool: backup
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
...
errors: Permanent errors have been detected in the following files:

        backup/media@autosnap_2025-12-25:some/path/video.mp4

Signification : ZFS n’a pas pu réparer les données pour ce fichier/bloc. Ce n’est pas une « alerte de monitoring ». C’est une perte de données.

Décision : Restaurez depuis une sauvegarde/snapshot/réplica. Ensuite, investiguez le matériel. Aussi : arrêtez de clear les erreurs ; vous avez besoin de la piste d’audit jusqu’à ce que la cause racine soit corrigée.

Task 14: Replace a failed disk correctly (use by-id)

cr0x@server:~$ sudo zpool replace backup ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX ata-WDC_WD80EFAX-68LHPN0_VNEW1234
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 02:01:44 2025
        1.84T scanned at 512M/s, 620G issued at 172M/s, 16.2T total
        610G resilvered, 3.74% done, 07:55:10 to go
config:

        NAME                                       STATE     READ WRITE CKSUM
        backup                                     ONLINE       0     0     0
          raidz1-0                                 ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ7XXXX           ONLINE       0     0     6  (resilvering)
            ata-WDC_WD80EFAX-...VKJ8YYYY           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ9ZZZZ           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VNEW1234           ONLINE       0     0     0  (resilvering)

Signification : Le resilver est en cours. ZFS conserve l’ancien périphérique jusqu’à la fin si possible. Les erreurs de checksum sur l’ancien périphérique peuvent continuer pendant qu’il est lu durant le resilver.

Décision : Surveillez la montée d’erreurs sur d’autres disques. Si le resilver ralentit fortement ou si les périphériques se réinitialisent, mettez en pause et corrigez le transport avant de forcer la procédure.

Task 15: Clear errors only after you’ve fixed the cause

cr0x@server:~$ sudo zpool clear backup
cr0x@server:~$ zpool status -xv backup
  pool 'backup' is healthy

Signification : Les compteurs sont réinitialisés. Ce n’est pas « guéri » ; c’est une « ardoise propre ».

Décision : Ne clear qu’après remplacement/réparation et après un scrub propre. Sinon vous supprimez vos propres preuves judiciaires et vous invitez la répétition des incidents.

Task 16: NVMe-specific SMART/health (different vocabulary, same job)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        47 Celsius
Available Spare:                    100%
Percentage Used:                    6%
Media and Data Integrity Errors:    12
Error Information Log Entries:      44

Signification : Des erreurs Media and Data Integrity non nulles et en hausse sont un fort prédicteur de problème pour NVMe.

Décision : Corrélez avec les erreurs checksum/I/O ZFS et les resets NVMe du kernel. Si les erreurs augmentent, planifiez le remplacement ; NVMe a tendance à échouer « vite » une fois que cela commence.

Blague #2 : Resilvering via un câble défectueux, c’est comme essayer d’éponger une fuite pendant que quelqu’un continue d’ouvrir le robinet—techniquement possible, spirituellement imprudent.

Trois mini-récits d’entreprise issus du terrain

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

Une entreprise SaaS de taille moyenne exploitait un magasin d’objets sur ZFS sur une paire de serveurs de stockage. La surveillance indiquait SMART « PASSED » partout.
ZFS signalait quelques erreurs de checksum pendant les scrubs, toujours corrigées, toujours sur le même vdev. L’astreinte traitait cela comme un bruit de fond inoffensif.

La mauvaise hypothèse était simple : « Si le pool est ONLINE et que SMART dit PASSED, le disque est sain. » C’est une histoire réconfortante parce qu’elle permet de ne rien faire.
Et ne rien faire est la stratégie opérationnelle la plus populaire sur Terre.

Quelques semaines plus tard, un disque de ce vdev a commencé à accumuler des comptes Current_Pending_Sector et Offline_Uncorrectable. Personne n’a regardé parce que personne n’avait de dashboards pour les attributs SMART bruts,
seulement le bit overall-health. Puis un second disque du même groupe RAIDZ a développé des timeouts de lecture pendant une fenêtre d’ingestion chargée.

ZFS a fait ce qu’il pouvait, mais RAIDZ n’est pas magique quand plusieurs membres sont malades. Le pool s’est dégradé, la performance s’est effondrée, et l’activité scrub/resilver s’est battue contre l’I/O de production.
L’incident n’était pas une perte de données instantanée — c’était pire d’un point de vue corporatif : une panne lente et bruyante avec des erreurs partielles et beaucoup de « retry later ».

Après incident, la correction fut ennuyeuse : alerter sur les attributs SMART bruts qui comptent, alerter sur les erreurs corrigées ZFS, et exiger une décision humaine quand l’un ou l’autre bouge.
L’équipe n’a pas éliminé les pannes de disque. Elle a éliminé la surprise.

Mini-récit 2 : L’optimisation qui a échoué

Une institution financière voulait des scrubs plus rapides. Ils avaient lu qu’augmenter le débit de scrub aide à détecter les erreurs latentes plus tôt.
Vrai. Ils voulaient aussi réduire les « fenêtres de maintenance », alors ils ont augmenté la parallélisation, programmé des scrubs en heures ouvrables, et ajusté le système pour prioriser l’I/O de scrub.

Les premiers scrubs furent fulgurants. Tout le monde s’est félicité. Puis ils sont tombés sur un vdev avec un disque marginal et une connexion de backplane SAS limite.
Le scrub agressif a produit une tempête : resets de lien, timeouts de commande, retries. Les compteurs ZFS ont augmenté. Les graphiques de latence sont devenus de l’art abstrait.

La morale est que l’optimisation a changé le mode de défaillance. Au lieu de découvrir quelques mauvais secteurs gentiment au fil du temps, ils ont forcé le système dans une charge de haute tension
qui a amplifié l’instabilité du transport et généré des pics de latence visibles par les clients. Pire, leur surveillance traitait « scrub in progress » comme « bruit de maintenance » et supprimait les alertes.

La remédiation n’était pas « ne plus scrub ». C’était : scrub régulièrement, mais ajuster l’impact du scrub, ne pas supprimer les mauvaises alertes, et traiter les erreurs de transport pendant le scrub comme un signal de priorité.
Ils ont aussi appris à étaler les scrubs entre hôtes et éviter les tempêtes d’I/O synchronisées.

Ils ont fini avec des scrubs plus lents et moins d’incidents. Ce compromis en valait la peine. La performance est une caractéristique ; la prévisibilité est un produit.

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

Une entreprise exploitait un grand pool ZFS pour stockage VM. Rien de glamour. Elle faisait trois choses de manière cohérente :
des scrubs mensuels, une revue hebdomadaire des attributs SMART bruts, et une nomination stricte des périphériques via /dev/disk/by-id avec une carte vivante serial→slot.

Un vendredi après-midi, ZFS a signalé quelques erreurs de checksum sur un disque pendant un scrub. SMART montrait UDMA_CRC_Error_Count en hausse, mais pas de secteurs en attente.
L’ingénieur en rotation n’a pas paniqué. Il n’a pas commandé une livraison de disque d’urgence. Il a suivi la checklist.

Il a reseat le disque, remplacé le câble SATA, et déplacé le port vers une autre voie contrôleur. Les CRC ont immédiatement cessé d’augmenter.
Le scrub suivant s’est terminé proprement. Les compteurs ZFS sont restés stables.

Le « sauvetage » n’a pas été un dépannage héroïque. C’était disposer d’une base et d’un mapping suffisants pour que l’ingénieur puisse toucher un seul câble en ayant confiance que c’était le bon.
Le compte-rendu de l’incident fut court. C’est ainsi que l’on sait que c’était une bonne journée.

Erreurs courantes : symptôme → cause racine → correction

1) « Erreurs checksum ZFS sur un disque, SMART dit PASSED »

Symptôme : ZFS CKSUM augmente ; SMART overall-health passe.

Cause racine : SMART overall-health n’est pas sensible ; les attributs bruts peuvent toujours montrer pending/uncorrectables. Ou la corruption est dans le transport (câble/contrôleur) et pas dans le média interne.

Correction : Vérifiez les attributs SMART bruts et le journal d’erreurs ; vérifiez les logs kernel pour des resets ; si pending/UNC existe, remplacez le disque. Si le pattern CRC/reset domine, réparez le câblage/HBA d’abord.

2) « Beaucoup d’erreurs I/O sur plusieurs disques dans le même boîtier »

Symptôme : Plusieurs membres d’un vdev montrent des erreurs lecture/écriture simultanément.

Cause racine : Composant partagé : backplane, expander, rail d’alimentation, HBA, firmware, ou un câble mini-SAS lâche.

Correction : Inspectez le chemin de transport ; échangez port/câble d’expander ; vérifiez la distribution d’alimentation. Ne remplacez pas en rafale plusieurs disques sauf si les erreurs média SMART corroborent.

3) « Les erreurs CRC augmentent mais ZFS est OK »

Symptôme : UDMA_CRC_Error_Count augmente ; ZFS ne montre pas encore d’erreurs.

Cause racine : L’intégrité du lien se dégrade ; les retries masquent le problème.

Correction : Remplacez/sécurisez les câbles, nettoyez les connecteurs, vérifiez le bon enfoncement. Si les CRC cessent d’augmenter, vous avez probablement évité un incident ZFS futur.

4) « Scrub repaired 0B mais a signalé des erreurs »

Symptôme : La sortie du scrub affiche des erreurs mais aucun octet réparé.

Cause racine : Les erreurs peuvent être des timeouts I/O ou des défaillances de transport transitoires plutôt que des corruptions réparables par checksum.

Correction : Examinez zpool status -v et les logs kernel ; vérifiez les erreurs CRC SMART et les resets du contrôleur. Réparez le transport ; relancez le scrub.

5) « Resilver est lent et redémarre sans cesse »

Symptôme : La progression du resilver stagne ; les périphériques se réinitialisent ; le pool oscille entre DEGRADED/ONLINE.

Cause racine : Instabilité du transport ou problèmes d’alimentation. Sous charge de rebuild, les liens marginaux échouent plus souvent.

Correction : Stabilisez câblage/backplane/alimentation d’abord. Envisagez de réduire la charge, de mettre en pause les jobs perturbateurs, et d’éviter les resets répétés de périphériques.

6) « J’ai clear les erreurs ZFS et maintenant on ne sait plus ce qui s’est passé »

Symptôme : Les compteurs historiques ont disparu ; les erreurs intermittentes reviennent ; pas de timeline.

Cause racine : zpool clear prématuré a effacé les preuves avant que la cause racine soit réparée.

Correction : Conservez les compteurs jusqu’après la remédiation et un scrub propre. Utilisez des notes de ticket pour enregistrer les compteurs avant/après et les valeurs SMART brutes.

7) « J’ai remplacé un disque et les erreurs ont suivi la baie »

Symptôme : Le nouveau disque montre immédiatement des erreurs, même baie/port.

Cause racine : Le slot de backplane, le câble, ou le port HBA est en faute.

Correction : Déplacez le disque vers une autre baie/port ; remplacez le câble/élément backplane suspect. Ne continuez pas à sacrifier des disques pour un connecteur défectueux.

8) « ZFS rapporte des erreurs permanentes, mais SMART semble propre »

Symptôme : zpool status -v liste des fichiers avec des erreurs permanentes.

Cause racine : Les données ont été écrites corrompues (par exemple corruption transitoire du chemin) et sont devenues la « vérité » en parité, ou la redondance n’a pas pu reconstruire à cause de fautes multiples.

Correction : Restaurez les données affectées depuis une sauvegarde/réplica ; puis dépannez le transport et la stabilité mémoire. Traitez cela comme un incident d’intégrité des données, pas seulement un remplacement de disque.

Checklists / plan étape par étape

Checklist A: When you get a SMART alert

1. Exécutez zpool status -xv. Si ZFS se plaint déjà, priorisez les signaux ZFS.
2. Identifiez le périphérique via le symlink /dev/disk/by-id. Enregistrez le serial et le by-path.
3. Collectez SMART : smartctl -H, -A, -l error, -l selftest.
4. Classez l’alerte SMART :
   • Pending/uncorrectable/reallocated en augmentation : planifiez le remplacement du disque.
   • CRC errors en augmentation : réparez câblage/backplane/port.
   • Température élevée : corrigez le refroidissement/flux d’air et re-vérifiez ; la chaleur accélère la panne.
5. Lancez un scrub si la redondance existe et que l’impact opérationnel est acceptable.
6. Décidez : remplacer le disque maintenant, planifier le remplacement, ou réparer le transport et surveiller.

Checklist B: When ZFS reports checksum or I/O errors

1. Ne clear pas les erreurs. Capturez la sortie zpool status -xv dans un ticket.
2. Vérifiez si les erreurs augmentent avec le temps. Si oui, traitez comme un incident actif.
3. Mappez le périphérique : ls -l /dev/disk/by-id/ et udevadm info.
4. Collectez les attributs SMART bruts et les journaux d’erreurs.
5. Vérifiez les logs kernel pour des resets/timeouts et pour des patterns de chemin partagé (plusieurs disques).
6. Si des indicateurs média existent : remplacez le disque avec zpool replace en utilisant by-id.
7. Si les indicateurs de transport dominent : réparez câblage/HBA/backplane, puis relancez un scrub.
8. Après remédiation : scrub propre, puis zpool clear pour réinitialiser les compteurs.

Checklist C: Before you declare victory

1. Vérifiez que le pool est stable : zpool status -x doit être silencieux.
2. Vérifiez qu’aucun compteur n’augmente pendant la charge normale.
3. Vérifiez que SMART CRC cesse d’augmenter (si c’était un problème de transport).
4. Planifiez un scrub de suivi (ou confirmez qu’un scrub s’est terminé proprement après la correction).
5. Mettez à jour votre documentation serial→slot pour que la prochaine fois soit plus rapide et moins créative.

FAQ

1) Lequel dois-je mieux faire confiance : ZFS ou SMART ?

Pour la correction des données, faites davantage confiance à ZFS. Pour prévoir qu’un disque va bientôt lâcher, les attributs SMART bruts aident.
SMART overall « PASSED » n’est pas un veto face aux erreurs de checksum ZFS.

2) Dois-je remplacer un disque après une seule erreur de checksum ?

Pas toujours. Une seule erreur de checksum corrigée peut être transitoire. La démarche : lancer un scrub, inspecter les attributs SMART bruts,
vérifier les logs de transport. Si les erreurs se répètent ou si SMART montre des pending/uncorrectables, remplacez. Si les CRC augmentent, réparez le câblage.

3) Quelle est la différence entre scrub et resilver pour le diagnostic ?

scrub lit et vérifie les données existantes dans le pool ; c’est un audit d’intégrité périodique. Resilver reconstruit les données sur un périphérique remplacé.
Les deux stressent les disques, mais resilver est plus urgent et plus risqué si le transport est instable car il reconstruit l’état sous charge.

4) Pourquoi je vois des erreurs ZFS mais « errors: No known data errors » ?

Parce que ZFS peut corriger certaines défaillances grâce à la redondance et enregistre quand il a dû le faire. « No known data errors » signifie qu’il pense que les données utilisateur sont cohérentes maintenant.
Cela ne veut pas dire que le matériel est sain.

5) Les UDMA CRC errors sont-elles une raison de RMA un disque ?

Généralement non. Les erreurs CRC impliquent le lien SATA : câble, connecteur, backplane, EMI. Remplacez le câble, reseat, changez de port.
Si les CRC cessent d’augmenter, vous avez corrigé le problème. Si le disque a aussi des pending/UNC, alors oui, le disque peut aussi être en panne.

6) Comment éviter de remplacer le mauvais disque ?

Utilisez le nommage persistant et la cartographie. Travaillez avec /dev/disk/by-id. Confirmez le serial via smartctl -i et mappez la baie via by-path ou les outils d’enclosure.
Ne vous fiez jamais aux noms /dev/sdX pour une maintenance planifiée.

7) Dois-je lancer des tests SMART longs sur des disques en production ?

Oui, mais avec intention. Les tests longs peuvent ajouter de la charge et de la latence. Programmez-les, étalez-les, et ne les exécutez pas quand le pool est dégradé sauf si vous collectez des preuves urgentes.
Si vous avez déjà des indicateurs forts de panne, remplacez plutôt que de « tester jusqu’à ce que ça empire ».

8) Que faire si SMART montre des secteurs en attente mais ZFS n’a pas d’erreurs ?

Les secteurs en attente signifient que le disque n’a pas pu lire certaines données de manière fiable. ZFS peut ne pas avoir touché ces blocs récemment.
Lancez un scrub pour forcer les lectures. Si pending/uncorrectable persiste ou augmente, remplacez le disque tant que la redondance est intacte.

9) Une mauvaise RAM peut-elle causer des erreurs de checksum ZFS qui ressemblent à des problèmes de disque ?

Oui, bien que ce soit moins fréquent que certains ne le prétendent quand ils veulent éviter de remplacer un disque. Si des erreurs de checksum apparaissent sur plusieurs périphériques ou se déplacent,
considérez la mémoire/CPU/PCIe de l’hôte. L’ECC aide ; il ne rend pas immortel.

10) Pourquoi les erreurs augmentent-elles pendant les scrubs ?

scrub lit tout. Les erreurs médias latentes qui n’étaient jamais exercées sous la charge normale sont soudainement sollicitées.
Les problèmes de transport apparaissent aussi parce que le débit soutenu augmente la chance de resets/timeouts.
Un scrub qui révèle des erreurs fait son travail ; l’erreur serait d’ignorer les résultats.

Conclusion : prochaines étapes réalisables aujourd’hui

Corréler les alertes SMART avec les erreurs ZFS ne consiste pas à collecter plus de graphiques. Il s’agit de transformer deux sources imparfaites de vérité en une décision.
Vos meilleurs résultats sont ennuyeux : un échange de disque planifié, un câble remplacé, un scrub qui s’achève proprement, et un ticket qui se clôt sans drame.

1. Standardiser l’identification : exploitez ZFS en utilisant /dev/disk/by-id et gardez une carte serial→slot.
2. Alerter sur les attributs SMART bruts signifiants : tendances pending, uncorrectable, reallocated ; CRC errors pour le transport.
3. Considérer les erreurs ZFS corrigées comme des signaux actionnables : pas des urgences, mais pas du bruit de fond non plus.
4. scrub régulièrement et avec intention : étalez les scrubs, surveillez les erreurs pendant le scrub, et ne supprimez pas les alertes dont vous avez réellement besoin.
5. Ne clear les compteurs qu’après correction : preuves d’abord, cosmétique ensuite.

L’objectif n’est pas zéro alertes. L’objectif est moins de surprises, et moins de week-ends passés à apprendre la signature acoustique exacte d’un disque qui meurt.