RAM ECC : quand ça compte — et quand c’est juste du prestige

Ce que la RAM ECC fait vraiment (et ce qu’elle ne fait pas)

ECC signifie Error-Correcting Code. En termes pratiques : la mémoire ECC peut détecter et corriger certains types d’erreurs de bit qui surviennent pendant que les données sont en RAM ou transitent dans le sous-système mémoire. C’est tout. Pas de magie, pas de supériorité morale. Juste des mathématiques et un peu de silicium supplémentaire.

Ce que l’ECC corrige

La plupart des implémentations ECC courantes sur serveurs supportent SECDED : Single-Error Correction, Double-Error Detection. Si un bit se retourne dans un mot mémoire, l’ECC peut le corriger à la volée. Si deux bits se retournent, l’ECC peut détecter qu’il y a eu un problème et enregistre généralement une erreur non corrigeable, provoquant souvent le plantage du système (ou au moins l’empoisonnement de la page) parce que l’alternative serait de continuer avec des données corrompues.

Ce que l’ECC ne corrige pas

• Écritures disque incorrectes causées par des bugs logiciels. L’ECC ne réparera pas votre logique applicative.
• Corruption après le CPU. Si votre contrôleur de stockage altère les données, l’ECC ne le voit pas.
• Fichiers déjà corrompus sur disque. C’est le rôle des sommes de contrôle bout en bout et des scrubs.
• Toutes les erreurs multi-bits. Certains modes de défaillance ressemblent à des motifs, pas à des inversions uniques. La détection ECC aide, mais ce n’est pas un champ de force.
• Mauvaise configuration. « DIMM ECC installés » n’est pas la même chose que « ECC activé et rapporté ».

L’ECC est une fonctionnalité de fiabilité, pas de performance. Parfois elle ajoute une infime latence. Parfois elle est pratiquement gratuite. Dans les deux cas, ce n’est pas là que vous gagnerez vos benchmarks.

Blague n°1 : L’ECC, c’est comme la ceinture de sécurité : la plupart du temps elle est là en silence, et puis un jour c’est l’achat le plus rentable que vous ayez fait.

La valeur opérationnelle : du signal, pas seulement de la correction

La partie sous-estimée de l’ECC, c’est la télémétrie. Les erreurs corrigées sont un fumet précoce. Elles peuvent indiquer :

• Qu’un DIMM se dégrade.
• Qu’un canal mémoire est malheureux.
• Que vous avez un overclock marginal, une sous-tension, ou un problème thermique (oui, même sur des « serveurs »).
• Que les rayons cosmiques font leur travail cosmique (rare, mais réel).

En d’autres termes, l’ECC n’est pas seulement un filet de sécurité. C’est un capteur. Les capteurs empêchent les incidents en vous permettant d’agir avant que la défaillance ne devienne dramatique.

Le vrai ennemi : la corruption silencieuse

Toutes les défaillances ne se manifestent pas bruyamment. En fait, les pires sont celles qui ressemblent à un succès. Une erreur mémoire qui inverse un bit dans une page de base de données, une structure de métadonnées de système de fichiers, un tampon de décompression ou une routine crypto peut produire une sortie plausible — et fausse.

Pourquoi c’est particulièrement méchant dans les architectures modernes :

• La mémoire est un carrefour. Les données passent par la RAM en route vers le disque, le réseau et d’autres processus.
• Nous compressons, chiffrons, dédupliquons et mettons en cache agressivement. Un bit inversé peut empoisonner toute une chaîne de transformations.
• Nous faisons confiance aux caches. Page cache, ARC, pools de buffers — on attend d’eux qu’ils soient dignes de confiance. S’ils mentent, votre système ment.
• Nous augmentons délibérément le rayon d’impact. Un objet corrompu mis en cache dans un niveau peut être servi à des milliers de clients rapidement. Bravo pour votre efficacité.

L’ECC ne rend pas la corruption impossible. Elle rend une classe courante et subtile de corruption moins susceptible d’être silencieuse.

Il y a une raison pour laquelle les personnes en fiabilité obsessionnent sur tout ce qui est « silencieux ». Une panne bruyante déclenche des alarmes. Une panne silencieuse est promue en production, sauvegardée, répliquée et archivée avec amour.

Une idée paraphrasée de Richard Feynman : la personne la plus facile à tromper, c’est vous-même. En exploitation, cela inclut se tromper en pensant que « pas d’alertes » signifie « pas de corruption ».

Quand l’ECC est obligatoire

Si vous exploitez l’un des éléments suivants, l’ECC n’est pas un luxe. C’est le minimum. Vous pouvez choisir de l’ignorer, mais alors vous acceptez un mode de défaillance difficile à détecter et coûteux à annuler.

1) Systèmes de stockage qui revendiquent l’intégrité (ZFS, btrfs, Ceph, « appliances de sauvegarde »)

Si votre pile de stockage met en avant des « somme de contrôle » et de l’« auto-réparation », votre RAM fait partie de ce pipeline. Les sommes de contrôle aident à détecter la corruption sur disque. Mais si les données en RAM sont corrompues avant d’être sommées, le système peut joyeusement sommer les mauvaises données et les persister pour toujours.

