Erreurs de lecture ZFS : disque, câble ou contrôleur

Un modèle mental : ce que ZFS peut prouver vs ce qu’il peut seulement suggérer

ZFS est un système de stockage avec des reçus. Chaque bloc a un checksum ; les métadonnées sont protégées ; la redondance (mirror/RAIDZ)
permet à ZFS de s’autoréparer en lisant une bonne copie et en réparant la mauvaise. C’est la partie que les gens retiennent.

La partie qu’on oublie : ZFS repose sur une pile I/O qui inclut pilotes, firmware, un contrôleur (HBA/carte RAID en IT mode),
un backplane, des câbles, l’alimentation, et enfin le contrôleur et le média du disque. Si une couche ment, réessaie, expire ou retourne des données corrompues
tout en prétendant que tout va bien, ZFS le détectera (mismatch de checksum) mais ne saura pas forcément où la corruption s’est produite.

Traitez donc les erreurs ZFS comme des indices sur une scène de crime :

• ZFS peut prouver que les données ne correspondent pas au checksum. Il ne peut pas prouver où la corruption a eu lieu.
• ZFS peut compter les erreurs d’E/S par périphérique. Il ne peut pas garantir que l’étiquette du périphérique correspond au disque physique si votre câblage est chaotique.
• ZFS peut réparer si la redondance existe et si la défaillance est transitoire. Il ne peut pas réparer si vous avez perdu la redondance et que la seule copie est corrompue.

Opérationnellement, vous voulez répondre rapidement à trois questions :

1. La confidentialité des données est‑elle en risque maintenant (plus que ce que votre redondance peut tolérer) ?
2. Le défaut est‑il localisé (un seul disque) ou systémique (chemin/contrôleur/backplane/alimentation) ?
3. Quelle est l’action la plus sûre qui améliore immédiatement les probabilités ?

Une règle utile : remplacez les pièces seulement après avoir réduit l’incertitude. Échanger la mauvaise pièce est la façon la plus sûre
de créer de « nouveaux » problèmes — par exemple décrocher un câble marginal et transformer un lien intermittent en lien mort.

READ vs CHECKSUM vs WRITE : ce que chaque erreur indique

READ errors : le périphérique n’a pas livré les données demandées

Une READ error dans zpool status signifie que ZFS dit « j’ai demandé des octets au bloc périphérique et j’ai reçu une erreur ».
Cette erreur peut provenir du disque (erreur média, reset interne), du lien (erreurs CRC provoquant l’abandon des commandes),
du contrôleur/du pilote (timeouts, resets), ou d’événements d’alimentation. Ce n’est pas aussi spécifique que les gens l’espèrent.

Si les READ errors sont isolées à un seul périphérique et que les logs OS montrent que ce périphérique rapporte des erreurs de média, le disque est un suspect prioritaire.
Si les READ errors sautent entre plusieurs disques derrière le même port HBA, le lien ou le contrôleur devient plus suspect.

CHECKSUM errors : les données sont arrivées, mais elles étaient incorrectes

Les CHECKSUM errors sont la carte de visite de ZFS. Le périphérique a retourné des données avec succès, mais le checksum ne correspondait pas.
Si la redondance existe, ZFS essaiera d’autres répliques/parité et corrigera la copie défaillante. Sinon, votre « lecture réussie » vous a livré de la corruption.

Les erreurs de checksum impliquent souvent le chemin : câbles SAS/SATA médiocres, un backplane capricieux, ou un contrôleur qui fait des choses « créatives ».
Elles peuvent aussi provenir de la RAM, mais si vous exécutez ZFS sans ECC et que vous voyez des CHECKSUM errors, ce n’est pas de la « malchance » —
c’est un point à revoir dans l’architecture.

WRITE errors : le périphérique a refusé d’accepter les données

Les WRITE errors sont plus directes : ZFS a tenté d’écrire et le chemin du périphérique a renvoyé un échec.
Des erreurs d’écriture persistantes pointent généralement vers un périphérique ou un chemin qui meurt ou se déconnecte de façon intermittente.

Le motif qui doit immédiatement changer votre posture :
des erreurs de checksum sur plusieurs périphériques en même temps. Ce n’est pas « deux disques qui tombent ensemble ».
C’est « quelque chose de partagé se comporte mal ».

Blague n°1 : RAID n’est pas une sauvegarde, et « nous n’avons jamais eu de problème » non plus. C’est juste un vœu déguisé en tableur.

Faits intéressants et contexte historique (ce qui explique les bizarreries d’aujourd’hui)

