ZFS ECC vs non-ECC : Mathématiques du risque pour des déploiements réels

décembre 31, 2025 • février 3, 2026 • Lecture : 33 min • Views: 13

Cet article vous a aidé ?

Si vous utilisez ZFS assez longtemps, vous vous poserez tôt ou tard la même question inconfortable : « Ai‑je vraiment besoin de RAM ECC, ou ce n’est que du folklore de gens qui aiment les cartes mères chères ? »
La réponse honnête est ennuyeuse et tranchante : cela dépend de votre budget de risque, de la valeur de vos données et de l’utilisation réelle de votre pool ZFS — pas des impressions, de la doctrine des forums ou d’une capture d’écran effrayante.

ZFS est excellent pour détecter la corruption. Il n’est pas magique pour empêcher la corruption qui survient avant que le checksum soit calculé, ni pour empêcher la corruption qui survient au mauvais endroit au mauvais moment.
Cet article présente les mathématiques, les modes de défaillance et le plan opérationnel — pour que vous puissiez prendre une décision défendable lors d’un post‑mortem.

Ce que change l’ECC (et ce que ça ne change pas)

La mémoire ECC (Error‑Correcting Code) n’est pas « plus rapide » et ce n’est pas un talisman. C’est un contrôle : elle détecte et corrige certaines classes d’erreurs mémoire (typiquement les erreurs d’un seul bit) et détecte (mais peut ne pas corriger) certaines erreurs multi‑bits.
Elle réduit la probabilité qu’une faute mémoire transitoire devienne des données pourries persistantes écrites sur disque.

Le non‑ECC n’est pas une « corruption garantie ». C’est simplement un risque non géré. La plupart des systèmes tourneront longtemps sans problème visible.
Puis, un jour, lors d’un scrub, d’un resilver, d’un fort churn d’ARC, de mises à jour de métadonnées ou d’une période de mémoire serrée, vous obtenez une erreur de checksum inexplicable — ou pire, vous n’en obtenez pas parce que la mauvaise chose a été checksummée.

Voici un cadrage pratique :

L’ECC réduit l’incertitude. Vous aurez toujours besoin de redondance, de scrubs, de sauvegardes, de monitoring et de restaurations testées.
L’ECC est le plus utile là où ZFS est le plus sollicité. Charges metadata‑intensives, dédup, fort churn d’ARC, special vdevs et gros pools qui scrubbent pendant des jours.
L’ECC ne corrige pas une mauvaise planification. Si votre seule copie est sur un pool unique, votre vrai problème est « pas de sauvegarde », pas « pas d’ECC ».

Une idée paraphrasée qui devrait accompagner chaque décision de stockage : l’espoir n’est pas une stratégie. — attribué à Vince Lombardi dans la culture ops, mais traitez‑la comme un proverbe.

Faits et contexte historique (ceux que vous pouvez utiliser)

Les erreurs soft sont connues depuis longtemps. « Les rayons cosmiques inversent des bits » sonne comme de la science‑fiction, mais c’est mesuré dans des flottes de production depuis des décennies.
La densité de la DRAM a rendu les erreurs plus pertinentes. À mesure que les cellules ont rétréci, la marge pour le bruit et la fuite de charge s’est réduite ; les taux d’erreur sont devenus visibles à grande échelle.
L’ECC est devenu standard sur les serveurs parce que la disponibilité coûte cher. Pas parce que les serveurs seraient moralement supérieurs, mais parce que les pannes et interruptions ont un coût financier.
ZFS a popularisé les checksums de bout en bout pour les admins mainstream. Le checksumming des données et métadonnées n’est pas unique à ZFS, mais ZFS l’a rendu opérationnellement accessible.
Les scrubs sont un changement culturel. Les RAID traditionnels detectaient souvent la dégradation seulement lors d’une reconstruction ; ZFS normalise la vérification périodique de tout.
Le copy‑on‑write change le rayon d’impact. ZFS n’écrase pas en place, ce qui réduit certains patterns de corruption mais en introduit d’autres (surtout autour des mises à jour de métadonnées).
La dédup a été une leçon d’humilité. La dédup ZFS peut fonctionner, mais c’est une fonction vorace en mémoire qui transforme de petites erreurs en grosses pannes.
Le « NAS grand public » a mûri. Les labs domestiques et PME ont commencé à exécuter des pools ZFS multi‑disques avec des attentes d’entreprise, souvent sur de la RAM et des cartes mères grand public.

Où les erreurs mémoire affectent ZFS : un modèle de défaillance

1) Le problème du timing du checksum

ZFS protège les blocs avec des checksums stockés séparément. Très bien. Mais il existe une fenêtre temporelle : le checksum est calculé sur des données en mémoire.
Si les données sont corrompues avant que le checksum soit calculé, ZFS calcule fidèlement un checksum des octets corrompus et écrit les deux. Ce n’est pas une « corruption silencieuse » à l’intérieur de ZFS ; c’est « des données fausses valablement checksummées ».

L’ECC aide en réduisant la probabilité que les octets alimentant le checksum soient erronés.
Le non‑ECC signifie que vous misez sur le fait que les erreurs transitoires n’apparaîtront pas dans cette fenêtre assez souvent pour poser problème.

2) Les métadonnées sont là où votre journée bascule