C’est la partie que les gens oublient : l’intégrité bout en bout n’est pas bout en bout si vous ignorez « l’extrémité » où les données sont générées et mises en attente. La RAM est dans cette extrémité.

Avez-vous besoin d’ECC pour un NAS domestique ? Pas automatiquement. Avez-vous besoin d’ECC pour un NAS qui contient la seule copie des finances de votre entreprise ? Oui, sauf si vous aimez le théâtre de conformité.

2) Bases de données et files de messages (Postgres, MySQL, MongoDB, Kafka)

La corruption de base de données n’est pas « un bug qu’on redémarre ». Un bit inversé en mémoire peut :

• Corrompre une page en mémoire qui sera ensuite vidée sur disque.
• Corrompre une structure d’index, entraînant des résultats de requête erronés (le type le plus effrayant).
• Provoquer une divergence de réplication qui ressemble à une « bizarrerie réseau ».

Avec les WAL/logs de redo, vous pouvez peut-être récupérer. Ou vous pouvez rejouer fidèlement un état corrompu. L’ECC n’est pas une solution miracle, mais sans elle vous laissez l’entropie participer à vos transactions.

3) Virtualisation et hôtes multi-tenant denses

Dans un hyperviseur, une erreur mémoire peut affecter :

• Une VM (meilleur cas).
• Le noyau hôte et toutes les VM (mauvais cas courant).
• Une frontière de sécurité, si une corruption mémoire déclenche un comportement indéfini (rare, mais aux conséquences coriaces).

Si une machine physique exécute les charges de dizaines d’équipes, dépensez pour l’ECC. Votre coût par VM pour l’ECC est minime ; votre coût d’incident par hôte ne l’est pas.

4) Tout ce qui donne des erreurs « nous ne pouvons pas les reproduire »

Segfaults aléatoires, mismatches de checksum occasionnels, erreurs de décompression sporadiques, compilateurs qui échouent bizarrement, ou conteneurs qui plantent sans motif. Si vous chassez des fantômes, la mémoire non-ECC rallonge et renchérit la chasse aux fantômes.

5) Systèmes longue durée avec objectifs de disponibilité

Plus la durée d’exécution est longue, plus il y a d’occasions d’événements rares. L’ECC est un jeu de probabilités. Si vous exploitez des flottes à grande échelle, « rare » devient « mardi ».

6) Stations de travail réalisant un travail qui doit être correct

CAO, EDA, calcul scientifique, pipelines vidéo destinés à la diffusion, machines de build produisant des releases, infrastructure de signature, modélisation financière — tout ce dont la sortie erronée est pire que la lenteur. L’ECC a sa place ici.

Il ne s’agit pas d’être chic. Il s’agit de ne pas expédier un artefact subtilement corrompu puis de passer un mois à prouver que ce n’était pas votre code.

Quand l’ECC est un luxe (et que vous pouvez dépenser ailleurs)

L’ECC n’est pas une religion. C’est un contrôle de risque. Si le risque est faible, ou si le coût d’atténuation est supérieur aux alternatives, vous pouvez le sauter — consciemment.

1) Calcul jetable avec vraie redondance

Si votre calcul est sans état, peut être recréé en minutes, et que vous avez de fortes vérifications de correction aux frontières, la mémoire non-ECC peut être acceptable. Pensez à :

• Frontends web horizontaux où la correction est validée en aval.
• Workers batch dont les sorties sont validées ou recalculées.
• Runners CI où les échecs se relancent et où vous acceptez l’échec occasionnel bizarre.

Le mot clé est jetable. Si vous dites « sans état » mais que vous mettez en cache des sessions localement et écrivez des fichiers sur des disques éphémères qui deviennent par accident importants, vous vous mentez.

2) Postes développeurs pour travail non critique

La plupart des machines développeurs n’ont pas besoin d’ECC. Le gain de productivité dû à des CPU/SSD plus rapides peut valoir plus que la réduction marginale du risque d’erreur mémoire.

Exception : si vous construisez des releases, signez des artefacts, entraînez des modèles que vous ne pouvez pas relancer, ou faites beaucoup de travail noyau, vous vous rapprochez de « la correction compte ». Alors l’ECC est moins un luxe.

3) Budget serré, mieux dépensé sur sauvegardes et monitoring

Si vous devez choisir entre l’ECC et avoir réellement des sauvegardes, achetez les sauvegardes. Pareil pour un bon monitoring, des scrubs de filesystem, la réplication et des tests de restauration périodiques. L’ECC réduit un mode de défaillance. Les sauvegardes couvrent beaucoup d’autres, y compris les erreurs humaines.

Blague n°2 : Si votre stratégie de sauvegarde est « on a du RAID », l’ECC ne vous sauvera pas — votre problème, c’est l’optimisme, pas la mémoire.

4) Environnements de labo à vie courte

Bancs de test, sandboxes jetables, prototypes hack-week. Non-ECC est acceptable si vous acceptez l’occurrence occasionnelle d’échecs bizarres et si vous n’utilisez pas le labo pour valider l’intégrité de stockage ou publier des résultats.

Une règle décisionnelle qui marche en réunion