• ZFS a été créé chez Sun pour mettre fin à la corruption silencieuse des données. Le checksum sur chaque chose répondait aux piles de stockage qui « faisaient confiance au disque ».
• Les premiers SATA ont la réputation de « juste marcher » jusqu’à ce qu’ils cessent de le faire. Les câbles et connecteurs SATA grand public n’étaient pas conçus pour des châssis denses et soumis aux vibrations.
• SAS a été pensé pour des topologies expander/backplane. C’est pourquoi les compteurs d’erreurs SAS et le reporting au niveau lien peuvent être plus riches — si vos outils les exposent.
• Le cache des contrôleurs RAID cachait autrefois des problèmes disque. Un cache sur batterie pouvait masquer la latence et même réordonner les symptômes de défaillance, rendant les postmortems intéressants dans le pire sens.
• Les HBAs en IT mode sont devenus la norme pour ZFS parce que ZFS veut la vérité. ZFS attend des sémantiques de périphériques directs ; un firmware RAID qui remappe les erreurs peut saboter le diagnostic.
• Le reporting ATA des erreurs est incohérent selon les fabricants. SMART est utile, mais les vendeurs implémentent les attributs différemment et parfois de manière optimiste.
• Les UDMA CRC errors sont généralement des erreurs de chemin, pas des erreurs média. Si ce compteur augmente, suspectez d’abord les câbles, backplanes ou interférences électriques.
• Les retries internes du disque peuvent se manifester par une « latence aléatoire » avant d’apparaître comme défaillance. Au moment où vous voyez des erreurs dures, le disque peut lutter depuis des semaines.
• Les scrubs ZFS ont été conçus pour détecter les erreurs de secteurs latentes. L’idée est de trouver les secteurs défaillants tant que vous avez de la redondance, pas pendant une reconstruction quand vous ne l’avez plus.

Une idée paraphrasée de Werner Vogels : « Tout échoue, tout le temps. » Traitez‑le comme une contrainte de conception, pas comme une citation motivante.

Feuille de route de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Premier : établir l’étendue et le risque actuel

1. Exécutez zpool status -xv. Cherchez quels vdevs sont dégradés, si les erreurs augmentent, et si ZFS a réparé quoi que ce soit.
2. Vérifiez si un scrub/resilver est en cours et son ETA. Si vous êtes déjà dégradé, votre objectif est d’éviter d’ajouter du stress ou de déclencher d’autres défaillances.
3. Identifiez la marge de redondance. Mirror : vous pouvez perdre un côté. RAIDZ1 : un seul disque au total. RAIDZ2 : deux. Soyez brutalement honnête.

Deuxième : corrélez avec les preuves au niveau OS

1. Consultez dmesg / journald pour resets, timeouts, erreurs de lien. Si vous voyez « hard resetting link », « device offline » ou « COMRESET failed », vous êtes plutôt sur du câble/contrôleur.
2. Récupérez SMART, en particulier UDMA CRC et reallocated/pending sectors. Un CRC qui monte pointe vers le chemin ; des reallocated/pending pointent vers le disque.
3. Vérifiez si plusieurs disques sur le même port HBA ou expander montrent des symptômes. Un destin partagé suggère du matériel partagé en cause.

Troisième : agissez prudemment et vérifiez après chaque changement

1. Si les preuves pointent vers un disque : remplacez‑le. Ne « surveillez » pas si vous êtes déjà dégradé et que le disque lance des erreurs média.
2. Si les preuves pointent vers le chemin : resserrez/remplacez le composant le plus simple d’abord. Commencez par le câble, puis l’emplacement backplane, puis l’HBA — sauf si les logs hurlent autrement.
3. Après tout changement matériel : effacez les erreurs, lancez un scrub et surveillez les compteurs. « Réparé » signifie que les compteurs ne montent plus sous charge.

Tâches pratiques : commandes, sorties attendues et la décision que vous prenez

Task 1: Obtenir la liste officielle des symptômes ZFS

cr0x@server:~$ sudo zpool status -xv
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:11:09 with 0 errors on Tue Dec 24 03:12:21 2025
config:

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

errors: No known data errors

Ce que cela signifie : Un disque a accumulé des READ errors, mais ZFS indique que les applications ne sont pas affectées et qu’il n’y a pas d’erreurs de données connues.
Cela suggère que ZFS a eu la redondance nécessaire pour récupérer.

Décision : Vous n’avez pas fini. Il faut identifier si ces lectures sont un problème de disque (média) ou un problème de chemin (CRC/timeouts).
N’effacez pas les erreurs maintenant ; ce sont des miettes de preuves.

Task 2: Surveillez si les compteurs d’erreurs continuent d’augmenter

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

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

Ce que cela signifie : Les erreurs sont passées de 3 à 7. Quelque chose est toujours défaillant.

Décision : Montez l’urgence. Commencez immédiatement la corrélation avec les logs OS ; planifiez une action de maintenance (remplacer le disque ou réparer le chemin) aujourd’hui, pas « lors de la prochaine fenêtre ».

Task 3: Faire correspondre le device ZFS à un disque physique que vous pouvez toucher

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD80 | head
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdd1

Ce que cela signifie : Vous pouvez traduire le nom by-id en /dev/sdX.
Ne sautez pas cette étape : les gens remplacent le mauvais disque plus souvent qu’ils ne l’admettent.

