Corruption silencieuse avec ZFS : ce que ZFS détecte et que RAID ignore souvent

Corruption silencieuse : de quoi il s’agit et pourquoi RAID peut la manquer

La corruption silencieuse (a.k.a. « bit rot », « erreurs de secteur latentes », « écritures mal dirigées » ou « oh le contrôleur a menti »)
désigne tout cas où la pile de stockage renvoie des données qui ne sont pas ce qui a été écrit, sans lever d’erreur I/O.
Le mot-clé est silencieuse : l’OS reçoit une lecture réussie, votre application obtient des octets, et personne n’émet d’exception.

RAID — en particulier le RAID matériel ou le RAID « mdadm-only » — se concentre généralement sur la disponibilité des périphériques. Un disque tombe en panne, la parité ou
un miroir maintient le volume en ligne. Très bien. Mais RAID a souvent une visibilité limitée sur le fait que le contenu des blocs est
correct tel qu’il a été écrit à l’origine par l’application. Il peut détecter certaines erreurs (comme un secteur illisible),
mais il peut aussi livrer joyeusement des données corrompues parce qu’il n’a pas de vérification de bout en bout depuis l’application → système de fichiers → disque.

Voici la vérité inconfortable : de nombreux designs RAID partent du principe que le reste de la pile est honnête. En production, c’est
une hypothèse risquée. Les contrôleurs ont des bugs de firmware. Les HBA ont des bizarreries. Les câbles et backplanes se comportent
de manière étrange à l’échelle. Les disques remappent des secteurs. Le DMA peut mal fonctionner. La mémoire peut renverser des bits.
Et oui, parfois des humains « réparent » un problème de stockage en changeant de slot, en recâblant ou en mettant à jour un firmware — et créent
accidentellement un nouveau problème.

ZFS adopte une approche différente : il suppose que l’environnement est hostile. Il vérifie tout ce qu’il peut, et il considère le « succès »
d’une couche inférieure comme une suggestion, pas comme une garantie.

Ce que ZFS « voit » et que le RAID classique ignore souvent

Checksums de bout en bout : l’idée principale

ZFS stocke une somme de contrôle pour chaque bloc qu’il écrit — données et métadonnées — et range cette somme dans les métadonnées parentes
du bloc (pas à côté du bloc lui‑même). Quand ZFS lit un bloc, il recalcule la somme et la compare à la valeur attendue. Si les checksums
ne correspondent pas, ZFS sait que les données sont incorrectes même si le disque a répondu « lecture OK ».

Cette somme est de bout en bout : elle couvre le chemin du point de vue du système de fichiers jusqu’au périphérique. ZFS ne se contente pas
de s’appuyer sur l’ECC interne du disque ou la logique de parité du contrôleur comme mécanisme d’intégrité unique. Il les utilise
comme défense en profondeur.

Lectures auto‑réparatrices (lorsqu’il y a redondance)

Si le pool dispose de redondance (miroir, RAIDZ, dRAID), ZFS peut tenter d’autres copies lorsqu’il détecte une corruption. Il lit
une autre réplique, valide la checksum, puis répare la copie défectueuse automatiquement. Ce n’est pas « reconstruire quand un disque meurt ».
C’est « réparer un seul mauvais bloc alors que le disque est toujours en vie ».

La parité RAID peut reconstruire des données quand un disque est manquant. Mais si un disque renvoie un mauvais bloc sans erreur, RAID
ne sait souvent pas quel disque est fautif, et il peut ne pas disposer d’une checksum de haut niveau pour le prouver. Vous vous retrouvez
avec un bloc de Schrödinger : à la fois correct et incorrect jusqu’à ce que vous l’utilisiez.

Scrubs : détection proactive plutôt que panne surprise

Les scrubs ZFS parcourent l’espace alloué du pool, lisent les blocs, vérifient les checksums et réparent lorsqu’ils le peuvent. C’est ainsi
que vous attrapez les erreurs de secteur latentes avant que la seule copie correcte soit écrasée ou avant que vous n’ayez besoin
de ces données pendant un incident.

Copy-on-write : moins de « torn writes », surface de défaillance différente

ZFS est copy‑on‑write (CoW). Il écrit de nouveaux blocs ailleurs, puis met à jour atomiquement les pointeurs de métadonnées. Le CoW n’empêche
pas magiquement toute corruption, mais il réduit un problème classique du RAID : les écritures partielles laissant un système de fichiers
dans un état incohérent (surtout après une coupure de courant). Les systèmes de fichiers traditionnels comptent sur le journaling et l’ordre
correct des opérations. ZFS s’appuie sur des sémantiques transactionnelles au niveau du système de fichiers.

Checksumming des métadonnées aussi, car perdre la carte est pire que perdre le territoire