Utilisez l’ECC si l’un des éléments suivants est vrai :

• Vous stockez des données importantes sur la machine.
• Vous exécutez beaucoup de VMs/conteneurs avec impact réel.
• Le recalcul est coûteux ou impossible.
• Vous devez prouver l’intégrité aux auditeurs ou clients.
• Vous ne pouvez pas tolérer des incidents « bizarres et irréproductibles ».

Si aucun n’est vrai et que le système est vraiment jetable, l’ECC est optionnel. Toujours agréable. Pas obligatoire.

8 faits rapides et historique à répéter en réunion

1. L’ECC existe depuis bien avant le cloud. Les mainframes utilisaient parité et schémas de type ECC parce que les jobs longue durée ne pouvaient pas tolérer la corruption aléatoire.
2. La mémoire parité en était une cousine. La parité détecte des erreurs sur un bit mais ne peut pas les corriger ; l’ECC corrige généralement les erreurs sur un bit automatiquement.
3. SECDED est le standard courant. Correction d’un bit, détection de deux bits est l’histoire typique des serveurs, bien que des schémas avancés existent.
4. Les « soft errors » sont réels. Certaines inversions de bit ne proviennent pas d’une puce définitivement défectueuse ; ce sont des événements transitoires liés à la fuite de charge et aux radiations.
5. Les cellules DRAM ont rétréci. Une charge plus petite par cellule peut rendre les systèmes plus sensibles aux perturbations, ce qui explique pourquoi l’industrie a ajouté des mitiges au fil du temps.
6. Les contrôleurs mémoire sont passés sur les CPU. Cela a amélioré la performance mais a aussi rendu la validation de plateforme (CPU + carte mère + DIMMs) plus importante pour le comportement et le reporting de l’ECC.
7. Le scrub existe. De nombreuses plateformes serveur lisent périodiquement la mémoire et corrigent proactivement les erreurs, réduisant la probabilité d’accumulation d’erreurs multi-bits.
8. L’ECC peut être présent mais « inactif ». Il est possible d’installer physiquement des DIMMs ECC mais de fonctionner en mode non-ECC selon le support CPU/carte et les réglages firmware.

Trois micro-histoires d’entreprise venues du terrain

Micro-histoire n°1 : L’incident causé par une mauvaise hypothèse

L’entreprise grandissait vite, et leur serveur de stockage « temporaire » est devenu permanent — parce que c’est ce qui arrive quand ça marche. C’était une belle machine : beaucoup de baies, CPU correct, RAM non-ECC parce que « c’est juste un serveur de fichiers ». Ils utilisaient ZFS, se sentaient sophistiqués, et se disaient que les sommes de contrôle faisaient le gros du travail.

Quelques mois plus tard, les sauvegardes ont commencé à échouer. Pas bruyamment. Un job hebdomadaire rapportait parfois une discordance dans un flux tar. Les ingénieurs ont haussé les épaules, blâmé le réseau, et relancé. Parfois ça passait. Parfois non. Les échecs étaient suffisamment rares pour être ignorés, ce qui est la fréquence la plus dangereuse.

Puis un test de restauration — fait pour une demande client — a rencontré un dataset corrompu. ZFS a fidèlement signalé des erreurs de checksum lors des lectures. Mais l’histoire ne collait pas : le pool était en miroir, les disques semblaient sains, et les scrubs ne criaient pas. L’hypothèse inconfortable est apparue : la checksum « correcte » avait été calculée sur des données corrompues, puis répliquée dans les sauvegardes. L’intégrité avait été violée en amont.

Ils ont quand même remplacé un disque. Rien n’a changé. Ils ont remplacé un contrôleur. Toujours instable. Finalement quelqu’un a vérifié les logs d’erreurs mémoire. Il y avait des erreurs corrigées qui augmentaient en silence, depuis des semaines. Personne ne les alertait. Le DIMM était marginal ; sous charge il inversait des bits occasionnellement. ZFS a fait exactement ce qu’on lui avait demandé : il a checksumé ce qu’il a vu.

La solution a été simple — remplacer les DIMMs, activer l’alerte sur EDAC/MCE, et arrêter de prétendre que l’intégrité du stockage commence au disque. La leçon n’était pas « ZFS a besoin d’ECC ». La leçon était « les hypothèses ne sont pas des contrôles ».

Micro-histoire n°2 : L’optimisation qui s’est retournée

Une autre équipe gérait un cluster de virtualisation pour des services internes. Ils voulaient plus de densité. L’acheteur a dit que la référence ECC était en rupture, mais la variante non-ECC était disponible maintenant, moins chère et « pratiquement la même ». L’équipe a signé, car la douleur immédiate de capacité était plus forte que la douleur future de la correction.

Au début, tout s’est amélioré. Plus d’hôtes, plus de marge, coûts plus bas. Puis les bizarreries ont commencé : redémarrages occasionnels de VM, réparations de systèmes de fichiers à l’intérieur des invités, et les tickets classiques « ça n’arrive que sous charge ». Les ingénieurs ont ajusté des paramètres noyau, mis à jour les hyperviseurs, blâmé les drivers, et écrit de longs postmortems sur un firmware NIC flaky.