Décision : Identifiez le nœud de périphérique suspect (par ex. /dev/sdc) et utilisez‑le systématiquement pour SMART et les logs.

Task 4: Inspecter les logs kernel pour resets de lien/timeouts (odeur de path/contrôleur)

cr0x@server:~$ sudo dmesg -T | egrep -i 'sdc|ata[0-9]|reset|timeout|failed command|I/O error' | tail -n 20
[Wed Dec 25 01:44:02 2025] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
[Wed Dec 25 01:44:02 2025] ata6.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:44:03 2025] ata6: SError: { CommWake DevExch }
[Wed Dec 25 01:44:03 2025] ata6: hard resetting link
[Wed Dec 25 01:44:08 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Sense Key : Medium Error [current]
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Add. Sense: Unrecovered read error

Ce que cela signifie : Vous avez à la fois du drame au niveau lien (hard resetting link) et une erreur média (unrecovered read error).
C’est là que le diagnostic devient épicé : un mauvais câble peut déclencher des resets ; un disque défectueux peut aussi provoquer des resets.

Décision : Lancez SMART ensuite. Si SMART montre des pending/reallocated sectors, le disque est suffisamment coupable pour être remplacé.
Si SMART est propre mais que les CRC augmentent, suspectez câble/backplane/contrôleur.

Task 5: Vérifier le résumé SMART et les attributs qui comptent

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i 'SMART overall|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature' 
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       -       12
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       7
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   074   074   000    Old_age   Always       -       22816
194 Temperature_Celsius     0x0022   110   099   000    Old_age   Always       -       40

Ce que cela signifie : SMART « PASSED » n’est pas une exonération. Vous avez 12 secteurs pending et 7 offline uncorrectables.
Ce n’est pas un câble ; c’est le disque qui avoue ne pas pouvoir lire certaines parties du plateau/du flash.

Décision : Remplacez le disque. Ne perdez pas de temps à échanger les câbles quand le média admet déjà sa défaite.

Task 6: Rechercher les UDMA CRC errors (preuve classique de câble/backplane)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'UDMA_CRC_Error_Count|Interface_CRC|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       43

Ce que cela signifie : Les CRC errors s’incrémentent lorsque le lien corrompt des trames. Les disques ne peuvent pas corriger cela par reallocation.
Quelques erreurs sur une longue durée peuvent arriver, mais un compteur qui grimpe sur une courte période est un problème de chemin matériel.

Décision : Resserrez/remplacez le câble SATA/SAS pour ce bay, vérifiez les connecteurs du backplane, et assurez‑vous que le disque est bien enclenché.
Après les changements, vérifiez que le compteur CRC cesse d’augmenter sous charge.

Task 7: Lancer un self-test SMART ciblé pour valider la suspicion

cr0x@server:~$ sudo smartctl -t long /dev/sdc
Please wait 780 minutes for test to complete.
Test will complete after Wed Dec 25 15:10:22 2025

Ce que cela signifie : Un test long force le disque à parcourir le média. S’il échoue, vous obtenez une preuve concrète.

Décision : Si vous ne pouvez pas attendre, remplacez maintenant. Si vous pouvez, laissez le test s’exécuter et vérifiez les résultats — utile pour négocier avec les achats.

Task 8: Lire les résultats du self-test SMART (l’étape « montrez votre travail »)

cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '/SMART Self-test log/,$p' | head -n 20
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%     22820         3912456672
# 2  Short offline       Completed without error       00%     22816         -

Ce que cela signifie : « Completed: read failure » avec un LBA est une preuve accablante de problème média.

Décision : Remplacez le disque, puis lancez un scrub après le resilver. Si vous êtes en RAIDZ1 et déjà dégradé, agissez vite et évitez les charges non essentielles.

Task 9: Identifier si les erreurs se regroupent par contrôleur / expander

cr0x@server:~$ lsscsi -t
[0:0:0:0]    disk    ata:WDC_WD80...  /dev/sdb  -  sata:ahci
[0:0:1:0]    disk    ata:WDC_WD80...  /dev/sdc  -  sata:ahci
[2:0:0:0]    disk    sas:SEAGATE...   /dev/sdd  -  sas:phy0
[2:0:1:0]    disk    sas:SEAGATE...   /dev/sde  -  sas:phy0

Ce que cela signifie : Vous avez des périphériques derrière différents hôtes/phys. Si tous les disques « sas:phy0 » montrent des checksum errors ensemble,
arrêtez de blâmer des « disques au hasard » et commencez à blâmer l’infrastructure partagée.

Décision : Regroupez les erreurs par hôte/port. Si le motif correspond à un seul HBA/expander, planifiez une maintenance sur ce composant.

Task 10: Inspecter les événements HBA/driver (les resets ne sont pas un bon signe)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt2sas|mpt3sas|sas|reset|ioc|task abort' | tail -n 30
[Wed Dec 25 01:20:11 2025] mpt3sas_cm0: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100)
[Wed Dec 25 01:20:12 2025] mpt3sas_cm0: sending diag reset !!
[Wed Dec 25 01:20:20 2025] mpt3sas_cm0: diag reset: SUCCESS
[Wed Dec 25 01:20:23 2025] sd 2:0:1:0: [sde] tag#91 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK

Ce que cela signifie : Le contrôleur a effectué un reset, et les disques ont vu DID_RESET. ZFS peut consigner des read/checksum issues parce que le flux d’E/S a été interrompu.

Décision : Traitez cela comme un territoire contrôleur/firmware/PCIe/alimentation. Vérifiez les versions de firmware, les erreurs PCIe et les conditions thermiques.
Si les resets se répètent, prévoyez un échange d’HBA plutôt que « on surveille ».

Task 11: Confirmer l’état de la couche PCIe (parce que les HBAs sont sur PCIe, pas sur des vibes)

cr0x@server:~$ sudo journalctl -k | egrep -i 'pcie|aer|corrected|uncorrected|fatal' | tail -n 20
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
Dec 25 01:20:10 server kernel: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:   device [8086:2030] error status/mask=00000040/00002000
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:    [ 6] Bad TLP

Ce que cela signifie : PCIe AER « Bad TLP » est la plateforme qui admet un problème de lien de données. Cela peut se manifester par des resets HBA et des erreurs d’E/S.

Décision : Resserrez l’HBA, vérifiez l’état du slot PCIe, contrôlez les réglages BIOS, et envisagez de déplacer l’HBA sur un autre slot.
Si les erreurs persistent, suspectez la carte mère / les risers.

Task 12: Effacer les erreurs seulement après avoir traité le problème sous‑jacent

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

Ce que cela signifie : Les compteurs sont réinitialisés. Parfait pour la visibilité, terrible si vous l’avez fait avant de réparer quoi que ce soit.

Décision : Appliquez maintenant une charge (charge normale ou un scrub) et confirmez que les compteurs restent à zéro.
S’ils remontent, votre « correction » n’était que de la mise en scène.

Task 13: Démarrer un scrub et interpréter ce qu’il trouve

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 02:05:18 2025
        1.20T scanned at 1.45G/s, 220G issued at 270M/s, 8.00T total
        0B repaired, 2.75% done, 08:07:12 to go
config:

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

Ce que cela signifie : Le scrub est propre jusqu’à présent et les compteurs restent à zéro. Voilà à quoi ressemble un « correctif ».

Décision : Laissez le scrub se terminer. S’il se termine sans erreurs et que les compteurs restent stables pendant la charge maximale,
vous pouvez clore l’incident avec une confiance raisonnable.

Task 14: Remplacer correctement un disque défaillant (et éviter l’incident du « mauvais disque »)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80...-part1 /dev/disk/by-id/ata-WDC_WD80_NEW_DISK-part1
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 25 02:12:44 2025
        620G scanned at 1.10G/s, 85.2G issued at 155M/s, 8.00T total
        85.2G resilvered, 1.04% done, 09:11:33 to go

Ce que cela signifie : Le resilver est en cours. Le statut DEGRADED est attendu jusqu’à sa fin.

Décision : Surveillez de nouvelles erreurs pendant le resilver. Si un autre disque commence à générer des erreurs pendant le resilver, arrêtez et réévaluez le risque :
vous pourriez être à un mauvais jour d’une perte de données (surtout en RAIDZ1).

Task 15: Vérifier l’historique des événements ZFS (utile si le compteur a déjà été effacé)

cr0x@server:~$ sudo zpool events -v | tail -n 25
Dec 25 2025 01:44:08.123456789 ereport.fs.zfs.io
        class = "ereport.fs.zfs.io"
        ena = 0x7f0b2c00000001
        detector = (embedded nvlist)
        (snip)
        vdev_path = "/dev/disk/by-id/ata-WDC_WD80...-part1"
        vdev_guid = 1234567890123456789
        io_error = 5

Ce que cela signifie : ZFS a enregistré des ereports I/O, y compris quel vdev path était impliqué. Utile pour reconstruire la chronologie.

Décision : Utilisez les events pour corréler avec les logs OS et les changements matériels. Si vous voyez des rafales d’événements alignées avec des resets de contrôleur, le contrôleur est suspect.

Blague n°2 : Si votre « solution rapide » est de redémarrer le serveur de stockage, ce n’est pas du dépannage — c’est la version IT de monter le son de la radio.

Disque vs câble vs contrôleur : reconnaissance de motifs qui tient la route

Quand c’est le disque

Les disques tombent en panne de façons à la fois prévisibles et exaspérantes. La partie prévisible : les erreurs média apparaissent sous forme de secteurs pending,
d’unable/offline uncorrectable, et de self-tests SMART qui ne peuvent pas se terminer. La partie exaspérante : beaucoup de disques « passent » SMART jusqu’au moment où ils ne passent plus,
parce que SMART est un ensemble de seuils définis par le fournisseur, pas une garantie.