Beaucoup de systèmes traitent les métadonnées comme « petites et fiables ». En pratique, la corruption des métadonnées est souvent catastrophique :
structures de répertoires, tables d’allocation, blocs indirects. ZFS checksumpe les métadonnées et peut les auto‑réparer grâce à la redondance.
C’est une grosse différence dans le comportement en cas de panne : au lieu de « le système de fichiers a besoin de fsck et de prières », vous obtenez souvent
« ZFS l’a réparé lors de la lecture ».

Meilleur suivi des erreurs : vous obtenez des reçus

Les compteurs d’erreurs ZFS distinguent les erreurs de lecture, d’écriture et les erreurs de checksum. Cette dernière catégorie est la plus intéressante :
le disque n’a pas signalé d’erreur, mais les données ne correspondaient pas. Beaucoup de configurations RAID n’exposent jamais cette nuance. ZFS
vous dira quand la pile de stockage vous a menti.

Une idée paraphrasée de W. Edwards Deming s’applique aussi aux opérations de stockage : sans mesure, vous gérez en conjectures (idée paraphrasée, Deming).
ZFS mesure l’intégrité en continu.

Les forces du RAID et les lacunes qu’on confond avec de la sécurité

RAID vise la disponibilité, pas la correction

Le rôle principal du RAID est de maintenir un périphérique bloc en ligne lorsqu’un disque échoue. Il est bon pour cela. Il est aussi pratique pour cacher
les pannes de disque à l’OS, ce qui peut être à la fois confortable et dangereux : confortable car les serveurs continuent de tourner,
dangereux car la première fois que vous remarquez un problème, la carte RAID peut déjà jongler avec plusieurs états dégradés.

« Mais le contrôleur RAID a une batterie et un patrol read »

Le cache d’écriture avec batterie (ou flash) est excellent pour les performances et peut réduire certains risques liés aux coupures d’alimentation. Le patrol
read peut détecter des secteurs illisibles. Aucun des deux ne garantit l’exactitude de bout en bout.

• Le patrol read est un outil de santé de surface disque. Il ne valide pas que les octets lus correspondent à ce que l’application a écrit
  il y a des mois.
• Certaines piles de contrôleurs utilisent des checksums en interne, mais elles ne sont généralement pas exposées au système de fichiers, et elles
  ne vous protègent pas contre les écritures mal dirigées ou la corruption côté hôte.

Le write hole et les cauchemars de parité

Les écritures de parité RAID5/6 peuvent souffrir du « write hole » si l’alimentation est perdue au milieu d’une mise à jour de stripe. Les contrôleurs
modernes atténuent cela avec cache + journalisation, mais les implémentations varient. Le RAID logiciel a ses propres stratégies d’atténuation, également variables.
ZFS évite le write hole classique par conception car il n’écrase jamais en place ; il commit de nouveaux arbres cohérents.

Quand RAID reconstruit, il met à l’épreuve votre maillon le plus faible

La reconstruction/resilver lit d’énormes quantités de données. C’est alors que les erreurs de lecture latentes apparaissent. Une reconstruction RAID6 peut encore échouer
si trop de secteurs sont illisibles au mauvais moment. Le resilver ZFS peut être plus rapide dans certains scénarios car il ne reconstruit que les blocs alloués,
pas chaque secteur d’un disque.

Blague #1 : RAID, c’est comme une roue de secours — vous êtes content de l’avoir, jusqu’à ce que vous réalisiez qu’elle est à plat depuis des mois.

Faits et contexte historique à connaître

1. ZFS est originaire de Sun Microsystems au début‑milieu des années 2000, conçu pour combiner gestion de volumes et système de fichiers en une seule pile cohérente.
2. Les checksums de bout en bout étaient un point de conception central dès le départ : ZFS considère la corruption silencieuse comme un problème majeur, pas comme un cas marginal.
3. Les snapshots CoW n’étaient pas « agréables à avoir » — ils sont structurellement liés à la cohérence transactionnelle et aux mises à jour sûres sur disque.
4. Le RAID précède les disques multi‑téraoctets modernes de plusieurs décennies ; beaucoup d’hypothèses RAID ont été façonnées quand les fenêtres de reconstruction étaient courtes et le risque URE plus faible.
5. Les contrôleurs RAID matériels sont devenus populaires en partie pour délester le CPU et standardiser la gestion des disques, à une époque où la mathématique de parité et le caching importaient davantage.
6. Le scrub ZFS a formalisé ce que beaucoup d’administrateurs faisaient manuellement : lectures complètes périodiques pour faire émerger les erreurs latentes avant qu’elles ne deviennent une perte de données.
7. Les disques d’entreprise annoncent des taux URE (unrecoverable read errors), ce qui rappelle qu’« un disque qui n’est pas encore mort » peut échouer pendant une reconstruction.
8. OpenZFS est devenu la lignée multi‑plateforme, avec un développement actif sur illumos, FreeBSD, Linux et autres — important car les bugs de stockage ne respectent pas les frontières des OS.
9. Le « bit rot » n’est pas un phénomène unique ; c’est un nom‑parapluie pour défauts médias, bugs firmware, écritures mal dirigées et fautes RAM/câble/contrôleur.