Un jour, la base critique d’une VM a montré une corruption d’index. La réplication a aussi rompu parce que le standby était en désaccord. L’équipe base de données insistait sur un problème matériel. L’équipe virtualisation insistait sur la base. Tout le monde avait raison, ce qui est une autre façon de dire que tout le monde a souffert.

Quand ils ont finalement lancé un test mémoire et inspecté les logs machine check, ils ont trouvé des fautes mémoire intermittentes. Pas assez pour crasher l’hôte systématiquement — juste assez pour corrompre. L’« optimisation » d’éviter l’ECC n’avait pas seulement risqué des pannes ; elle avait créé une fiabilité lente, le type qui grignote le temps d’ingénierie en tranches de 30 minutes pendant des mois.

Ils ont remplacé les hôtes par des systèmes ECC au cycle suivant. Les objectifs de densité ont été atteints de toute façon via un meilleur scheduling et un redimensionnement adéquat. Les « économies » de la non-ECC avaient été remboursées, avec intérêts, en attention humaine.

Micro-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise fintech-like exploitait une flotte modeste de nœuds de stockage. Rien de glamour. ECC partout, sans exception. Plus important : ils avaient une politique selon laquelle les erreurs mémoire corrigées étaient traitées comme un disque défaillant — actionnable, ticketé, suivi.

Un nœud a commencé à enregistrer quelques erreurs corrigées par jour. Pas de panne. Pas d’impact client. Le monitoring l’a détecté parce qu’ils expédiaient les compteurs EDAC dans leur stack de métriques et avaient une alerte simple : « toute erreur corrigée sur les hôtes de stockage en production ». L’ingénieur on-call a soupiré, ouvert un ticket et planifié une fenêtre de maintenance.

Pendant la fenêtre, ils ont remplacé le DIMM, lancé un scrub, et sont passés à autre chose. Une semaine plus tard, l’ancien DIMM — maintenant dans une machine de test — a commencé à produire des erreurs non corrigeables sous stress. Si cette défaillance avait eu lieu en production, cela aurait ressemblé à un crash aléatoire au mieux, et à une corruption silencieuse au pire.

Le meilleur incident est celui qui ne devient jamais un postmortem. C’est juste un ticket de maintenance qui se ferme. C’est ce que l’ECC plus la discipline ennuyeuse vous achètent.

Tâches pratiques : 12+ vérifications avec commandes, sorties et décisions

Ce sont les vérifications que je lance vraiment quand quelqu’un demande « avons-nous de l’ECC ?» ou quand un système se comporte comme hanté. Les commandes supposent Linux ; adaptez les noms de paquets à votre distro.

Task 1: Confirm the system thinks ECC exists (DMI)

cr0x@server:~$ sudo dmidecode -t memory | sed -n '1,120p'
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 3.2.1 present.

Handle 0x0038, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: Multi-bit ECC
	Maximum Capacity: 512 GB
	Number Of Devices: 8

Ce que cela signifie : « Error Correction Type: Multi-bit ECC » est un bon signe. S’il indique « None » ou « Unknown », la plateforme peut ne pas supporter l’ECC ou le firmware ne le rapporte pas.

Décision : S’il ne rapporte pas clairement l’ECC, n’assumez pas. Passez aux vérifications EDAC/MCE ci‑dessous et vérifiez dans le BIOS/UEFI.

Task 2: Check individual DIMM type and speed

cr0x@server:~$ sudo dmidecode -t 17 | egrep -i 'Locator:|Type:|Type Detail:|Speed:|Configured Memory Speed:|Manufacturer:|Part Number:'
	Locator: DIMM_A1
	Type: DDR4
	Type Detail: Synchronous Registered (Buffered)
	Speed: 2666 MT/s
	Configured Memory Speed: 2666 MT/s
	Manufacturer: Samsung
	Part Number: M393A4K40CB2-CTD

Ce que cela signifie : Les DIMMs registerés/buffered sont courants sur serveurs et généralement ECC‑capables. Les UDIMM peuvent aussi être ECC, selon la plateforme.

Décision : Si vous voyez des UDIMM grand public sur une carte serveur supposée, revérifiez que vous n’êtes pas dans un territoire où l’ECC est physiquement impossible.

Task 3: See if the kernel has EDAC drivers loaded

cr0x@server:~$ lsmod | egrep 'edac|skx_edac|i10nm_edac|amd64_edac'
skx_edac               32768  0
edac_mce_amd           28672  0
edac_core              65536  1 skx_edac

Ce que cela signifie : Les modules EDAC indiquent que le noyau peut rapporter des événements du contrôleur mémoire. Les noms de modules varient selon la génération/vendor du CPU.

Décision : Si aucun module EDAC n’existe et que vous attendez de l’ECC, installez les modules/paquets noyau appropriés ou vérifiez si votre plateforme rapporte via IPMI uniquement.

Task 4: Inspect EDAC counters (corrected vs uncorrected)

cr0x@server:~$ for f in /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ue_count; do echo "$f: $(cat $f)"; done
/sys/devices/system/edac/mc/mc0/ce_count: 0
/sys/devices/system/edac/mc/mc0/ue_count: 0