La corruption de données est pénible. La corruption de métadonnées est existentielle. Les métadonnées ZFS incluent les pointeurs de blocs, les spacemaps, les métadonnées d’allocation, les structures du MOS, les dnodes, et plus.
Un bit défectueux dans les métadonnées peut signifier :

un problème d’import du pool irrécupérable
un dataset qui ne monte pas
un objet qui pointe vers le mauvais bloc
un resilver qui se comporte « bizarrement » parce qu’il suit des pointeurs endommagés

ZFS est résilient, mais pas infaillible. Votre redondance (mirror/RAIDZ) aide si la corruption est sur disque et détectable.
Si les mauvaises métadonnées sont écrites, la redondance peut répliquer l’erreur parce qu’il s’agit d’un écrit logiquement consistant.

3) ARC, churn d’éviction et « la RAM comme multiplicateur de défaillance »

L’ARC est le cache en mémoire de ZFS. C’est une fonctionnalité de performance, mais aussi un endroit où un bit inversé peut être amplifié :
les mauvaises données mises en cache peuvent être servies, réécrites ou utilisées pour construire un état dérivé.

Sous pression mémoire, l’ARC évince agressivement. Ce churn augmente le nombre de transactions mémoire et la quantité de données touchées.
Plus de données touchées signifie plus d’opportunités pour qu’une faute ait de l’impact.

4) Special vdevs et accélération des petits blocs de métadonnées

Les special vdevs (souvent des miroirs SSD contenant métadonnées et petits blocs) sont une fusée de performance et une mine anti‑personnelle de fiabilité.
Si vous perdez ce vdev et n’avez pas de redondance, vous pouvez perdre le pool. Si vous corrompez ce qui y est écrit et que la corruption est valablement checksummée, vous pouvez perdre l’intégrité des structures les plus importantes.

5) Scrub, resilver et les phases de « forte lecture »

Les scrubs et les resilvers lisent beaucoup. Ils stressent aussi la chaîne : CPU, mémoire, HBA, câblage, disques.
Ce sont des moments où les problèmes latents se manifestent.
Si vous utilisez du non‑ECC, ces opérations sont votre tirage au sort, car elles poussent d’énormes volumes de données à travers la RAM.

Blague #1 : Si votre calendrier de scrub est « quand je m’en souviens », félicitations — vous avez inventé le bit rot de Schrödinger.

Mathématiques du risque appliquées aux déploiements réels

La plupart des arguments sur l’ECC s’embourbent sur des absolus : « Il faut l’avoir » contre « Je n’ai jamais eu de problème ».
Les décisions en production vivent de probabilités et de coûts. Modélisons donc de façon utilisable.

L’équation centrale : taux × exposition × conséquence

Vous n’avez pas besoin du taux exact de bit‑flip dû aux rayons cosmiques pour faire des calculs utiles. Il vous faut :

Taux d’erreur (R) : à quelle fréquence les erreurs mémoire surviennent (corrigées ou non). Cela varie énormément selon le matériel, l’âge, la température et la qualité des DIMM.
Exposition (E) : combien de données et de métadonnées transitent par la mémoire dans une fenêtre « dangereuse » (écritures, mises à jour de métadonnées, fenêtres de checksumming, pipeline scrub/resilver).
Conséquence (C) : quel est le coût lorsqu’un incident survient (d’un fichier isolé corrompu à « pool impossible à importer »).

Votre risque n’est pas « R ». Votre risque est R × E × C.

Le risque n’est pas réparti uniformément selon les charges

Une archive média majoritairement en lecture après ingestion a un profil d’exposition différent de :

un datastore de VM avec churn constant
une base de données avec latence serrée et écritures synchrones
une cible de sauvegarde qui reçoit de grands flux séquentiels et des purge fréquentes
un environnement intensif en dédup qui transforme les métadonnées en vos données les plus chaudes

Définissez votre « unité de perte »

Cessez de débattre en abstraction. Décidez ce que signifie une perte pour vous :

Unité A : un fichier corrompu restauré proprement depuis une sauvegarde (gênant)
Unité B : une VM avec corruption du système de fichiers (douloureux)
Unité C : échec d’import du pool, restauration sur plusieurs jours et une revue d’incident avec la direction (aux conséquences professionnelles)

L’ECC réduit principalement la probabilité des événements Unité B/C. Ce n’est pas une question pour votre collection de MP3 ; c’est une question de rayon d’impact.

Les sauvegardes modifient la conséquence, pas la probabilité

Des sauvegardes robustes réduisent C. L’ECC réduit R.
Si vous avez les deux, vous obtenez un bénéfice multiplicatif : moins d’incidents, et des incidents moins coûteux.

Pourquoi « ZFS checksums rendent l’ECC superflu » est une idée fausse répandue

Les checksums ZFS vous protègent quand :

le disque renvoie des données incorrectes
le câblage/HBA corrompt des bits en transit depuis le disque
la rotation secteur sur disque survient

Les checksums ZFS ne garantissent pas la protection quand :

des données erronées sont checksummées puis écrites
les pointeurs de métadonnées sont corrompus avant checksum
votre application écrit des données pourries et ZFS les préserve fidèlement

L’ECC est un contrôle amont qui réduit la probabilité que des « mauvaises données deviennent la vérité ».