Modes de défaillance : comment la corruption survient en production

Écritures mal dirigées : la corruption la plus effrayante qui arrive sans prévenir

Une écriture mal dirigée se produit lorsque le système écrit les bonnes données au mauvais endroit. Votre application écrit le bloc A, mais
le disque/contrôleur l’écrit au bloc B. Les deux écritures « réussissent ». RAID reflète ou protège par parité le mauvais emplacement.
Plus tard, les lectures renvoient des données qui passent l’ECC du disque, et RAID pense que tout va bien.

ZFS attrape cela parce que la checksum stockée dans les métadonnées pour le bloc A ne correspondra pas à ce qui se trouve maintenant au bloc A.
Avec redondance, ZFS peut lire une autre copie et réparer.

Corruption DMA / mémoire : votre système de fichiers ne peut pas réparer ce qu’il ne détecte pas

Si une mauvaise RAM inverse des bits avant que les données n’atteignent le disque, le disque stocke un contenu corrompu. RAID protégera fidèlement
ces mauvais octets. ZFS calculera une checksum à l’écriture — donc si la corruption se produit avant le calcul de la checksum, la checksum
correspondra aux données corrompues et ZFS ne pourra pas savoir qu’elles étaient erronées.

C’est pourquoi la mémoire ECC est importante sur les systèmes ZFS. ZFS est un système d’intégrité ; il a quand même besoin d’une mémoire fiable.

Écritures partielles et ordre : la perte d’alimentation n’est pas polie

Une coupure d’alimentation soudaine peut créer des écritures déchirées : moitié ancienne, moitié nouvelle. Certains disques mentent sur l’achèvement des flush.
Certains contrôleurs réordonnent. Les systèmes de fichiers tentent de composer avec journaling, barrières et flushs soigneux.

Le modèle transactionnel CoW de ZFS réduit l’exposition, mais vous avez toujours besoin d’un ordre d’écriture sensé et de flush honnêtes.
Si votre disque accuse des écritures qu’il n’a pas persistées, vous pouvez encore perdre les dernières secondes de données. La différence :
vous avez moins de chances d’obtenir une structure de système de fichiers corrompue ; vous êtes plus susceptible de perdre des transactions récentes.

Mauvais secteurs : le méchant classique et ennuyeux

Les erreurs de secteur latentes apparaissent au pire moment : pendant une reconstruction, un scrub ou une restauration. RAID peut reconstruire si
l’erreur de lecture est identifiée et si la redondance est suffisante. ZFS peut faire de même, mais il valide aussi la correction avec des checksums
et peut réparer pendant que le disque reste en ligne.

Blague #2 : Les vendeurs de stockage promettent des « cinq neuf », mais ils ne disent jamais si ces neuf concernent la disponibilité ou votre sommeil.

Guide de diagnostic rapide

Quand vous suspectez une corruption ou que vous voyez des erreurs ZFS, la rapidité est importante. Pas parce que ZFS est fragile — parce que plus
vous fonctionnez en mode dégradé, plus vous risquez d’empiler des défaillances. Voici un ordre d’opérations rapide et pratique qui marche en
vraie vie d’astreinte.

1) Confirmer s’il s’agit d’un problème d’intégrité (checksum) ou d’un échec I/O (lecture/écriture)

• Vérifiez zpool status -v en premier. Si vous voyez des incréments CKSUM, c’est « le périphérique a renvoyé des données mais elles étaient erronées ».
• Si vous voyez des erreurs READ ou WRITE, c’est plus classique : défaillance du périphérique ou du transport.

2) Déterminer si la redondance peut guérir le problème

• Les miroirs et RAIDZ peuvent corriger automatiquement beaucoup d’erreurs de checksum.
• Les pools sur disque unique ne le peuvent pas. Ils peuvent détecter la corruption, mais pas la réparer.

3) Localiser le problème : un disque, un chemin, ou systémique

• Si les erreurs se concentrent sur un membre de vdev, suspectez ce disque, son câble, sa baie ou ce port HBA.
• Si plusieurs disques sur le même HBA posent problème, suspectez le contrôleur, le backplane, l’expander ou le firmware.
• Si les erreurs de checksum apparaissent sur de nombreux dispositifs sans motif, suspectez la mémoire, l’instabilité CPU ou un bug de pilote.

4) Décider : scrub, mettre hors ligne/remplacer, ou stopper les écritures

• Lancer un scrub si vous avez de la redondance et si le pool est stable ; il fera émerger et corriger davantage de problèmes.
• Mettre hors ligne/remplacer un périphérique qui continue d’accumuler des erreurs.
• Arrêter les écritures (ou geler les charges) si vous observez une corruption active sans stratégie claire de confinement.

5) Valider les sauvegardes en restaurant, pas en y croyant aveuglément