Ce que cela signifie : ce_count sont les erreurs corrigées. ue_count sont les erreurs non corrigées. Les erreurs corrigées ne sont pas « ok » ; elles sont des preuves.

Décision : Toute hausse de ce_count en production devrait déclencher un ticket. Toute ue_count doit déclencher de l’urgence et probablement une fenêtre de maintenance ASAP.

Task 5: Read kernel logs for machine check events

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|edac|ecc' | tail -n 20
Jan 10 12:44:10 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#1_DIMM#0
Jan 10 12:44:10 server kernel: mce: [Hardware Error]: Corrected error, no action required.

Ce que cela signifie : Vous voyez des erreurs corrigées qui sont journalisées. La ligne « no action required » est du langage noyau, pas un conseil opérationnel.

Décision : Identifiez le slot DIMM dans le message, planifiez le remplacement, et surveillez le taux. Si le taux augmente, raccourcissez le délai.

Task 6: Decode MCE details with mcelog (where applicable)

cr0x@server:~$ sudo mcelog --client
mcelog: error reading log: No such file or directory
mcelog: consider using rasdaemon on newer kernels

Ce que cela signifie : De nombreuses distributions modernes préfèrent rasdaemon à mcelog. Cette sortie vous indique que le choix des outils compte.

Décision : Utilisez rasdaemon et interrogez sa base, ou fiez-vous aux journaux plus aux compteurs EDAC.

Task 7: Use rasdaemon to list RAS (Reliability/Availability/Serviceability) events

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
	Corrected Errors: 1
	Uncorrected Errors: 0

Ce que cela signifie : Un compte des événements ECC suivis par les outils RAS. Utile pour le monitoring de flotte.

Décision : Si les erreurs corrigées ne sont pas nulles, corrélez les timestamps avec la charge et les températures ; planifiez le remplacement du DIMM.

Task 8: Check if ECC is enabled in firmware (best-effort via vendor tools/IPMI)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i 'mem|dimm|ecc' | head
DIMM A1 Status     | 0x01 | ok  | 10.1 | Presence detected
DIMM A2 Status     | 0x02 | ok  | 10.2 | Presence detected

Ce que cela signifie : La présence n’est pas l’ECC, mais cela indique que l’IPMI voit les DIMMs et peut rapporter des défauts ailleurs.

Décision : Si vous ne pouvez pas confirmer le mode ECC via le système d’exploitation, vérifiez dans le BIOS/UEFI (souvent « ECC mode », « memory RAS », « patrol scrub »).

Task 9: Run a targeted memory stress test (maintenance window)

cr0x@server:~$ sudo memtester 2048M 1
memtester version 4.5.1 (64-bit)
testing 2048MB:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok
  8-bit Writes        : ok
  16-bit Writes       : ok
Done.

Ce que cela signifie : Un passe ne prouve pas la perfection, mais les échecs sont décisifs. Des erreurs corrigées par ECC peuvent apparaître dans les logs même si memtester affiche « ok ».

Décision : Si memtester échoue ou que les logs montrent des événements ECC pendant le stress, remplacez les DIMMs et retestez.

Task 10: Correlate ECC events with thermals (because heat is a bully)

cr0x@server:~$ sudo sensors | egrep -i 'temp|cpu|dimm' | head -n 12
coretemp-isa-0000
Package id 0: 71.0°C  (high = 80.0°C, crit = 100.0°C)
Core 0:       69.0°C  (high = 80.0°C, crit = 100.0°C)

Ce que cela signifie : Si les événements ECC augmentent avec les températures ou après une panne de ventilateur, vous avez un problème thermique ou d’aéraulique.

Décision : Corrigez le refroidissement, reseatez les DIMMs, et validez les courbes du firmware pour les ventilateurs. Ne remplacez pas seulement la mémoire en appelant cela de la « mauvaise chance ».

Task 11: Check ZFS for checksum errors and scrub results (storage integrity clue)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.
  scan: scrub repaired 0B in 00:18:23 with 0 errors on Wed Jan 10 02:10:11 2026
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     3
	  mirror-0  ONLINE       0     0     3
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
	tank/data/archive.bin

Ce que cela signifie : Des erreurs de checksum sont survenues quelque part le long du chemin. Les disques montrent 0, le pool montre CKSUM. Cela peut venir de la RAM, du contrôleur, du câble ou du firmware du disque.

Décision : Si le stockage signale des erreurs de checksum et que les disques semblent propres, vérifiez immédiatement les logs ECC/MCE. Vérifiez aussi les câbles/firmware HBA, mais n’ignorez pas la RAM.

Task 12: Use dmesg to spot I/O errors vs memory errors

cr0x@server:~$ dmesg -T | egrep -i 'ata[0-9]|nvme|i/o error|edac|mce' | tail -n 25
[Wed Jan 10 12:44:10 2026] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#1_DIMM#0
[Wed Jan 10 12:45:22 2026] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Ce que cela signifie : Vous avez à la fois des erreurs mémoire corrigées et des problèmes de lien disque. Ce n’est pas « une seule cause racine ». C’est « le système est stressé » ou « la plateforme est flaky ».