Alors quelle est la recommandation réelle ?

Si votre pool contient données métier, des données irremplaçables ou des données dont la corruption est difficile à détecter au niveau applicatif, l’ECC est le choix par défaut approprié.
Le non‑ECC peut être défendable pour :

des caches jetables
des réplicas secondaires où l’intégrité du primaire est protégée
des labs domestiques où le temps d’indisponibilité est acceptable et où les sauvegardes sont réelles (testées)
du stockage froid où l’ingestion est contrôlée et vérifiée

Si votre plan est « je remarquerai la corruption », vous supposez que la corruption est bruyante. Souvent, elle ne l’est pas.

Quand le non‑ECC est acceptable (et quand c’est imprudent)

Acceptable : vous pouvez tolérer des données erronées et restaurer rapidement

Le non‑ECC peut convenir lorsque :

vos données sont répliquées ailleurs (et vous vérifiez les réplicas)
vous pouvez effacer et reconstruire le pool depuis la source de vérité
votre hôte ZFS n’effectue pas de travail lourd sur les métadonnées (pas de dédup, pas de special vdev)
vous scrubbiez régulièrement et surveillez les tendances d’erreurs

Imprudent : le pool est la source de vérité

Le non‑ECC est un mauvais pari quand :

vous avez un seul pool contenant la seule copie des données de production
vous utilisez ZFS pour le stockage de VM avec écritures constantes et snapshots
vous avez activé la dédup parce que quelqu’un a dit que ça « économise de l’espace »
vous fonctionnez près des limites mémoire et l’ARC est constamment sous pression
vous utilisez des special vdevs sans redondance, ou des SSD grand public sans protection en cas de perte de puissance

Dans ces scénarios, l’ECC coûte peu par rapport au premier incident où vous devez expliquer pourquoi les données sont « cohérentes mais fausses ».

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une hypothèse erronée

Une entreprise de taille moyenne exploitait un cluster VM reposant sur ZFS pour des services internes. Les hôtes étaient des machines de bureau réaffectées : beaucoup de cœurs, beaucoup de RAM, pas d’ECC.
L’ingénieur stockage avait plaidé pour des cartes mères serveur, mais les achats avaient retenu « ZFS a des checksums » et traduit ça par « l’ECC est optionnel ».

Tout semblait correct jusqu’à une fenêtre de maintenance routinière : mise à jour du noyau, reboot, puis un scrub programmé a démarré automatiquement.
En plein scrub, un hôte a commencé à journaliser des erreurs de checksum. Pas beaucoup. Juste assez pour vous mettre mal à l’aise. Le pool est resté en ligne, le scrub s’est finalement terminé, et l’équipe a classé ça comme « un disque capricieux ».

Au cours des deux semaines suivantes, des problèmes d’application sporadiques sont apparus : la base SQLite d’un service a renvoyé des erreurs « malformed ». Le système de fichiers d’une autre VM a dû être réparé après un arrêt non propre.
L’équipe a chassé des faux‑sens : latence stockage, coupures réseau, SSD suspect.

Le point de bascule a été la comparaison des sauvegardes : restaurer la même image VM depuis deux snapshots différents produisait deux checksums différents pour quelques blocs.
Ce n’est pas de la « pourriture disque », c’est « quelque chose a écrit des vérités inconsistantes à différents moments ».

Après une analyse douloureuse, ils ont trouvé un pattern : les erreurs de checksum apparaissaient lors d’activités mémoire élevées. Les logs hôtes montraient des symptômes semblables à des MCE sur une machine, mais rien de définitif parce que la plateforme ne remontait pas bien la télémétrie mémoire.
Le remplacement des DIMM a réduit les erreurs, mais n’a pas restauré la confiance. Ils ont remplacé la plateforme par des systèmes compatibles ECC et ajouté des tests de restauration mensuels.

L’hypothèse erronée n’était pas « le non‑ECC corrompt toujours les données ». L’hypothèse erronée était « les checksums rendent l’exactitude en amont sans importance ».
Les checksums détectent les mensonges. Ils ne vous empêchent pas de les écrire.

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

Une autre équipe utilisait ZFS pour un dépôt de sauvegarde. La pression d’espace était réelle, alors quelqu’un a proposé déduplication plus compression. Sur le papier, c’était brillant : les sauvegardes sont répétitives, la dédup devrait être efficace, et ZFS l’a intégré.
Ils ont activé la dédup sur un grand dataset et ont vu les gains augmenter. Tout le monde se sentait malin.

Puis sont arrivées les plaintes de performance. Les fenêtres d’ingestion ont glissé. La machine a commencé à swapper sous charge.
L’équipe a réagi en ajustant l’ARC et en ajoutant un SSD rapide pour L2ARC, essayant de « mettre en cache » le problème. Ils ont aussi augmenté le recordsize pour améliorer le débit.

Ce qu’ils n’avaient pas compris : la dédup pousse une énorme quantité de métadonnées en mémoire. La DDT (dedup table) est vorace. Sous pression mémoire, tout devient plus lent, et le système devient plus vulnérable aux cas limites.
Ils tournaient en non‑ECC parce que « ce ne sont que des sauvegardes », et parce que la plateforme était à l’origine une appliance optimisée pour le coût.