Si la corruption est suspectée, faites un vrai test de restauration de données représentatives. ZFS protège ce qu’il stocke, pas ce que votre système de sauvegarde
manipule mal.

Tâches pratiques : commandes, sorties et étapes suivantes

Ci‑dessous des tâches pratiques que j’attends d’un opérateur lors de la mise en service, de l’hygiène hebdomadaire et de la réponse à incident.
Chaque tâche inclut une commande réaliste, une sortie typique, ce que cela signifie et la décision à prendre.

Task 1: Identify corruption vs I/O failure

cr0x@server:~$ zpool status -v tank
  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. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 00:12:41 with 3 errors on Wed Dec 25 03:10:12 2025
config:

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

errors: Permanent errors have been detected in the following files:
        tank/vmstore@auto-2025-12-24:/vm/guest1/disk0.img

Sens : Les erreurs CKSUM sur sda indiquent des données erronées renvoyées sans erreur I/O. ZFS a trouvé au moins une erreur permanente dans un fichier spécifique.

Décision : Si la redondance existe, remplacez sda et restaurez ou recréez le fichier affecté. Si le fichier est un disque VM, traitez‑le comme critique : restaurez depuis un snapshot/sauvegarde connu sain.

Task 2: Start a scrub (and know what it will do)

cr0x@server:~$ sudo zpool scrub tank

Sens : Un scrub lira les blocs alloués, validera les checksums et réparera en utilisant la redondance.

Décision : Planifiez des scrubs régulièrement ; lancez‑en un après un remplacement matériel ou après un événement suspect (coupure, recâblage, reset de contrôleur).

Task 3: Check scrub progress and whether it’s healing or just reading

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:41 2025
        412G scanned at 1.31G/s, 88G issued at 288M/s, 6.02T total
        0B repaired, 1.43% done, 06:12:11 to go
config:

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

Sens : « 0B repaired » est bon ; si « repaired » augmente, ZFS est en train d’auto‑réparer.

Décision : Si les octets réparés augmentent régulièrement entre scrubs, considérez cela comme un problème de chemin matériel (disque, câble, HBA) et non comme un événement ponctuel cosmique.

Task 4: Inspect error counters over time

cr0x@server:~$ zpool status -p tank
  pool: tank
 state: ONLINE
config:

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

Sens : Les erreurs CKSUM sont des compteurs cumulés. Elles ne se réinitialisent pas automatiquement.

Décision : N’effacez les compteurs qu’après remédiation et documentation. Si CKSUM continue d’augmenter, remplacez/déplacez le périphérique et vérifiez le chemin.

Task 5: Clear errors after you’ve fixed something (not before)

cr0x@server:~$ sudo zpool clear tank sda

Sens : Efface les compteurs d’erreurs pour sda afin que de nouvelles erreurs soient visibles.

Décision : Ne le faites qu’après avoir resserré/remplacé le matériel ; sinon vous supprimez des preuves en plein milieu de l’investigation.

Task 6: List datasets and mountpoints (to find what data might be affected)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME             USED  AVAIL  REFER  MOUNTPOINT
tank             4.12T  2.55T   128K  /tank
tank/vmstore     3.40T  2.55T  3.40T  /tank/vmstore
tank/backups      612G  2.55T   612G  /tank/backups

Sens : Vous pouvez rapidement mapper les problèmes de santé du pool aux datasets impactant le business.

Décision : Si des erreurs permanentes citent un chemin, identifiez le dataset et décidez de restaurer, réhydrater depuis une réplication ou reconstruire des données générées.

Task 7: Find snapshots (useful for rolling back damaged data)

cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/vmstore | tail
tank/vmstore@auto-2025-12-24-0100  Wed Dec 24 01:00 2025
tank/vmstore@auto-2025-12-25-0100  Thu Dec 25 01:00 2025
tank/vmstore@auto-2025-12-26-0100  Fri Dec 26 01:00 2025

Sens : Si la corruption est récente, un snapshot antérieur à l’événement peut être sain.

Décision : Envisagez de cloner et valider avant un rollback. Ne restaurez pas aveuglément un dataset très actif sans coordonner avec les propriétaires applicatifs.

Task 8: Validate pool properties that influence integrity behavior

cr0x@server:~$ zfs get -o name,property,value -s local,default checksum,compression,recordsize tank/vmstore
NAME          PROPERTY     VALUE
tank/vmstore  checksum     on
tank/vmstore  compression  lz4
tank/vmstore  recordsize   128K

Sens : Le checksumming est activé par défaut ; le désactiver est de l’auto‑sabotage.

Décision : Laissez checksum=on. Si vous héritez de propriétés étranges depuis des templates, corrigez‑les avant la production.

Task 9: Look for devices by persistent IDs (avoid “sda roulette”)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|scsi-' | head
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123ABC -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123DEF -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123GHI -> ../../sdc