Décision : Stabilisez la plateforme. Commencez par la mémoire (remplacez le DIMM), puis traitez les erreurs SATA/NVMe (câbles, baie, firmware contrôleur).

Task 13: Confirm CPU and board support ECC (sanity check)

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU\(s\)'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
CPU(s):                          20

Ce que cela signifie : Xeon prend généralement en charge l’ECC. Les CPU grand public peuvent ou non le faire, selon la gamme produit.

Décision : Si vous voyez un CPU grand public dans un système où vous attendez l’ECC, vérifiez les capacités de la plateforme et n’assumez pas que les DIMMs vous sauveront.

Task 14: Watch for corrected error rate over time (a real SRE move)

cr0x@server:~$ watch -n 5 'for f in /sys/devices/system/edac/mc/mc*/ce_count; do echo "$f: $(cat $f)"; done'
Every 5.0s: for f in /sys/devices/system/edac/mc/mc*/ce_count; do echo "$f: $(cat $f)"; done

/sys/devices/system/edac/mc/mc0/ce_count: 12

Ce que cela signifie : Si le compteur s’incrémente pendant la charge normale, votre DIMM est activement corrigé.

Décision : Erreurs corrigées en hausse → planifier le remplacement. Montée rapide → maintenance d’urgence.

Task 15: Check system event log via IPMI (hardware-level truth serum)

cr0x@server:~$ sudo ipmitool sel list | tail -n 8
  118 | 01/10/2026 | 12:44:10 | Memory | Correctable ECC | Asserted
  119 | 01/10/2026 | 12:44:11 | Memory | Correctable ECC | Asserted

Ce que cela signifie : Le BMC est d’accord : des événements ECC se produisent. C’est précieux lorsque les logs OS sont bruyants ou tournent.

Décision : Si le SEL montre des événements ECC répétés, traitez cela comme un disque en fin de vie : planifiez le remplacement du DIMM et investiguez les causes environnementales.

Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Vous êtes en astreinte. Quelque chose corrompt, plante ou échoue « au hasard ». Vous avez besoin du chemin le plus rapide vers « est-ce la mémoire, le stockage ou autre chose ? »

Premier : déterminer si le système ment en silence (signaux ECC)

• Vérifiez les erreurs mémoire corrigées/non corrigées :

  cr0x@server:~$ for f in /sys/devices/system/edac/mc/mc*/{ce_count,ue_count}; do echo "$f: $(cat $f)"; done
  /sys/devices/system/edac/mc/mc0/ce_count: 3
  /sys/devices/system/edac/mc/mc0/ue_count: 0
  

• Parcourez les logs noyau :

  cr0x@server:~$ sudo journalctl -k -b | egrep -i 'edac|mce|machine check' | tail -n 50
  Jan 10 12:44:10 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#1_DIMM#0
  

Interprétation : Les erreurs corrigées signifient que la plateforme compense. Cela corrèle fortement avec des « problèmes bizarres et irréproductibles ». Les erreurs non corrigées signifient que vous êtes en zone dangereuse.

Second : classer le mode de défaillance (intégrité des données vs disponibilité)

• Symptômes d’intégrité : mismatches de checksum, archives corrompues, erreurs d’index DB, divergence de réplication.
• Symptômes de disponibilité : kernel panics, reboots, vagues de SIGSEGV, crashs d’hôte VM.

Interprétation : Les problèmes d’intégrité doivent vous pousser vers l’ECC et les checks bout en bout. Les problèmes de disponibilité peuvent toujours être liés à l’ECC, mais aussi à l’alimentation, au firmware ou au thermique.

Troisième : isoler le chemin stockage vs mémoire

• Recherchez des erreurs du transport stockage (SATA/NVMe/HBA) :

  cr0x@server:~$ dmesg -T | egrep -i 'nvme|ata|sas|scsi|i/o error|reset' | tail -n 50
  [Wed Jan 10 12:45:22 2026] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
  

• Vérifiez l’état des scrubs de système de fichiers (si applicable) :

  cr0x@server:~$ sudo zpool status
    pool: tank
   state: ONLINE
    scan: scrub repaired 0B in 00:18:23 with 0 errors on Wed Jan 10 02:10:11 2026
  

Interprétation : Si les disques et le transport semblent propres mais que vous voyez de la corruption, la mémoire devient plus suspecte. Si des erreurs de transport existent, corrigez-les aussi — les systèmes peuvent échouer en grappes.

Erreurs fréquentes : symptômes → cause racine → correction

1) « Nous avons installé des DIMMs ECC, donc nous sommes protégés. »

Symptômes : Toujours des corruptions aléatoires ; pas de compteurs ECC ; pas de modules EDAC ; BIOS indique ECC désactivé.

Cause racine : La plateforme (CPU/carte) ne supporte pas l’ECC, ou l’ECC est désactivé dans le firmware, ou l’OS ne peut pas le reporter.

Correction : Vérifiez le support ECC CPU/carte, activez l’ECC dans le BIOS/UEFI, confirmez les compteurs EDAC et/ou les événements IPMI SEL.

2) « Les erreurs corrigées sont OK ; le système dit qu’il les a corrigées. »