La panne n’a pas été immédiate, ce qui rend l’enseignement d’autant plus précieux. Après quelques mois, un scrub a trouvé des erreurs de checksum dans des blocs de métadonnées.
Les restaurations ont commencé à échouer pour un sous‑ensemble de jeux de sauvegarde — la pire des situations, car les sauvegardes existaient, mais n’étaient pas fiables.

Le rollback a pris des semaines : désactiver la dédup pour les nouvelles données, migrer les sauvegardes critiques vers un nouveau pool, et exécuter une vérification complète des restaurations sur les ensembles les plus importants.
L’optimisation n’était pas malveillante ; elle était mal adaptée au matériel et à la maturité opérationnelle.

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

Un groupe financier exploitait ZFS sur une paire de serveurs de stockage avec RAM ECC, des special vdevs miroir, et un calendrier que personne ne remettait en question : scrub hebdomadaire, tests SMART étendus mensuels, exercices de restauration trimestriels.
L’ensemble était presque offensivement peu glamour. Pas de dédup. Pas de tunables exotiques. Juste des miroirs et de la discipline.

Un trimestre, lors d’un exercice de restauration, ils ont remarqué qu’une restauration était plus lente que prévu et que l’hôte récepteur avait journalisé une poignée d’erreurs mémoire corrigées.
Rien ne s’est crashé. Aucune donnée n’a été perdue. Mais la télémétrie existait, et l’exercice a forcé l’équipe à l’examiner alors que personne n’était en crise.

Ils ont remplacé le DIMM de manière proactive, puis exécuté un autre exercice de restauration et un scrub. Propre.
Deux semaines plus tard, le DIMM jumelé remplacé (même lot) a commencé à rapporter des erreurs corrigées sur un autre serveur. Ils l’ont aussi remplacé.

La partie amusante est ce qui ne s’est pas produit : aucun incident client, aucune corruption de pool, aucun « depuis combien de temps ça dure ? » en réunion.
L’ECC n’a pas « sauvé la journée » tout seul. La pratique ennuyeuse l’a fait : surveiller les erreurs corrigées, les traiter comme un signal de dégradation matérielle et valider les restaurations tant que c’était un événement calendaire plutôt qu’une crise.

Guide de diagnostic rapide : trouver rapidement le goulot

Quand ZFS commence à mal se comporter — erreurs de checksum, scrubs lents, blocages aléatoires — vous pouvez perdre des jours à débattre de l’ECC comme si c’était de la théologie.
Ce playbook est pour le moment où vous avez besoin de réponses rapides.

Premier point : confirmez quel type de défaillance vous avez

Défaillance d’intégrité : erreurs de checksum, fichiers corrompus, erreurs de pool en augmentation.
Défaillance disponibilité/performance : blocages I/O, scrub qui prend une éternité, latences élevées, timeouts.
Pression sur les ressources : swapping, OOM kills, thrash ARC, saturation CPU.

Deuxième point : isolez « chemin disque » vs « chemin mémoire/CPU »

Si zpool status montre des erreurs de checksum sur un périphérique spécifique, suspectez d’abord le disque/câble/port HBA ou le backplane.
Si des erreurs apparaissent sur plusieurs périphériques simultanément, suspectez HBA, backplane, RAM ou CPU.
Si le pool est propre mais que les applis voient de la corruption, suspectez des bugs applicatifs, la RAM ou la couche réseau au‑dessus du stockage.

Troisième point : décidez si vous pouvez garder le système en ligne

Les erreurs mémoire corrigées sont un avertissement. Vous pouvez généralement rester en ligne, mais planifiez une fenêtre de maintenance.
Erreurs non corrigibles ou augmentation des checksum : stoppez les écritures, snapshottez ce que vous pouvez et planifiez un basculement/restauration contrôlé.
Resilver/scrub sur du matériel instable : risqué. Réparez la plateforme d’abord si possible.

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

Ce sont des tâches réelles que vous pouvez exécuter sur Linux avec OpenZFS. Chacune indique ce qu’il faut rechercher et la décision à prendre.
(Si vous êtes sur FreeBSD, les commandes diffèrent, mais la logique opérationnelle reste la même.)

Task 1: Check pool health and error counters

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  scan: scrub repaired 0B in 05:12:44 with 3 errors on Sun Dec  8 03:20:55 2025
config:

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

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

        /tank/vmstore/vm-112-disk-0.qcow2

Ce que cela signifie : des erreurs de CKSUM sur un seul disque indiquent souvent un problème de disque, de câble, de port HBA ou de backplane. « Permanent errors » signifie que ZFS n’a pas pu reconstruire certains blocs.

Décision : Si la redondance ne peut pas réparer, restaurez le fichier impacté depuis une sauvegarde/snapshot. Ensuite, investiguez le chemin du périphérique (SMART, câblage). Ne faites pas de « clear and forget ».

Task 2: Show detailed pool properties that affect integrity and recovery

cr0x@server:~$ zpool get ashift,autotrim,autoexpand,autoreplace,listsnapshots tank
NAME  PROPERTY       VALUE   SOURCE
tank  ashift         12      local
tank  autotrim       off     default
tank  autoexpand     off     default
tank  autoreplace    off     default
tank  listsnapshots  off     default