Sens : Les noms de périphériques comme /dev/sda peuvent changer au redémarrage ; by-id est stable.

Décision : Utilisez les chemins by-id lors de la création des pools et lors du remplacement des périphériques pour éviter de remplacer le mauvais disque (une erreur fréquente et coûteuse).

Task 10: Check SMART health for early warning signs

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       37

Sens : Les secteurs en attente et les erreurs CRC pointent vers des problèmes médias et/ou de câblage. « PASSED » ne signifie pas « sain », cela signifie « pas encore mort ».

Décision : Remplacez le disque si les secteurs en attente persistent ou si les secteurs réalloués augmentent. Si les erreurs CRC montent, remplacez le câble/la baie du backplane et observez si les erreurs s’arrêtent.

Task 11: Confirm the pool isn’t accidentally built on a RAID controller volume

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL
NAME        SIZE TYPE MODEL
sda       7.3T  disk ST8000NM000A
sdb       7.3T  disk ST8000NM000A
sdc       7.3T  disk ST8000NM000A
nvme0n1   1.8T  disk Samsung SSD 990

Sens : Si vous voyez un unique « disque » énorme qui est en réalité un LUN RAID du contrôleur, ZFS ne peut pas voir les disques individuels et ne peut pas
faire une auto‑réparation correcte par périphérique.

Décision : Préférez le mode HBA/JBOD pour ZFS. Si vous êtes déjà déployé sur un LUN RAID, planifiez une migration ; n’attendez pas que le contrôleur devienne votre point unique de regret.

Task 12: Replace a failing disk correctly (mirror example)

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-ST8000NM000A_ZR123ABC /dev/disk/by-id/ata-ST8000NM000A_ZR999XYZ

Sens : ZFS commence la resilverisation vers le nouveau disque.

Décision : Surveillez le resilver. Ne retirez pas l’ancien disque tant que vous ne voyez pas le nouveau en ligne et la progression du resilver.

Task 13: Monitor resilver and interpret “resilvered X” properly

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Fri Dec 26 02:11:05 2025
        842G scanned at 780M/s, 216G issued at 200M/s, 2.90T total
        216G resilvered, 7.43% done, 05:41:32 to go
config:

        NAME                                                   STATE     READ WRITE CKSUM
        tank                                                   ONLINE       0     0     0
          mirror-0                                             ONLINE       0     0     0
            replacing-0                                        ONLINE       0     0     0
              /dev/disk/by-id/ata-ST8000NM000A_ZR123ABC        ONLINE       0     0    24
              /dev/disk/by-id/ata-ST8000NM000A_ZR999XYZ        ONLINE       0     0     0
            sdb                                                ONLINE       0     0     0

Sens : « issued » montre ce qui est écrit ; « scanned » inclut ce qui est vérifié. L’ancien disque conserve l’historique des checksums ; c’est normal.

Décision : Si le resilver ralentit beaucoup, vérifiez la charge I/O, les disques en échec ou un goulot HBA. Si des erreurs de checksum surviennent pendant le resilver, mettez en pause et enquêtez sur le chemin.

Task 14: After resilver, verify no new errors and run a scrub

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 2.90T in 05:55:12 with 0 errors on Fri Dec 26 08:06:17 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdx     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

Sens : Le resilver s’est terminé proprement.

Décision : Lancez un scrub peu après, surtout si l’incident impliquait une instabilité de câblage/contrôleur. Vous voulez de la confiance, pas des impressions.

Task 15: Check ZFS event history for the timeline

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 26 2025 01:18:43.221001000  ereport.fs.zfs.checksum
Dec 26 2025 02:11:05.102334000  sysevent.fs.zfs.resilver_start
Dec 26 2025 08:06:17.552190000  sysevent.fs.zfs.resilver_finish

Sens : Les événements vous disent quand les problèmes de checksum ont commencé et quelle remédiation a eu lieu.

Décision : Utilisez cela pour corréler avec les fenêtres de maintenance, les mises à jour de firmware, les événements d’alimentation ou les pics de charge.

Task 16: Confirm ashift and avoid accidental 512e performance/latency traps

cr0x@server:~$ zdb -C tank | egrep 'ashift|path' | head -n 10
        path: /dev/disk/by-id/ata-ST8000NM000A_ZR123DEF
        ashift: 12
        path: /dev/disk/by-id/ata-ST8000NM000A_ZR123GHI
        ashift: 12

Sens : ashift=12 indique des secteurs 4K. Un ashift incorrect peut provoquer une amplification d’écriture et des timeouts qui ressemblent à des disques instables.

Décision : Si ashift est incorrect sur un pool, planifiez une migration. Vous ne pouvez pas changer ashift en place en toute sécurité dans le cas général.

Trois mini‑histoires d’entreprise depuis le terrain

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