Symptômes : Erreurs corrigées qui augmentent ; crashes applicatifs occasionnels ; mismatches de checksum rares.

Cause racine : Dégradation du DIMM, timings marginaux, stress thermique ou bruit d’alimentation. La correction masque le symptôme jusqu’à ce qu’elle n’y parvienne plus.

Correction : Traitez les erreurs corrigées comme un échec prédictif. Remplacez le DIMM, vérifiez les thermiques, mettez à jour le BIOS, évitez overclock/undervolt mémoire.

3) « Les checksums ZFS signifient que l’ECC n’a pas d’importance. »

Symptômes : Erreurs de checksum dans le pool ; fichiers corrompus ; scrub montrant des problèmes qui ne se mappent pas clairement à un disque.

Cause racine : La corruption s’est produite en RAM avant la génération du checksum ou pendant la mise en attente I/O ; ou la mémoire a corrompu des métadonnées en vol.

Correction : Utilisez l’ECC, monitorisez EDAC/MCE, et gardez scrubs et sauvegardes. Checksums et ECC se complètent.

4) « On se fiera aux checksums applicatifs. »

Symptômes : Mismatches de hash applicatif ; échecs TLS sporadiques ; erreurs de décompression étranges.

Cause racine : Vous détectez la corruption après qu’elle s’est produite. Bien pour la prise de conscience, mauvais pour empêcher les mauvaises écritures et leurs effets secondaires.

Correction : Déplacez la protection plus tôt dans le pipeline : ECC + bonne intégrité stockage + monitoring.

5) « Les tests mémoire sont passés, donc ce n’est pas la RAM. »

Symptômes : Memtest/memtester passent ; production voit toujours des fautes inexpliquées.

Cause racine : Fautes intermittentes déclenchées par des températures, des motifs, des charges ou des timings spécifiques que le test n’a pas touchés.

Correction : Corrélez les erreurs avec les compteurs EDAC, faites des runs de stress plus longs, testez sous thermiques similaires, ou échangez les DIMMs pour confirmer.

6) « Nous avons changé le DIMM, problème résolu. » (…jusqu’à ce que ce ne soit pas le cas)

Symptômes : Les erreurs corrigées réapparaissent sur un autre slot ou canal.

Cause racine : Slot de carte mère défectueux, problème de contrôleur mémoire, bug BIOS, instabilité PSU, ou VRMs qui surchauffent.

Correction : Reseat, déplacez les DIMMs entre les canaux pour voir si l’erreur suit le slot, mettez à jour le firmware, vérifiez l’alimentation et le refroidissement, envisagez le remplacement de la carte.

7) « La non-ECC suffit car nous avons de la HA. »

Symptômes : La HA masque les crashs mais des incohérences de données apparaissent entre réplicas ; des basculements surviennent « sans raison ».

Cause racine : La HA améliore la disponibilité, pas la correction. La corruption mémoire peut être répliquée comme des données « valides ».

Correction : Ajoutez de l’ECC là où la correction compte et implémentez la validation bout en bout (checksums, scrubs, vérifications de cohérence, tests de restauration).

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

Checklist A: Décider si l’ECC en vaut la peine (version honnête)

1. Le système stocke-t-il des données uniques ou liées à la conformité ? Si oui : ECC.
2. Le système est-il un hyperviseur ou un hôte de conteneurs dense ? Si oui : ECC.
3. Une mauvaise sortie serait-elle pire qu’une sortie lente ? Si oui : ECC.
4. Pouvez-vous tout recalculer facilement et détecter les sorties erronées de façon fiable ? Si oui : peut-être non-ECC.
5. Avez-vous des sauvegardes, des scrubs et des tests de restauration ? Si non : réglez ça avant de discuter de l’ECC.

Checklist B: Déployer le monitoring ECC (la partie que les gens sautent)

1. Activez les drivers EDAC dans votre noyau/distro si disponibles.
2. Envoyez les logs noyau (journal) dans votre système de logging.
3. Collectez les compteurs EDAC (ce_count, ue_count) dans des métriques.
4. Alarmez sur toute erreur corrigée pour les hôtes de stockage et bases de données.
5. Alarmez sur toute erreur non corrigée pour tous les hôtes de production.
6. Documentez le mapping physique DIMM (étiquettes de slot chassis vs nommage OS).
7. Définissez une politique opérationnelle : « CE déclenche ticket ; UE déclenche maintenance maintenant. »

Checklist C: Quand des erreurs ECC apparaissent en production

1. Confirmez que les compteurs augmentent (pas un pic historique isolé).
2. Vérifiez les événements SEL/IPMI pour corroborer les logs OS.
3. Identifiez le slot/channel DIMM depuis la sortie EDAC/MCE.
4. Vérifiez les thermiques et changements firmware récents.
5. Planifiez la maintenance pour remplacer le DIMM (ou déplacez-le pour reproduire si vous devez le prouver).
6. Après remplacement : vérifiez que les compteurs cessent d’augmenter et lancez un test mémoire de stress.
7. Si les erreurs persistent : suspectez le slot/channel/carte ou le contrôleur mémoire ; escaladez vers remplacement hardware.