Indicateurs favorables au disque :

• Current_Pending_Sector ou Offline_Uncorrectable est non nul et en croissance.
• Les logs kernel montrent Medium Error, « Unrecovered read error », ou des données sense similaires pour le même disque.
• Un SMART long test échoue avec une lecture ratée et un LBA.
• Les erreurs ZFS restent localisées sur une feuille de vdev unique dans le temps et à travers les reboots.

Remplacer un disque n’est pas un échec moral. C’est le travail. La seule vraie erreur est d’hésiter jusqu’à ce qu’un second composant échoue
pendant que vous débattez du premier.

Quand c’est le câble ou le backplane

Les câbles et backplanes n’ont pas assez de responsabilités : ils sont ennuyeux. Ils n’ont pas non plus de tableaux de bord de garantie.
Mais l’intégrité du signal est de la physique, et la physique se fiche de votre revue trimestrielle.

Indicateurs favorables au câble/backplane :

• UDMA_CRC_Error_Count augmente (surtout rapidement) alors que les attributs média semblent propres.
• Les logs kernel montrent des link resets, COMRESET failed, « SATA link down » ou « device offlined » sans erreurs média claires.
• Les erreurs se déplacent quand vous déplacez le disque dans un autre emplacement, ou quand vous échangez le câble.
• Plusieurs disques dans la même rangée de backplane/expander présentent des erreurs avec les vibrations/variations de température.

Conseil pratique : si vous utilisez du SATA dans un châssis dense, utilisez des câbles à verrouillage de qualité, minimisez les coudes, et traitez les backplanes comme des composants
ayant un cycle de vie. Si vous ne pouvez pas obtenir de câbles à verrouillage, vous n’êtes qu’à une traction accidentelle d’un incident.

Quand c’est le contrôleur (HBA, expander, firmware, ou PCIe)

Les contrôleurs échouent d’une manière unique : ils échouent « systémiquement », et ils échouent bruyamment dans les logs. Ils échouent aussi de façons qui ressemblent à des pannes disque,
parce que le disque est le messager qui se fait tirer dessus.

Indicateurs favorables au contrôleur :

• Les logs kernel montrent des mpt2sas/mpt3sas resets, des task aborts, des IOC resets, ou des resets de bus répétés.
• Les erreurs apparaissent sur plusieurs disques derrière le même HBA/expander, surtout dans la même fenêtre temporelle.
• Des erreurs PCIe AER se corrèlent avec des interruptions d’I/O.
• Changer les versions de firmware/driver modifie le motif des symptômes (parfois en mieux, parfois en « nouveau et excitant »).

Conseil tranché : si vous utilisez ZFS, votre HBA devrait être en IT mode, sur une version de firmware stable et reproductible,
et vous devriez pouvoir identifier exactement quels disques pendent de quels ports. Si vous ne le pouvez pas, vous êtes en train d’opérer à l’aveugle.

Le milieu confus : signaux mixtes et dommages secondaires

Les incidents réels impliquent souvent plus d’un facteur contributif :

• Un câble marginal provoque des resets de lien intermittents.
• Ces resets forcent les disques à entrer en récupération d’erreurs plus souvent.
• Un disque ayant des secteurs faibles doit maintenant retenter des lectures sous stress, et des secteurs pending apparaissent.

C’est pourquoi vous ne vous arrêtez pas à « c’est le disque » si les CRC explosent, et vous ne vous arrêtez pas à « c’est le câble » si SMART rapporte des uncorrectables.
Parfois la bonne réponse est : remplacez le disque et le câble, puis surveillez les resets du contrôleur qui ont déclenché toute la chaîne.

Trois mini‑histoires du monde d’entreprise (anonymisées, douloureusement plausibles)

1) L’incident causé par une mauvaise supposition

Une entreprise moyenne exploitait une ferme NFS sur ZFS pour des artefacts de build. Rien d’exotique : quelques pools RAIDZ2, des disques corrects,
et l’habitude d’ignorer les avertissements jusqu’à ce qu’ils deviennent des pages. Un matin, les développeurs se plaignent que les builds n’arrivent plus à récupérer des artefacts.
L’hôte de stockage affiche des read errors sur un disque d’un vdev.

L’ingénieur d’astreinte fit l’hypothèse classique : « READ errors = disque mort. » Il offlina le disque, alla au rack,
et tira le disque du bay qu’il croyait correspondre à /dev/sde. Il le remplaça, lança zpool replace,
et vit le resilver démarrer. Ça avait l’air compétent. Ce ne l’était pas.

Le problème : le châssis avait été recâblé des mois auparavant, et la cartographie physique n’avait jamais été mise à jour.
Le disque qu’il avait retiré n’était pas sde. C’était un disque sain, frère du même vdev. Le disque défaillant resta en ligne,
continuant à flancher, tandis que le pool travaillait en dégradé pendant le resilver. Puis le disque défaillant lança plus d’erreurs sous la charge du resilver et fut expulsé.
Le vdev était maintenant dans un état pire que le matin.