Une entreprise SaaS de taille moyenne faisait tourner un cluster de bases de données sur un stockage « entreprise » : SAN à double contrôleur, RAID6, les acronymes rassurants habituels.
L’hypothèse de l’équipe était simple : RAID6 signifie que la corruption des données est essentiellement gérée. Ils s’intéressaient aux pannes de disque et aux unités de secours, pas à l’intégrité
des données.

Pendant quelques mois, ils ont constaté des bizarreries intermittentes dans les requêtes : un petit sous‑ensemble de lignes échouait aux contrôles applicatifs.
Rien de cohérent. Aucune panne de disque évidente. Le support stockage demandait des logs, l’équipe les collectait, et le problème refusait poliment de se reproduire pendant les heures de bureau.

Le tournant fut un test de restauration (pas pendant une panne — juste un exercice planifié). La base restaurée passait les checksums au niveau base de données pour la plupart des tables, mais quelques index
étaient subtilement corrompus. Les sauvegardes avaient capturé la corruption parce qu’elle existait déjà et était silencieuse.

Ils ont déplacé la charge vers des miroirs ZFS sur serveurs commodity avec mémoire ECC, ont scrubbé chaque semaine et activé des snapshots fréquents. Le plus effrayant n’était pas que RAID ait échoué — il a fait
ce qu’il promettait. La mauvaise hypothèse était de croire que RAID garantissait la correction. RAID promettait « votre volume reste en ligne quand un disque meurt ». Contrat différent.

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

Une autre organisation avait un cluster de virtualisation avec ZFS sur Linux. Les performances étaient correctes, mais quelqu’un voulait « de meilleurs » chiffres : latence plus basse, IOPS plus élevées.
Ils ont ajouté un dispositif L2ARC et ajusté recordsize et cache de façon agressive. Puis ils ont osé : ils ont désactivé les écritures synchrones au niveau du dataset pour le stockage VM parce que « l’onduleur est solide ».

Des mois plus tard, une mise à jour du firmware du contrôleur a déclenché une boucle de reboot inattendue sur un hôte. L’onduleur était bien. L’hôte, non. Après la poussière, plusieurs VMs ne démarraient plus.
ZFS lui‑même restait cohérent — le CoW avait fait son travail — mais les systèmes de fichiers invités avaient perdu des transactions qu’ils pensaient durables.

L’optimisation n’était pas le L2ARC. C’était la décision de mentir sur la durabilité. Désactiver sync, c’est comme enlever la ceinture parce qu’elle froisse votre chemise. C’est joli jusqu’au premier freinage brutal.

Ils ont annulé ce réglage, ajouté un dispositif SLOG approprié pour les charges nécessitant des améliorations de latence sync, et instauré une checklist de revue de changement spécifiquement pour les paramètres de durabilité.
Les performances sont revenues à « assez bonnes », et la correction est redevenue « non négociable ».

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

Un service financier utilisait OpenZFS pour le stockage de documents. Rien de glamour. L’équipe avait trois habitudes ennuyeuses :
scrubs mensuels, tests de restauration trimestriels, et une règle qui déclenchait une inspection physique complète du chemin (disque, baie, backplane, port HBA, câble) dès qu’une erreur de checksum apparaissait.

Un mois, un scrub a signalé une poignée de réparations de checksum sur un membre de miroir. Pas d’interruption, pas de plainte utilisateur. L’ingénieur d’astreinte a ouvert un ticket et suivi la règle : récupérer SMART,
vérifier les CRC, inspecter le câble SAS. SMART montrait des CRC en hausse, mais le disque semblait sinon sain.

Ils ont remplacé le câble et déplacé le disque dans une autre baie. Les erreurs ont cessé. Au cours d’une maintenance planifiée, ils ont découvert que le slot du backplane d’origine avait un contact intermittent sous vibration.

Personne n’a écrit un roman postmortem parce que rien n’est tombé en panne. C’est le but. La pratique ennuyeuse a transformé une histoire « corruption silencieuse un jour » en non‑événement.

Erreurs fréquentes (symptôme → cause → correction)

1) Symptom: CKSUM errors increase, but SMART looks “PASSED”

Cause : L’état global SMART est trop grossier ; les erreurs de checksum indiquent souvent le transport, le firmware ou des écritures mal dirigées, pas seulement un média mourant.

Correction : Vérifiez les attributs SMART (CRC/pending/realloc), changez les câbles, déplacez les baies, mettez à jour le firmware HBA, et remplacez le disque si les erreurs persistent après remédiation du chemin.

2) Symptom: Permanent errors in files after scrub

Cause : ZFS a détecté une corruption mais n’a pas pu réparer parce que la redondance était insuffisante, ou toutes les répliques étaient mauvaises, ou les données corrompues ont été écrasées.

Correction : Restaurez les fichiers affectés depuis une sauvegarde ou un snapshot/réplique propre. Ensuite, examinez pourquoi la redondance n’a pas suffi (vdev disque unique, pool dégradé lors de l’événement, fautes multiples).

3) Symptom: Scrubs take forever and impact performance badly