Ce que cela signifie : ashift affecte l’amplification d’écriture et la performance. Ça ne résoudra pas les problèmes ECC, mais un mauvais ashift peut rendre les scrubs/resilvers extrêmement longs.

Décision : Si ashift est inadapté à vos disques, planifiez une migration (pas un changement rapide). Si les scrubs prennent des jours, votre fenêtre d’exposition augmente — une autre raison pour laquelle l’ECC devient plus précieuse.

Task 3: Confirm scrub schedule and last scrub outcome

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 3 errors on Sun Dec  8 03:20:55 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0

Ce que cela signifie : Vous avez un scrub récent et il a trouvé des erreurs. Le scrub est votre système d’alerte précoce ; traitez‑le comme tel.

Décision : Si les scrubs trouvent régulièrement de nouvelles erreurs de checksum, cessez de supposer que c’est « aléatoire ». Suivez la tendance et escaladez vers une expertise matérielle.

Task 4: Check ZFS error logs and kernel messages around I/O

cr0x@server:~$ dmesg -T | egrep -i 'zfs|checksum|ata|sas|mce|edac' | tail -n 20
[Sun Dec  8 03:21:12 2025] ZFS: vdev I/O error, zpool=tank, vdev=/dev/sdb1, error=52
[Sun Dec  8 03:21:12 2025] ata3.00: status: { DRDY ERR }
[Sun Dec  8 03:21:12 2025] ata3.00: error: { UNC }
[Sun Dec  8 03:21:13 2025] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: b200000000070005

Ce que cela signifie : Des erreurs I/O de stockage mélangées à des entrées MCE sont un signal d’alarme. Ne supposez pas que le disque est coupable si le CPU rapporte des machine checks.

Décision : Si MCE/EDAC suggère des problèmes mémoire, priorisez la stabilité RAM/plateforme avant de relancer un scrub/resilver qui pourrait écrire une nouvelle « vérité ».

Task 5: Verify ECC is actually enabled and recognized

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'error correction|ecc|type:|manufacturer' | head -n 20
        Error Correction Type: Multi-bit ECC
        Type: DDR4
        Manufacturer: Micron Technology
        Error Correction Type: Multi-bit ECC
        Type: DDR4
        Manufacturer: Micron Technology

Ce que cela signifie : La plateforme rapporte la capacité ECC. Cela ne garantit pas que Linux reçoive les événements EDAC, mais c’est une condition nécessaire.

Décision : Si cela rapporte « None » ou « Unknown », ne vous dites pas que vous avez l’ECC « parce que les DIMM sont ECC ». Il vous faut aussi une carte mère/CPU qui l’utilise.

Task 6: Check EDAC counters for corrected/uncorrected memory errors

cr0x@server:~$ sudo edac-util -v
edac-util: EDAC drivers are loaded. 1 MC detected:
  mc0: 2 Uncorrected Errors with no DIMM info
  mc0: 41 Corrected Errors with no DIMM info

Ce que cela signifie : Les erreurs corrigées signifient que l’ECC fait son travail. Les erreurs non corrigées signifient que le système a subi des fautes mémoire que l’ECC n’a pas pu réparer.

Décision : Toute erreur non corrigée : planifiez une maintenance immédiate et remplacez les DIMM/slots/carte mère suspects. Des erreurs corrigées en tendance : considérez‑les comme un signal de pré‑défaillance et planifiez un remplacement.

Task 7: Inspect per-DIMM error detail (when available)

cr0x@server:~$ sudo ras-mc-ctl --summary
Summary of memory errors:
Location: mc0/csrow0/channel0/dimm0
  Corrected: 37
  Uncorrected: 0
Location: mc0/csrow0/channel1/dimm0
  Corrected: 4
  Uncorrected: 0

Ce que cela signifie : Les erreurs sont localisées sur un DIMM/canal, ce qui est exactement ce que vous voulez pour un remplacement actionnable.

Décision : Remplacez le DIMM avec le plus grand nombre d’erreurs corrigées en premier, puis revérifiez. Si les erreurs persistent sur le même canal, suspectez le slot ou le contrôleur mémoire.

Task 8: Confirm ZFS is not doing dedup accidentally

cr0x@server:~$ zfs get -r dedup tank
NAME                PROPERTY  VALUE  SOURCE
tank                dedup     off    default
tank/vmstore        dedup     off    default
tank/backups        dedup     off    default

Ce que cela signifie : La dédup est désactivée, bien. Si elle est activée quelque part, la pression mémoire et la sensibilité des métadonnées augmentent fortement.

Décision : Si vous trouvez la dédup activée sans justification solide et plan de dimensionnement, désactivez‑la pour les nouvelles écritures (set dedup=off) et planifiez la migration des anciennes données si nécessaire.

Task 9: Check ARC size and memory pressure signals

cr0x@server:~$ arc_summary | egrep -i 'arc size|target size|memory|evict' | head -n 12
ARC size (current):                                   27.4 GiB
Target size (adaptive):                               30.1 GiB
Min size (hard limit):                                8.0 GiB
Max size (high water):                                32.0 GiB
Evict skips:                                          0
Demand data hits:                                     89.3%