Ils se sont rétablis parce qu’ils avaient RAIDZ2, pas RAIDZ1, et parce que ZFS avait suffisamment de données cohérentes pour finir le resilver après une pause compliquée.
Le postmortem fut court et direct : la défaillance n’était pas le disque ; c’était l’hypothèse que les noms de périphériques correspondent aux emplacements sans vérification.

La correction n’était pas héroïque. Ils ajoutèrent une procédure : toujours cartographier by-id vers le bay physique en utilisant les outils d’enclosure ou les numéros de série,
et étiqueter le châssis. Ennuyeux. Correct. Le genre d’ennui qui préserve vos week‑ends.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation avait une plateforme analytique lourde en stockage. Ils étaient fiers de leur débit et voulaient toujours plus.
Quelqu’un remarqua que les scrubs « gaspillent de l’I/O » pendant les heures ouvrées, alors ils réduisirent la fréquence des scrubs et réglèrent ZFS pour limiter le travail en arrière‑plan.
Les tableaux de bord furent plus jolis. Un temps.

Des mois plus tard, un disque échoua lors d’un pic de charge. Le remplacement fut simple, mais le resilver fut lent.
Pendant le resilver, un second disque rencontra une unrecoverable read error sur un secteur qui n’avait pas été touché depuis des lustres.
ZFS ne put réparer le bloc car la parité restante ne couvrait pas la combinaison de défaillances.

La vérité désagréable : le secteur du second disque était mauvais depuis longtemps. Un scrub régulier l’aurait trouvé tant que la redondance était intacte,
et ZFS aurait réécrit le secteur mauvais à partir d’une bonne copie. En optimisant les scrubs, ils ont optimisé la disparition des avertissements précoces et de l’auto‑réparation.

Ils ont fini par restaurer un segment de données depuis des sauvegardes et retraiter certains jobs analytiques. L’impact business n’était pas existentiel,
mais c’était coûteux et embarrassant. L’ingénieur qui proposa le changement n’était pas négligent ; il optimisait un métrique sans comprendre ce que cela lui coûtait en intégrité et réduction du risque.

La nouvelle politique fut tranchée : faire des scrubs régulièrement, les throttler si nécessaire, mais ne pas les arrêter. Si vous devez choisir,
sacrifiez un peu de performance pour éviter de découvrir des erreurs latentes au pire moment.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société SaaS exploitait ZFS sur une flotte de nœuds de stockage. Le setup était volontairement simple : vdevs mirror pour le tier chaud,
RAIDZ2 pour le tier froid, RAM ECC partout, et une règle stricte de standardisation des HBAs et du firmware.
La règle agaçait parce qu’elle ralentissait les « mises à jour rapides ».

Un nœud commença à montrer des checksum errors intermittentes sur plusieurs disques d’une même étagère.
L’astreinte suivit le runbook : capturer zpool status, récupérer SMART, capturer les logs kernel,
et vérifier si les erreurs se corrélaient avec un port HBA particulier. Ils n’effacèrent pas les compteurs. Ils ne redémarrèrent pas.
Ils traitèrent le système comme des preuves.

Les logs montrèrent des resets de contrôleur répétés aux mêmes timestamps que les rafales de checksum.
SMART sur les disques était propre — pas de secteurs pending, pas d’uncorrectables, CRC stable. Ils remplacèrent un câble SAS et déplacèrent la connexion d’étagère
sur un port HBA de secours. Les erreurs cessèrent immédiatement, et le scrub s’acheva proprement.

La vraie « sauvegarde » survint une semaine plus tard. Un autre nœud montra des symptômes similaires, mais cette fois les compteurs CRC montèrent rapidement.
Parce qu’ils avaient des métriques de base pour CRC et resets, la déviation fut évidente en quelques minutes.
Ils échangèrent le câble avant que tout pool ne soit dégradé.

Rien de tout cela n’est glamour. La pratique qui les a sauvés fut la constance : firmware standard, ECC, scrubs réguliers,
et l’habitude de collecter les mêmes preuves à chaque fois. Leur rapport d’incident fut court. Leur sommeil, long.

Erreurs courantes : symptôme → cause racine → fix

1) « ZFS montre des erreurs ; je les ai effacées et maintenant tout va bien. »

Symptôme : Les erreurs réapparaissent des jours plus tard, parfois en pire.

Cause racine : L’effacement des compteurs a supprimé des preuves sans réparer le matériel/le chemin sous‑jacent.

Fix : Capturer zpool status -xv, les logs et SMART d’abord. Effacez seulement après remédiation, puis validez par scrub/charge.

2) CHECKSUM errors attribuées au disque sans vérifier les CRC

Symptôme : Plusieurs disques montrent des checksum errors, souvent en rafales.

Cause racine : Corruption des données en transit (câble/backplane/HBA) plutôt que défaut média.