Cause : I/O sous‑dimensionné, tempêtes de retries de disques en échec, ou conception de pool qui force des lectures larges. Parfois c’est simplement « vous avez construit un pool très occupé et planifié le scrub en heure de pointe ».

Correction : Lancez les scrubs hors‑pic, investiguez les périphériques lents, limitez la priorité scrub/resilver si possible, et considérez plus de vdevs/miroirs pour le parallélisme.

4) Symptom: RAID controller shows healthy, but ZFS inside a VM reports corruption

Cause : ZFS ne voit pas les disques physiques ; il voit un disque virtuel ou un LUN RAID. La corruption peut être introduite sous la couche invitée.

Correction : Préférez le passage d’HBA/disques à ZFS (mode JBOD/HBA) ou exécutez ZFS sur l’hôte. Si vous devez virtualiser, assurez‑vous que la couche inférieure fournit des garanties d’intégrité et des flushs stables.

5) Symptom: After power events, apps complain about lost writes, but ZFS pool is “ONLINE”

Cause : Les écritures sync étaient désactivées, ou les disques/contrôleurs ont menti sur les flush caches, ou la charge attendait une durabilité qui n’était pas fournie.

Correction : Réactivez les sémantiques sync, utilisez un SLOG approprié si nécessaire, et vérifiez les politiques de cache d’écriture. Traitez « accusé mais pas durable » comme une perte de données par conception.

6) Symptom: Repeated errors across multiple disks on the same host

Cause : Défaillance de chemin commun : HBA, expander, backplane, firmware, alimentation, ou instabilité mémoire.

Correction : Déplacez un disque vers un autre chemin contrôleur et observez. Mettez à jour le firmware. Consultez dmesg pour des resets de lien. Validez la santé ECC et exécutez des diagnostics mémoire.

7) Symptom: Replacing a disk doesn’t stop checksum errors

Cause : Vous avez remplacé la victime, pas le coupable. Souvent c’est le câblage, la baie ou le contrôleur, ou le modèle/firmware du disque a un problème connu.

Correction : Changez le câble, changez de baie, mettez à jour le firmware, et si nécessaire remplacez le HBA. Suivez les erreurs par slot physique et par‑id, pas par les noms sda.

Listes de contrôle / plan pas à pas

Checklist de mise en service (avant la production)

1. Utilisez de la mémoire ECC. Si vous ne pouvez pas, reconnaissez au moins le risque explicitement dans la revue d’architecture.
2. Utilisez des HBAs en mode IT/JBOD, pas des volumes RAID matériels, afin que ZFS voit et gère directement les disques.
3. Construisez les pools avec des chemins de périphériques persistants (/dev/disk/by-id).
4. Choisissez une redondance adaptée au rayon d’impact : miroirs pour IOPS et resilver rapide ; RAIDZ pour capacité avec des attentes réalistes de reconstruction.
5. Définissez et documentez un calendrier de scrub (commun : mensuel pour grands pools, plus fréquent pour données critiques).
6. Activez snapshots et réplication ; décidez de la rétention selon les objectifs de récupération, pas selon l’optimisme.
7. Testez la restauration de datasets représentatifs avant le passage en production.

Checklist d’hygiène opérationnelle (hebdo/mensuel)

1. Revue de zpool status sur les flottes ; alertez sur READ/WRITE/CKSUM non nuls.
2. Vérifiez les attributs SMART pour les tendances, pas seulement les drapeaux de défaillance.
3. Exécutez des scrubs planifiés ; vérifiez qu’ils se terminent et s’ils ont réparé quelque chose.
4. Suivez les temps de resilver ; l’allongement est un signal précoce de vieillissement des disques ou d’une conception surchargée.
5. Réalisez un test de restauration trimestriel. Choisissez des échantillons aléatoires et vérifiez réellement l’intégrité au niveau applicatif.

Plan de réponse à incident (erreurs de checksum détectées)

1. Geler les changements risqués. Arrêtez les « reboots utiles » et les mises à jour de firmware pendant l’incident.
2. Exécuter zpool status -v et capturer la sortie pour le ticket.
3. Si la redondance existe, lancez un scrub et surveillez les réparations et nouvelles erreurs.
4. Inspecter SMART et dmesg pour des resets de lien et des erreurs CRC ; échangez câbles/baies si indiqué.
5. Remplacez les périphériques qui continuent d’accumuler des erreurs. Utilisez zpool replace avec des chemins by-id.
6. Après remédiation, effacez les compteurs, scrubez à nouveau et confirmez la stabilité sur au moins un cycle complet de scrub.
7. Restaurez les fichiers/VMs affectés depuis snapshots ou sauvegardes ; validez au niveau applicatif.
8. Notez ce qui a été remplacé (numéro de série du disque, baie, câble) pour que le prochain ingénieur n’ait pas à répéter la même danse.

FAQ

ZFS empêche‑t‑il toute corruption ?