Ce que cela signifie : L’ARC est important et stable. Si vous voyez des évictions constantes, de faibles taux de hit, ou que la machine swappe, vous êtes en état de fort churn où les fautes ont plus d’impact.

Décision : Si l’ARC thrash ou le swap est présent, réduisez la charge, ajoutez de la RAM, ou limitez l’ARC. Ne lancez pas de resilvers sur un hôte qui swap de façon étrange.

Task 10: Check for swapping and reclaim pressure

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        58Gi       1.2Gi       1.0Gi       4.8Gi       2.6Gi
Swap:           16Gi        12Gi       4.0Gi

Ce que cela signifie : L’utilisation active du swap sur un hôte de stockage est un signe de mauvaise performance et, indirectement, un amplificateur de risque d’intégrité (plus de churn, plus de stress lors d’opérations critiques).

Décision : Trouvez ce qui consomme la mémoire (VMs, dédup, workloads metadata‑intensifs). Ajoutez de la RAM ou réduisez l’empreinte. Si vous ne pouvez pas ajouter l’ECC, évitez au moins de fonctionner à haute charge et de swapper.

Task 11: Verify SMART health and UDMA CRC errors (cabling tells)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'reallocated|pending|offline_uncorrectable|udma_crc_error_count' 
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12

Ce que cela signifie : Les erreurs UDMA CRC impliquent généralement des câbles/backplanes plutôt que le média. Les erreurs de checksum ZFS qui corrèlent avec des incréments CRC sont souvent des « données qui ont été malmenées en transit ».

Décision : Remplacez les câbles, reseatez les connexions, vérifiez le port backplane/HBA. Ensuite, relancez un scrub pour confirmer la stabilité.

Task 12: Identify whether checksum errors are new or historical

cr0x@server:~$ zpool status -v tank | tail -n 15
errors: Permanent errors have been detected in the following files:

        /tank/vmstore/vm-112-disk-0.qcow2

Ce que cela signifie : Les « Permanent errors » persistent jusqu’à ce que vous restauriez/écrasiez les blocs affectés. Effacer les erreurs ne répare pas les données.

Décision : Restaurez le fichier à partir d’un snapshot/sauvegarde fiable ou supprimez‑le et régénérez‑le. Ensuite, exécutez zpool clear seulement après remédiation.

Task 13: Map a block-level problem to snapshots and attempt self-heal

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation tank/vmstore | head
NAME                                CREATION
tank/vmstore@hourly-2025-12-08-0300  Sun Dec  8 03:00 2025
tank/vmstore@hourly-2025-12-08-0200  Sun Dec  8 02:00 2025
tank/vmstore@daily-2025-12-07        Sat Dec  7 23:55 2025

Ce que cela signifie : Vous avez des snapshots pour revenir en arrière ou cloner, ce qui est votre chemin le plus rapide vers la correction.

Décision : Si un fichier est marqué comme corrompu de façon permanente, restaurez‑le depuis le snapshot connu bon le plus récent et validez au niveau applicatif.

Task 14: Force a targeted read to surface latent errors

cr0x@server:~$ sudo dd if=/tank/vmstore/vm-112-disk-0.qcow2 of=/dev/null bs=16M status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 7 s, 307 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 14 s, 305 MB/s
...output...

Ce que cela signifie : Une lecture séquentielle complète peut déclencher la vérification des checksums et montrer si les erreurs réapparaissent. Ce n’est pas un substitut au scrub, mais c’est un outil de triage rapide pour un objet spécifique.

Décision : Si les lectures déclenchent de nouveaux erreurs de checksum, considérez le chemin sous‑jacent comme instable ; n’attendez pas le scrub hebdomadaire pour vous dire ce que vous savez déjà.

Task 15: Check scrub/resilver throughput and identify if you’re CPU-bound or I/O-bound

cr0x@server:~$ iostat -x 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    6.22   21.10    0.00   60.37

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sdb              84.0  10432.0     0.0    0.0   28.4   124.2        3.0     64.0    2.1    2.40   98.0
sdc              82.0  10240.0     0.0    0.0   29.1   124.9        2.0     48.0    1.9    2.35   97.5

Ce que cela signifie : Un %iowait élevé et une utilisation disque proche de 100 % suggèrent que le scrub est limité par les disques. Si le CPU était saturé et les disques inoccupés, vous seriez limité par le CPU/checksum.

Décision : Limité par les disques : vérifiez la topologie vdev, ashift, la santé des disques et le câblage. Limité par le CPU : envisagez un CPU plus rapide, activez les offloads de checksum si disponible, ou réduisez le recordsize/le churn des métadonnées.

Task 16: Confirm special vdev redundancy (if you use one)

cr0x@server:~$ zpool status tank | sed -n '1,80p'
  pool: tank
 state: ONLINE
config:

        NAME                       STATE     READ WRITE CKSUM
        tank                       ONLINE       0     0     0
          raidz2-0                 ONLINE       0     0     0
            sda1                   ONLINE       0     0     0
            sdb1                   ONLINE       0     0     0
            sdc1                   ONLINE       0     0     0
            sdd1                   ONLINE       0     0     0
          special                  ONLINE       0     0     0
            mirror-1               ONLINE       0     0     0
              nvme0n1p1            ONLINE       0     0     0
              nvme1n1p1            ONLINE       0     0     0