Fix : Vérifiez UDMA_CRC_Error_Count, dmesg pour les link resets, et si les erreurs se regroupent par HBA/expander. Remplacez/réparez le composant partagé.

3) Considérer SMART « PASSED » comme « sain »

Symptôme : SMART indique PASSED, mais des read errors continuent et des secteurs pending existent.

Cause racine : Le verdict global SMART est basé sur des seuils et souvent trop tolérant.

Fix : Regardez les attributs spécifiques (pending, uncorrectable, reallocated, CRC). Lancez des self‑tests longs quand possible.

4) Remplacer le mauvais disque

Symptôme : Après remplacement, les erreurs persistent ; parfois le pool se dégrade davantage.

Cause racine : La correspondance device→bay a été devinée, pas vérifiée. Le câblage a changé ; l’énumération a changé.

Fix : Utilisez /dev/disk/by-id, les numéros de série et les outils de mapping d’enclosure. Étiquetez les bays. Exigez une vérification à deux personnes en production.

5) Utiliser RAIDZ1 là où le risque de rebuild est inacceptable

Symptôme : Pendant le resilver, une seconde erreur disque cause perte de données ou blocs irréparables.

Cause racine : Les vdevs à parité simple sont fragiles pendant les rebuilds, surtout avec de grands disques et des erreurs de secteurs latentes.

Fix : Préférez des mirrors (resilver rapide, domaine de panne simple) ou RAIDZ2/3 pour les vdevs de grande capacité. Scrub régulier.

6) Ignorer les resets de contrôleur comme du « bruit »

Symptôme : Stalls I/O intermittents, plusieurs disques faussés brièvement, erreurs en vagues.

Cause racine : Instabilité du firmware/driver HBA, problèmes PCIe, surchauffe ou événements d’alimentation.

Fix : Vérifiez dmesg pour les resets, vérifiez PCIe AER, assurez‑vous du refroidissement, standardisez le firmware, et remplacez/déplacez l’HBA si nécessaire.

7) Surcharger le pool pendant un resilver

Symptôme : Le resilver prend une éternité ; plus d’erreurs apparaissent ; un second disque tombe.

Cause racine : I/O aléatoire lourd + stress de rebuild déclenche des composants marginaux.

Fix : Réduisez la charge si possible, planifiez les rebuilds, et évitez d’exécuter des jobs sensibles à la latence pendant les états dégradés. Envisagez des mirrors pour les tiers chauds.

Checklists / plan étape par étape

Checklist de confinement immédiat (les 30 premières minutes)

1. Exécutez zpool status -xv. Sauvegardez la sortie dans le ticket.
2. Confirmez la marge de redondance (mirror/RAIDZ level) et si un vdev est déjà dégradé.
3. Vérifiez si les compteurs d’erreurs augmentent (exécutez zpool status deux fois à quelques minutes d’intervalle).
4. Capturez les logs OS autour de la fenêtre d’incident : dmesg -T et journalctl -k.
5. Récupérez SMART des disques suspects (au moins ceux avec des erreurs ZFS ; idéalement tous les disques du vdev).
6. Si dégradé : réduisez la charge non essentielle et évitez les actions de maintenance qui ajoutent du stress (comme des mises à jour de firmware) sauf si nécessaire.

Checklist de décision : disque vs chemin

• Remplacez le disque maintenant si les secteurs pending/offline uncorrectable sont non nuls, ou si le SMART long test échoue.
• Réparez le chemin d’abord si les CRC augmentent, si les link resets dominent les logs, et si les indicateurs média SMART sont propres.
• Suspectez le contrôleur/plateforme si plusieurs disques derrière un même HBA montrent des problèmes et que vous voyez des resets de contrôleur ou des événements PCIe AER.
• Faites les deux si le disque montre des problèmes média et que le chemin montre des CRC/resets. Les défaillances mixtes existent.

Plan de remédiation (changer une chose à la fois)

1. Identifiez le composant physique exact (numéro de série du disque, bay, câble, port HBA).
2. Remplacez/réparez le composant le plus probable avec le plus petit rayon d’impact :
   • Reseat/remplacer le câble
   • Déplacer le disque dans un autre bay (si votre enclosure le permet et que vous pouvez garder la cartographie correcte)
   • Remplacer le disque
   • Échanger l’HBA ou déplacer sur un autre slot PCIe
3. Effacez les erreurs ZFS seulement après la remédiation.
4. Lancez un scrub. Surveillez les erreurs pendant le scrub.
5. Documentez la cartographie et ce qui a été remplacé (le vous du futur sera fatigué et reconnaissant).

Checklist de validation (la phase « prouvez‑le »)

1. Le scrub se termine sans erreurs.
2. zpool status ne montre pas de compteurs READ/WRITE/CKSUM qui augmentent pendant la charge maximale.
3. Les compteurs CRC SMART cessent d’augmenter après remédiation câble/backplane.
4. Pas de resets de contrôleur ni d’erreurs PCIe AER dans les logs pendant au moins un cycle business complet.