Checklist D: Si vous choisissez non-ECC (comment éviter d’être imprudent)

1. Gardez les workloads vraiment sans état et jetables, pas seulement sur PowerPoint.
2. Utilisez des checksums aux frontières (ETags stockage objet, hashes applicatifs, vérifs DB où approprié).
3. Automatisez rebuild et redeploy ; traitez les hôtes comme du bétail, pas des animaux de compagnie.
4. Lancez des jobs fréquents de validation d’intégrité (scrubs, équivalents fsck, checks DB).
5. Ayez des sauvegardes testées et une habitude de drills de restauration.

FAQ

1) L’ECC rend-il mon système plus lent ?

Généralement négligeable. Toute pénalité est typiquement minime comparée aux goulots disques, réseau ou applicatifs. Si votre SLA dépend de cette marge, vous avez un autre problème d’architecture.

2) L’ECC est-il requis pour ZFS ?

ZFS fonctionnera sans ECC. Mais si vous utilisez ZFS parce que vous vous souciez de l’intégrité, l’ECC est un compagnon sensé. ZFS ne peut pas checksumer correctement si la RAM lui fournit les mauvais bits avant le checksum.

3) L’ECC peut-il prévenir toute la corruption de données ?

Non. Elle réduit une classe courante d’erreurs mémoire transitoires et certaines persistantes. Vous avez toujours besoin de sommes de contrôle bout en bout, scrubs, sauvegardes et discipline opérationnelle.

4) Si j’ai RAID/mirrors, ai-je encore besoin d’ECC ?

RAID protège contre les pannes disque et certains read errors. Il ne protège pas contre de mauvaises données écrites dès le départ à cause d’une corruption mémoire.

5) Comment savoir si l’ECC est vraiment activé ?

Cherchez le reporting EDAC côté OS (/sys/devices/system/edac), les logs noyau mentionnant EDAC/MCE et les erreurs corrigées, et/ou les entrées IPMI SEL pour l’ECC. Vérifiez aussi les réglages BIOS/UEFI. « DIMMs ECC installés » n’est pas une preuve.

6) Quelle est la différence entre erreurs ECC corrigées et non corrigées ?

Corrigées : l’ECC a réparé ; le système est resté up ; vous avez reçu un avertissement. Non corrigées : l’ECC n’a pas pu réparer ; vous risquez des crashs ou un état corrompu et devez agir immédiatement.

7) Si je vois quelques erreurs corrigées, puis-je les ignorer ?

Vous pouvez, de la même façon que vous pouvez ignorer un détecteur de fumée avec une pile faible. Un petit nombre peut ne jamais se reproduire, mais la tendance des erreurs corrigées est un classique signal « remplacez le DIMM maintenant, évitez un incident pire plus tard ».

8) La non-ECC est-elle acceptable pour des nœuds workers Kubernetes ?

Parfois. Si les nœuds sont vraiment jetables, les workloads sont répliqués, et la correction est vérifiée en aval, cela peut aller. Mais les plans de contrôle, nœuds etcd, nœuds de stockage et opérateurs de bases de données ne sont pas des endroits où parier.

9) L’ECC aide-t-elle pour la sécurité ?

Indirectement. Elle réduit certains chemins de comportement indéfini causés par la corruption mémoire, mais ce n’est pas une fonctionnalité de sécurité. Ne confondez pas « plus fiable » et « sécurisé ».

10) Dois-je acheter de l’ECC pour mon serveur domestique ?

Si il contient des photos irremplaçables, sert de cible de sauvegarde, ou fonctionne comme votre « boîte tout-en-un », l’ECC est un bon upgrade — surtout si le coût delta est modeste. Si c’est un labo que vous effacez chaque mois, dépensez d’abord sur des SSD et des sauvegardes.

Prochaines étapes à faire cette semaine

1. Inventairez votre flotte : identifiez quels hôtes stockent des données, exécutent des bases ou servent d’hyperviseurs. Ce sont des candidats ECC par défaut.
2. Vérifiez que l’ECC est réel : lancez les vérifications DMI + EDAC + logs sur un hôte échantillon. Si vous ne pouvez pas prouver que l’ECC est activé, supposez que ce n’est pas le cas.
3. Transformez les erreurs corrigées en tickets : ajoutez des alertes sur les compteurs EDAC ou les événements SEL. Les erreurs corrigées ne sont pas du « bruit ». Ce sont des signaux précoces.
4. Renforcez l’intégrité bout en bout : scrubs, tests de restauration, checksums et vérifications de santé de réplication. L’ECC réduit le risque ; il n’enlève pas la responsabilité.
5. Rédigez la politique : que faire quand ce_count augmente, et que faire quand ue_count apparaît. Rendez-la ennuyeuse et automatique.

La RAM ECC n’est pas un luxe quand vous protégez des données ou exécutez du calcul multi-tenant. Ce n’est pas non plus un substitut aux sauvegardes, scrubs et hygiène opérationnelle. Achetez-la là où la correction compte, évitez-la là où le calcul est jetable, et monitorisez-la partout où vous la déployez — parce que l’essentiel est de savoir quand l’univers a essayé d’inverser un bit.