Ce que cela signifie : Le special vdev est en miroir. C’est la ligne de sécurité minimale si vous y placez des métadonnées.

Décision : Si le special est un seul périphérique, corrigez cela avant d’optimiser autre chose. Un special vdev unique est un point de défaillance unique du pool.

Blague #2 : Exécuter ZFS avec la dédup activée sur du non‑ECC, c’est comme jongler avec des tronçonneuses parce que ça « économise des étapes ».

Erreurs courantes : symptôme → cause racine → correction

1) « Erreurs de checksum “aléatoires” sur plusieurs disques »

Symptôme : l’incrément de CKSUM sur plus d’un disque, parfois différents disques certains jours.
Cause racine : problème de chemin partagé (HBA, backplane, alimentation, câblage) ou instabilité mémoire/CPU provoquant l’écriture/validation de mauvaises données.
Correction : Vérifiez les CRC SMART, changez câbles/ports, mettez à jour le firmware HBA, consultez les logs MCE/EDAC, exécutez memtest en maintenance et stoppez les écritures jusqu’à stabilisation.

2) « ZFS dit réparé, mais l’application est toujours cassée »

Symptôme : le scrub indique des réparations, mais la base de données/le format de fichier se plaint toujours.
Cause racine : ZFS a réparé des blocs corrompus via la redondance, mais l’état applicatif avait déjà intégré de mauvais écrits (surtout si la corruption est survenue avant checksum).
Correction : Restaurez depuis des sauvegardes/snapshots applicativement cohérents. Ajoutez des checksums côté application quand c’est possible (les bases de données en possèdent souvent).

3) Les scrubs sont propres, mais vous ne faites toujours pas confiance au pool

Symptôme : pas d’erreurs ZFS, mais vous avez eu des crashs inexplicables, des panics noyau ou des rapports de corruption de fichiers.
Cause racine : instabilité mémoire qui affecte le calcul et le comportement applicatif plus que les lectures disque, ou corruption survenant avant que les données n’atteignent ZFS.
Correction : Vérifiez EDAC/MCE, exécutez des tests mémoire, validez l’alimentation et la thermique, validez avec des checksums applicatifs de bout en bout, et envisagez l’ECC si le pool est la source de vérité.

4) « Nous avons effacé les erreurs et tout va bien »

Symptôme : quelqu’un a exécuté zpool clear et a déclaré victoire.
Cause racine : confusion entre compteurs et corruption. L’effacement réinitialise le reporting, pas la réalité.
Correction : Identifiez et remédiez aux fichiers endommagés (restauration/écrasement). N’effacez qu’après avoir réparé les données et stabilisé le matériel.

5) Le pool ne s’importe pas après un événement de coupure

Symptôme : l’import échoue ou se bloque après une coupure d’alimentation abrupte.
Cause racine : problèmes matériel/firmware, mauvaise mémoire ou chemin de stockage instable exposé par la lourde relecture et les opérations metadata au démarrage.
Correction : Validez la RAM (logs ECC ou memtest), vérifiez le firmware HBA, assurez‑vous d’un traitement correct des pertes de puissance (UPS), et documentez/testez les environnements de démarrage et de récupération.

6) « Nous avons ajouté de la RAM et maintenant nous avons des erreurs »

Symptôme : des erreurs apparaissent après une mise à niveau mémoire.
Cause racine : types/timings DIMM mélangés, DIMM marginal, mauvais réglages BIOS ou carte incapable de piloter la configuration de façon fiable.
Correction : Utilisez des configurations mémoire validées, mettez à jour le BIOS, réduisez la vitesse aux réglages stables et surveillez les compteurs EDAC. Remplacez tôt les DIMM suspects.

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

Checklist de décision : ce système ZFS doit‑il utiliser l’ECC ?

Ce pool est‑il une source de vérité ? Si oui, préférez l’ECC par défaut.
La corruption est‑elle difficile à détecter ? Images de VM, bases de données, photos, données scientifiques : oui. Préférez l’ECC.
Utilisez‑vous dédup, special vdevs ou snapshots intensifs ? Si oui, l’ECC est fortement recommandé.
Pouvez‑vous restaurer rapidement et l’avez‑vous testé ? Si non, l’ECC ne vous sauvera pas, mais le non‑ECC vous nuira davantage.
Avez‑vous de la télémétrie pour les erreurs mémoire ? Si non, vous volez à l’aveugle — préférez des plateformes ECC avec visibilité EDAC.

Checklist opérationnelle : si vous devez absolument tourner sans ECC

Gardez‑le simple : mirrors/RAIDZ, pas de dédup, évitez les special vdevs mono‑périphérique.
Exécutez des scrubs réguliers et alertez immédiatement sur toute nouvelle erreur de checksum.
Conservez une marge mémoire : évitez le swap ; limitez l’ARC si nécessaire.
Utilisez des checksums applicatifs quand c’est possible (vérifications bases de données, hachages pour archives).
Ayez des sauvegardes vérifiées : tests de restauration périodiques, pas « on a des sauvegardes quelque part ».
Maintenez un plan de pièces de rechange : câbles connus bons, HBA de rechange, disque de rechange, et procédure de remplacement documentée.

Étape par étape : répondre aux premières erreurs de checksum