FAQ

1) Les erreurs de lecture ZFS sont‑elles toujours causées par un disque défaillant ?

Non. Les READ errors signifient que la couche bloc a retourné une erreur. Cela peut être le média, mais aussi des resets de lien, des timeouts du contrôleur, ou l’alimentation.
Utilisez les attributs SMART média et les logs OS pour séparer disque et chemin.

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

READ errors signifient que le périphérique n’a pas renvoyé les données avec succès. CHECKSUM errors signifient que le périphérique a renvoyé des données,
mais qu’elles ne correspondaient pas au checksum de ZFS, ce qui pointe vers de la corruption en transit, du firmware, ou de la mémoire (moins fréquent).

3) Si ZFS dit « errors: No known data errors », puis‑je l’ignorer ?

Non. Ce message signifie que ZFS croit avoir réparé ou évité une corruption visible par l’utilisateur. Il ne signifie pas que le matériel est sain.
Traitez‑le comme un avertissement précoce — le moins coûteux.

4) Dois‑je exécuter zpool clear tout de suite ?

Pas tout de suite. Capturez d’abord les preuves. Effacez après avoir remplacé/réparé quelque chose afin de voir si le problème revient.

5) Combien de UDMA CRC errors est‑ce « trop » ?

Quelques‑unes sur une longue durée peuvent arriver à cause d’événements transitoires. Un compteur CRC qui augmente pendant l’exploitation normale — surtout rapidement — signifie que le chemin est malsain.
La tendance compte plus que la valeur absolue.

6) Des problèmes de RAM ECC peuvent‑ils se manifester en tant que checksum errors ?

Oui, mais c’est moins courant que les problèmes câble/backplane/HBA dans des systèmes bien construits. L’ECC corrige généralement les erreurs simples et les consigne.
Si vous suspectez la mémoire, vérifiez les logs kernel pour événements ECC et envisagez un test mémoire pendant une fenêtre de maintenance.

7) RAIDZ1 est‑il sûr avec de grands disques ?

Cela dépend de votre tolérance au risque, de la charge de travail et de la discipline opérationnelle. En pratique, de grands disques et de longs temps de rebuild rendent RAIDZ1 fragile.
Les mirrors ou RAIDZ2 sont des choix plus sûrs en production où le downtime ou la perte de données est coûteuse.

8) Pourquoi les erreurs apparaissent‑elles souvent pendant un scrub ou un resilver ?

Parce que les scrubs et les resilvers forcent des lectures de surface complètes. Ils accèdent à des données froides qui n’ont pas été lues depuis des mois.
C’est précisément à ce moment que les secteurs latents, les câbles marginaux et les contrôleurs fragiles sont exposés.

9) Si j’échange un câble, comment confirmer que c’était la solution ?

Effacez les erreurs ZFS après l’échange, puis lancez un scrub et observez. Surveillez aussi les compteurs SMART CRC : ils doivent cesser d’augmenter.
Si des link resets continuent dans les logs, le problème n’est pas résolu.

10) Un backplane peut‑il causer des checksum errors sans déconnecter les disques ?

Oui. Un backplane marginal peut corrompre le trafic ou provoquer des retries intermittents sans déconnecter complètement un disque.
Cela apparaît souvent comme des checksum errors, des link resets occasionnels, et des compteurs CRC qui augmentent progressivement.

Étapes suivantes (quoi faire après avoir arrêté l’hémorragie)

Une fois le pool stable et le scrub propre, ne gaspillez pas la douleur. Transformez‑la en posture :

• Standardisez votre cartographie des disques. Étiquettes, usage de by-id et une cartographie des bays documentée réduisent les erreurs humaines plus que n’importe quel outil.
• Basez des métriques SMART et log. CRC counters, pending sectors, resets de contrôleur et PCIe AER devraient être graphiés ou au moins revus périodiquement.
• Planifiez des scrubs. Ajustez pour limiter l’impact, mais ne les sautez pas. Les scrubs sont votre exercice d’intégrité, pas une option.
• Gardez le firmware ennuyeux. Des combos firmware/driver HBA stables battent le « dernier » en production sauf si vous avez un correctif précis à appliquer.
• Concevez pour les rebuilds. Mirrors ou RAIDZ2/3, plus des fenêtres de rebuild réalistes, transforment des pannes disque en maintenance plutôt qu’en incidents.
• Pratiquez les remplacements. Entraînez‑vous à remplacer un disque en laboratoire. Le pire moment pour apprendre les particularités de votre châssis est quand un vdev est dégradé.

Les systèmes de stockage les plus fiables ne sont pas ceux qui ne tombent jamais en panne. Ce sont ceux où la panne ressemble à une routine : preuves claires, isolation rapide,
un composant remplacé, scrub, fini. Voilà la barre. Fixez‑la, et vos futures erreurs de lecture redeviennent une course à faire plutôt qu’une crise.