Non. ZFS détecte la corruption sur disque et les corruptions sur le chemin I/O après

Si j’ai déjà du RAID, ai‑je encore besoin de ZFS ?

Si votre priorité est la correction, vous avez besoin d’une couche d’intégrité de bout en bout quelque part. ZFS la fournit au niveau filesystem+volume. RAID fournit la redondance des périphériques.
Les combiner est généralement redondant dans le mauvais sens (complexité) sauf si vous utilisez le RAID comme simple abstraction JBOD — mieux vaut alors le remplacer par le mode HBA.

Pourquoi ZFS signale‑t‑il des erreurs de checksum quand le disque dit que tout va bien ?

Parce que le disque peut renvoyer de mauvaises données sans signaler d’erreur (bugs firmware, lectures mal dirigées, corruption du transport). ZFS valide le contenu, pas la confiance du périphérique.

Quelle est la différence entre READ errors et CKSUM errors dans zpool status ?

Les READ errors signifient que le périphérique n’a pas pu fournir les données (échec I/O). Les CKSUM errors signifient qu’il a renvoyé des données, mais que celles‑ci ne correspondaient pas à la checksum attendue.
CKSUM est souvent plus alarmant car cela implique une corruption silencieuse.

À quelle fréquence dois‑je lancer un scrub ?

Mensuel est une base commune pour des pools multi‑to. Plus fréquent pour les données critiques ou du matériel moins fiable. La bonne réponse : assez souvent pour que les erreurs latentes soient trouvées
tant que la redondance existe encore et avant que les sauvegardes ne deviennent obsolètes.

Un scrub réparera‑t‑il la corruption ?

Si vous avez de la redondance et au moins une bonne copie, oui — ZFS peut s’auto‑guérir lors d’un scrub. Si vous avez un vdev sur disque unique, le scrub détecte la corruption mais ne peut pas la réparer.
Si toutes les copies sont mauvaises, il faudra restaurer depuis une sauvegarde dans tous les cas.

Les miroirs sont‑ils plus sûrs que RAIDZ ?

Les miroirs résilverisent généralement plus vite et sont opérationnellement plus simples ; ils offrent aussi de meilleures IOPS lectures aléatoires. RAIDZ est plus efficace en capacité mais peut avoir des fenêtres de reconstruction plus longues et des domaines de faute plus larges.
« Plus sûr » dépend de la charge, de la taille des disques et de la discipline opérationnelle. Si vous ne scrubez pas régulièrement, aucun des deux n’est sûr.

Puis‑je exécuter ZFS au sommet d’un volume RAID matériel ?

Vous le pouvez, mais vous aveuglez ZFS sur le comportement des disques physiques et poussez la confiance vers le contrôleur RAID. Vous perdez une partie de la capacité de ZFS à localiser les fautes et à s’auto‑réparer
au bon niveau. Si vous tenez à l’intégrité, donnez à ZFS un accès direct aux disques.

Que faire quand ZFS signale « Permanent errors » ?

Traitez cela comme une perte de données pour le(s) fichier(s) référencé(s). Restaurez depuis une sauvegarde ou un snapshot/réplique propre, corrigez ensuite le problème matériel/chemin sous‑jacente et scrubez à nouveau.
Ne supposez pas « il s’est guéri » si le message indique permanent.

La compression ou le recordsize affectent‑ils la détection de corruption ?

Le checksumming fonctionne toujours. La compression change les blocs physiques écrits, mais ils sont toujours checkés. Le recordsize affecte les patterns I/O et le comportement de reconstruction, ce qui peut influer
sur la rapidité à laquelle vous remarquez les problèmes et sur la pénibilité des scrubs/resilvers.

Prochaines étapes pratiques

Si vous utilisez RAID et pensez être « couvert », décidez de ce que vous entendez réellement : disponibilité ou correction. Si vous entendez correction, ajoutez une couche d’intégrité de bout en bout.
ZFS est l’un des rares à le faire de façon complète et opérationnelle.

1. Activez (et surveillez réellement) les scrubs ZFS. Mettez‑les au calendrier et alertez sur les réparations et erreurs.
2. Concevez la redondance de manière à pouvoir guérir : miroirs ou RAIDZ/dRAID avec des fenêtres de reconstruction réalistes.
3. Utilisez de la mémoire ECC et des HBAs en mode JBOD/IT pour que ZFS voie les vrais disques.
4. Quand des erreurs de checksum apparaissent, ne discutez pas avec elles. Localisez le chemin, remplacez ce qui est coupable, scrubez à nouveau et restaurez les données affectées.
5. Validez les sauvegardes en restaurations. La corruption déjà présente dans la source se propagera volontiers dans des sauvegardes « parfaitement réussies ».

Le gain opérationnel est simple : ZFS transforme la corruption silencieuse en corruption bruyante. Les problèmes bruyants sont corrigés. Les silencieux deviennent des incidents.