Gelez les hypothèses : ne déclarez pas « disque défaillant » tout de suite.
Capturez la sortie de zpool status -v et les logs système autour de l’événement.
Vérifiez SMART, en particulier les compteurs CRC et les secteurs en attente.
Vérifiez les compteurs MCE/EDAC. Si des erreurs corrigées existent, considérez le matériel en dégradation.
Identifiez les fichiers affectés ; restaurez depuis snapshot/sauvegarde si possible.
Corrigez la couche physique (câble/port/HBA) avant de relancer un scrub.
Exécutez un scrub et vérifiez que la tendance des erreurs est plate.
Si les erreurs réapparaissent sur plusieurs périphériques, planifiez une maintenance pour isoler RAM/HBA/backplane.

FAQ

1) ZFS nécessite‑t‑il de la RAM ECC ?

ZFS ne nécessite pas d’ECC pour fonctionner. L’ECC est un contrôle de fiabilité. Si le pool contient des données importantes, l’ECC est le choix par défaut approprié.

2) Si ZFS a des checksums, comment la corruption mémoire peut‑elle encore avoir de l’importance ?

Les checksums détectent la corruption après que le checksum a été calculé. Si des données corrompues sont checksummées et écrites, ZFS les validera ensuite comme « correctes », parce qu’elles correspondent à leur checksum.

3) Le non‑ECC est‑il acceptable pour un NAS domestique ?

Parfois. Si vous avez de vraies sauvegardes et que vous pouvez tolérer des restaurations occasionnelles, le non‑ECC peut être un compromis acceptable.
Si vous stockez des photos irremplaçables et que votre « sauvegarde » est un autre disque dans la même machine, vous jouez, vous n’ingéniez pas.

4) Qu’est‑ce qui est pire : pas de scrub ou pas d’ECC ?

L’absence de calendrier de scrub est généralement pire à court terme car vous découvrirez les problèmes disques latents seulement lors d’une reconstruction — quand vous pouvez le moins vous permettre des surprises.
L’absence d’ECC augmente la probabilité que certaines surprises soient plus étranges et plus difficiles à attribuer.

5) Les mirrors/RAIDZ rendent‑ils l’ECC moins important ?

La redondance aide lorsque la corruption est sur disque et detectable. L’ECC aide à prévenir les mauvais écrits et protège les opérations en mémoire.
Ils traitent des modes de défaillance différents ; ils sont complémentaires, pas substitutifs.

6) Puis‑je « valider » mon système non‑ECC en exécutant memtest une fois ?

Memtest est utile, mais c’est un test ponctuel. Certaines défaillances dépendent de la température ou de la charge et n’apparaissent qu’après des mois.
Si vous prenez l’intégrité au sérieux, préférez l’ECC plus la surveillance pour voir les erreurs corrigées avant qu’elles ne deviennent des incidents.

7) Quelles fonctionnalités ZFS rendent l’ECC plus importante ?

La dédup, les special vdevs, le snapshotting/clonage intensif, les charges metadata‑intensives et les systèmes tournant près des limites mémoire.
Elles augmentent la quantité d’état critique touché en mémoire et le coût d’une erreur.

8) Si je vois des erreurs ECC corrigées, dois‑je paniquer ?

Non. Les erreurs corrigées signifient que l’ECC a fait son travail. Mais ne les ignorez pas. Une tendance à la hausse est un signal de maintenance : remplacez le DIMM, vérifiez le refroidissement et validez les réglages BIOS.

9) L’ECC suffit‑il à garantir l’intégrité ?

Non. Vous avez toujours besoin de redondance, de scrubs, de sauvegardes et de validations. L’ECC réduit une classe de risque amont ; elle ne rend pas votre système invincible ni vos sauvegardes optionnelles.

10) Quelle est la mise à niveau de fiabilité la moins chère si je ne peux pas obtenir d’ECC ?

La discipline opérationnelle : scrubs, surveillance SMART, tests de restauration et empêcher le système de swapper. Simplifiez aussi le pool (mirrors) et évitez les fonctionnalités risquées (dédup, special vdev mono‑périphérique).

Prochaines étapes actionnables cette semaine

Décidez votre unité de perte. Si la perte du pool a des conséquences professionnelles, achetez du matériel compatible ECC ou déplacez la charge.
Activez et surveillez les signaux pertinents. Suivez la santé via zpool status, les résultats de scrub, les CRC/pending sectors SMART et les compteurs EDAC/MCE.
Planifiez des scrubs et testez les restaurations. Les scrubs détectent les problèmes ; les tests de restauration prouvent que vous pouvez y survivre.
Auditez vos fonctionnalités ZFS. Si la dédup est activée « pour économiser de l’espace », désactivez‑la pour les nouvelles écritures et repensez la conception avant de la réintroduire.
Si vous restez en non‑ECC, réduisez l’exposition. Gardez de la marge mémoire, évitez le swap et conservez une topologie de pool conservatrice.

La position mûre n’est ni « toujours ECC » ni « jamais ECC ». C’est : connaissez vos modes de défaillance, évaluez vos conséquences et choisissez le matériel qui correspond au sérieux de vos engagements.
ZFS vous dira quand il détecte des mensonges. L’ECC aide à faire en sorte que vous ne les écriviez pas en premier lieu.