Erreurs d’écriture ZFS : le schéma de panne qui prédit une mise hors ligne

Le schéma : pourquoi les erreurs d’écriture prédisent les mises hors ligne

Dans l’univers ZFS, les erreurs de checksum attirent l’attention. Elles sonnent effrayant et « corruption de données ».
Mais quand vous essayez de prédire le prochain événement de panne — celui qui éjecte un périphérique du pool —
les erreurs d’écriture sont le meilleur canari.

Voici le schéma de panne qui réapparaît encore et encore en production :

1. De petites erreurs d’écriture intermittentes s’accumulent sur un périphérique. Le pool peut rester ONLINE.
   Souvent c’est un nombre à un chiffre qui ne change pas pendant des jours, puis qui augmente soudainement.
2. Des pics de latence corrèlent avec des réinitialisations de liaison (SATA/SAS), des blocages de file d’attente HBA ou des micro-comportements de firmware.
   Vos applications le ressentent avant vous — sauf si vous surveillez les bonnes métriques.
3. Les logs du noyau montrent du drame au niveau du transport : timeouts, resets, « device offline », « rejecting I/O ».
   ZFS enregistre la conséquence : des I/O d’écriture qui n’ont pas été complétées avec succès.
4. Un scrub ne « répare » pas les erreurs d’écriture. Les scrubs valident et réparent les données via la redondance.
   Ils ne réparent pas un chemin de transport ni un canal d’écriture mourant.
5. Le périphérique tombe pendant une période de charge : un resilver, un envoi de snapshot, une fenêtre de sauvegarde, ou un lundi chargé.
   Le pool se dégrade et l’incident commence à vous coûter.

L’idée clé : les erreurs d’écriture ne sont souvent pas des « mauvais blocs » au départ. Elles sont fréquemment
des échecs au niveau du chemin — contrôleur, câblage, expander, backplane, alimentation ou firmware.
ZFS rapporte « j’ai essayé d’écrire, et la pile en dessous n’a pas livré ».

Si vous traitez cela comme un compteur cosmétique et passez à autre chose, vous misez votre disponibilité sur le fait que le même chemin instable
se comportera mieux demain sous une charge plus élevée. Ce n’est pas du courage ; c’est du pari.

Une citation qui tient encore en opération : L’espoir n’est pas une stratégie — souvent attribuée à Vince Lombardi.

Blague n°1 : Les disques ne « tombent pas partiellement » pour être polis. Ils le font pour s’assurer que votre panne tienne dans une réunion calendrier.

Faits et contexte historique utiles à connaître

• ZFS est né chez Sun au milieu des années 2000 avec le checksum de bout en bout comme idée fondamentale, pas comme greffon.
• Les compteurs d’erreurs ZFS sont des stats par périphérique vdev maintenues par le pool ; ils persistent après reboot dans de nombreuses implémentations.
• Le SATA précoce était rugueux dans les baies d’entreprise : timeouts, mauvais comportement TLER et gestion de lien fragile ont appris à respecter les erreurs de transport.
• SMART et ZFS voient des mondes différents : SMART rapporte souvent la « santé du disque » tandis que ZFS rapporte la « réalité des I/O », et ces deux visions peuvent diverger pendant des semaines.
• Les échecs d’écriture sont plus « visibles » que les lectures parce que des lectures réussies peuvent être servies depuis l’ARC/L2ARC, masquant les problèmes jusqu’aux cache-misses.
• Des bugs de firmware d’expander et de backplane ont causé de vraies pannes en émettant des resets sous charge, entraînant des erreurs d’écriture en rafales et des périphériques hors ligne.
• Les scrubs ZFS ne sont pas un fsck : ils vérifient les blocs et réparent à partir de la redondance, mais ils ne réparent pas des périphériques instables ou des HBAs défaillants.
• Le comportement du resilver a évolué : le « resilver séquentiel » et les améliorations d’OpenZFS ont réduit la douleur, mais les resilvers amplifient toujours les liens faibles.
• Une mauvaise ashift reste pour toujours : un alignement de secteur incorrect n’entraîne pas directement des erreurs d’écriture, mais il augmente l’amplification des écritures, poussant du matériel marginal au-delà de ses limites.

Ce que signifient réellement les « write errors » dans ZFS

Les trois compteurs : READ, WRITE, CKSUM

zpool status affiche typiquement trois nombres par périphérique : READ, WRITE, et CKSUM.
Ils ne sont pas interchangeables et n’impliquent pas la même couche.

• READ errors : le périphérique/chemin n’a pas renvoyé de données quand on le lui a demandé.
  Cela peut être une défaillance média, un timeout de transport ou « device not ready ».
• WRITE errors : le périphérique/chemin n’a pas persisté les données quand on le lui a demandé.
  C’est couramment un problème de transport ou de firmware du périphérique, parfois lié à l’alimentation.
• CKSUM errors : les données sont revenues mais ne correspondaient pas à leur checksum.
  Cela indique souvent une corruption en transit (câble, contrôleur, RAM) ou un média qui renvoie de mauvaises données.

Pourquoi les erreurs d’écriture prédisent une mise hors ligne

Un périphérique qui ne peut pas compléter de façon fiable les écritures a tendance à être expulsé par la pile OS en premier.
La plupart des HBA et pilotes ont un budget de patience. Sous charge, ce budget est consommé plus vite.
Quand des timeouts s’accumulent, le contrôleur réinitialise le lien. ZFS voit un I/O d’écriture échouer.
Assez de ces échecs et le périphérique devient effectivement peu fiable même s’il « revient ».

Ce que les erreurs d’écriture ne sont pas

Elles ne signifient pas automatiquement « perte de données ». Si le pool a de la redondance (mirror/RAIDZ) et qu’une écriture a échoué d’un côté,
ZFS peut encore compléter le groupe de transactions en toute sécurité, selon ce qui a échoué et quand.

Elles ne signifient pas automatiquement « le disque meurt ». Un pourcentage surprenant d’erreurs d’écriture sur le terrain provient
du câblage, des expanders, des HBAs, du backplane ou de l’alimentation. Le disque n’est que le messager — et nous savons tous ce que font les organisations aux messagers.

La chorégraphie de la mise hors ligne (ce que vous verrez)

La séquence classique pour un problème de chemin SATA/SAS est :
timeouts → reset de lien M:N → I/O en file supprimées → ZFS logge des erreurs d’écriture → device marqué FAULTED ou REMOVED → resilver commence.

Plus votre système « essaie d’aider » en tentant de récupérer les liens (tempêtes de reset), plus la latence devient chaotique.
Les applications se moquent que le périphérique soit revenu. Elles se soucient que la latence au 99e centile ait déménagé dans un autre pays.

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

L’objectif dans les 15 premières minutes n’est pas de tenir un séminaire philosophique sur le stockage.
C’est de répondre à trois questions :
Les données sont-elles sûres maintenant ? Quelle est la couche en défaut ? Quelle action réduit le risque le plus vite ?

Premier : confirmer l’état du pool et le rayon d’impact

• Lancez zpool status -v. Identifiez le vdev et le chemin de périphérique exact qui rapporte des erreurs d’écriture.
• Vérifiez si la redondance est intacte (le mirror a un autre côté ONLINE, le RAIDZ a assez de parité).
• Recherchez un resilver/scrub en cours. Ceux-ci amplifient le matériel faible et modifient le profil de risque pour les 30 prochaines minutes.

Deuxième : corréler avec les logs noyau transport

• Cherchez dans dmesg / journalctl -k les resets, timeouts, « rejecting I/O », « device offline », réinitialisations SAS phy.
• Si les logs hurlent « link reset », arrêtez de débattre. Traitez-le comme un problème de chemin jusqu’à preuve du contraire.

Troisième : vérifier l’identité du périphérique et SMART, puis décider remplacement vs réparation du chemin

• Mappez le périphérique ZFS au nœud /dev et à l’emplacement physique (utilisez zpool status, ls -l /dev/disk/by-id, outils d’armoire si disponibles).
• Lancez smartctl et cherchez les secteurs réalloués/pending, les erreurs UDMA CRC, les timeouts de commande et les entrées du journal SMART.
• Si SMART est propre mais que dmesg montre des resets : suspectez le câble/HBA/backplane/alimentation avant de changer le disque.

Règle de décision qui vous garde employable

Si les erreurs d’écriture augmentent et que vous voyez des resets de transport dans la même fenêtre, priorisez la stabilisation du chemin.
Si vous ne pouvez pas stabiliser le chemin rapidement, remplacez le composant le plus susceptible d’être intermittent (câble/port backplane),
et si la plateforme est « boîte noire », remplacez aussi le disque. La main d’œuvre coûte ; l’indisponibilité est pire.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont les tâches que j’exécute réellement. Chacune inclut ce que la sortie signifie et quelle décision elle entraîne.
Les commandes sont montrées pour un hôte Linux OpenZFS typique ; adaptez les noms de périphériques à votre environnement.

Task 1: Get the truth from ZFS

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
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 02:41:10 with 0 errors on Tue Dec 24 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     7     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/vm-104.img

Signification : Un disque affiche WRITE=7. Le pool est DEGRADED et ZFS rapporte un fichier avec des erreurs permanentes.
Ce n’est pas « peut-être ». Quelque chose a déjà échoué à écrire correctement ou n’a pas pu être engagé.

Décision : Traitez cela comme un incident actif. Identifiez si l’erreur est isolée et récupérable par la redondance/la sauvegarde.
Lancez aussi immédiatement l’enquête sur le transport ; le compteur WRITE est un indicateur précoce d’une mise hors ligne.

Task 2: Verify the exact device path(s) ZFS is using

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

        NAME                                      STATE  READ WRITE CKSUM
        tank                                      DEGRADED 0    0     0
          raidz1-0                                DEGRADED 0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_A1   ONLINE  0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_B2   ONLINE  0    7     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_C3   ONLINE  0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_D4   ONLINE  0    0     0

Signification : Vous avez maintenant des identifiants stables. Si votre pool utilise des noms /dev/sdX, corrigez cela plus tard.

Décision : Utilisez le chemin by-id pour SMART et pour localiser le disque physique. Ne faites pas confiance à l’ordre /dev/sdX après des resets.

Task 3: Check whether errors are still increasing

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

        NAME                        STATE  READ WRITE CKSUM
        tank                        DEGRADED 0    0     0
          raidz1-0                  DEGRADED 0    0     0
            ata-WDC_WD80EFAX_A1     ONLINE  0    0     0
            ata-WDC_WD80EFAX_B2     ONLINE  0    9     0
            ata-WDC_WD80EFAX_C3     ONLINE  0    0     0
            ata-WDC_WD80EFAX_D4     ONLINE  0    0     0

Signification : WRITE est passé de 7 à 9. Le problème est en cours.

Décision : Arrêtez le « attendre et voir ». Retirez la charge, migrez les workloads ou orientez-vous vers un remplacement / une réparation du chemin maintenant.

Task 4: Pull kernel logs for transport resets/timeouts

cr0x@server:~$ sudo journalctl -k --since "30 min ago" | egrep -i "ata|sas|scsi|reset|timeout|offline|aborted" | tail -n 20
Dec 25 01:43:11 server kernel: ata8.00: failed command: WRITE FPDMA QUEUED
Dec 25 01:43:11 server kernel: ata8.00: cmd 61/00:08:10:3c:2a/04:00:00:00:00/40 tag 1 ncq dma 524288 out
Dec 25 01:43:11 server kernel: ata8.00: status: { DRDY ERR }
Dec 25 01:43:11 server kernel: ata8.00: error: { ICRC ABRT }
Dec 25 01:43:12 server kernel: ata8: hard resetting link
Dec 25 01:43:17 server kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 25 01:43:17 server kernel: ata8.00: configured for UDMA/133

Signification : Les erreurs ICRC et les resets de lien sont des classiques de câbles/backplane/connecteurs défectueux (ou parfois du contrôleur).
Ce n’est pas que ZFS « soit pointilleux ». Le transport flanche.

Décision : Traitez d’abord comme un problème de chemin. Rebranchez/remplacez le câble, vérifiez le port du backplane, inspectez l’alimentation, envisagez le firmware/le pilote HBA.
Si c’est une baie hot-swap, déplacez le disque dans un autre emplacement si possible.

Task 5: Map the device to a kernel node and verify it’s stable

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX_B2
lrwxrwxrwx 1 root root 9 Dec 25 01:10 /dev/disk/by-id/ata-WDC_WD80EFAX_B2 -> ../../sdg

Signification : Le disque est actuellement /dev/sdg. Après des resets, il peut devenir sdf ou sdh.

Décision : Utilisez /dev/disk/by-id/... pour toutes les actions, pas /dev/sdg.

Task 6: Pull SMART health and error log

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Model|Serial|Power_On_Hours|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Error|SMART overall"
Model Family:     Western Digital Red
Device Model:     WDC WD80EFAX-68KNBN0
Serial Number:    XXXXXXXXXXXX
SMART overall-health self-assessment test result: PASSED
Power_On_Hours:   23144
Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0
UDMA_CRC_Error_Count: 27
SMART Error Log Version: 1
ATA Error Count: 14

Signification : Le média semble propre (pas de réallocations/pending), mais des erreurs CRC existent. Les erreurs CRC corrèlent fortement avec des problèmes de câblage/backplane.

Décision : Remplacez / rebranchez les éléments du chemin SATA/SAS. Si les CRC continuent d’augmenter ensuite, remplacez le disque ou l’HBA.

Task 7: Check whether ZFS thinks this is a transient I/O issue or permanent corruption

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,120p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
config:
...
errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/vm-104.img

Signification : « Permanent errors » signifie que ZFS n’a pas pu auto-réparer ce bloc à partir de la redondance au moment de la détection.
Cela a pu se produire pendant une écriture où la parité n’a pas pu être mise à jour en toute sécurité, ou la redondance était insuffisante/compromise.

Décision : Restaurer ce fichier/objet depuis une source connue bonne. Pour les images VM, cela signifie généralement restaurer depuis une sauvegarde ou une réplique.
Ne prétendez pas qu’un scrub fera revenir des données saines manquantes.

Task 8: Identify if a scrub or resilver is in progress (and how painful it is)

cr0x@server:~$ sudo zpool status tank | egrep -i "scan|resilver|scrub|repaired|errors"
  scan: resilver in progress since Wed Dec 25 01:21:34 2025
        1.18T scanned at 802M/s, 312G issued at 210M/s, 8.34T total
        78.1G resilvered, 3.65% done, 10:44:12 to go
errors: No known data errors

Signification : Un resilver est en cours. C’est une I/O soutenue importante et un excellent moyen de déclencher des liens marginaux.

Décision : Envisagez de réduire temporairement la charge (brider les workloads, ajuster zfs_resilver_delay si approprié),
ou planifiez le travail intensif pendant la fenêtre de risque la plus basse. Si le chemin est instable, le resilver peut ne jamais finir proprement.

Task 9: Confirm ashift and vdev layout (to understand stress and rebuild behavior)

cr0x@server:~$ sudo zdb -C tank | egrep -i "ashift|raidz|mirror|vdev" | head -n 30
            raidz
                ashift: 12
                nparity: 1
                children[0]:
                children[1]:
                children[2]:
                children[3]:

Signification : ashift 12 correspond à des secteurs 4K. Bien. Si vous voyez ashift 9 sur des disques modernes, vous amplifiez les écritures.

Décision : Si ashift est incorrect, planifiez une reconstruction/migration. Ne « tuninguez » pas autour d’une erreur structurelle en poursuivant des erreurs d’écriture.

Task 10: Check ARC pressure and memory errors (because bad RAM can mimic disk problems)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "size|c_max|memory_throttle_count|arc_no_grow" | head
size                            4    8589934592
c_max                           4    17179869184
memory_throttle_count           4    0
arc_no_grow                     4    0

Signification : L’ARC ne bride pas en raison de la pression mémoire. Cela ne certifie pas l’absence d’erreur RAM, mais écarte un scénario courant « le système meurt ».

Décision : Si vous suspectez la mémoire, vérifiez les logs ECC (mcelog/rasdaemon) et lancez un test de maintenance.
Ne remplacez pas des disques pour corriger une corruption RAM.

Task 11: Inspect I/O error stats at the block layer

cr0x@server:~$ iostat -x 1 5 /dev/sdg
Linux 6.5.0 (server)  12/25/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.10    0.00    1.20   12.40    0.00   83.30

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sdg              0.10  220.00     1.2  28160.0  85.40   4.10  90.20

Signification : Un await élevé avec une forte utilisation peut être « normal sous resilver », ou être des retries répétées dues à des problèmes de transport.
Vous devez corréler avec les logs noyau.

Décision : Si les pics d’await s’alignent avec des resets/timeouts dans les logs, escaladez la remédiation du chemin. Sinon, cela peut être attendu pendant une reconstruction,
et vous pouvez gérer en bridant plutôt qu’en remplaçant immédiatement le matériel.

Task 12: Confirm HBA driver/firmware class and queue behavior

cr0x@server:~$ lspci -nn | egrep -i "SAS|RAID|HBA"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097]

cr0x@server:~$ modinfo mpt3sas | egrep -i "version|firmware|srcversion" | head -n 10
version:        47.00.00.00
srcversion:     9F6C3D0F5E4D2C3A2E3A1B2

Signification : Vous êtes sur une pile HBA LSI/Broadcom SAS3. Bon — généralement solide, parfois pointilleuse sur le firmware.

Décision : Si de nombreux disques montrent des erreurs d’écriture intermittentes, suspectez HBA/expander/firmware. Un seul disque ? Suspectez la voie/slot/câble/disque.

Task 13: Check for wide impact—errors across multiple devices

cr0x@server:~$ sudo zpool status tank | awk 'BEGIN{p=0} /config:/{p=1} p && $1 ~ /(ata-|scsi-|nvme|\/dev\/disk)/ {print}'
tank                        DEGRADED 0 0 0
raidz1-0                    DEGRADED 0 0 0
ata-WDC_WD80EFAX_A1         ONLINE  0 0 0
ata-WDC_WD80EFAX_B2         ONLINE  0 9 0
ata-WDC_WD80EFAX_C3         ONLINE  0 0 0
ata-WDC_WD80EFAX_D4         ONLINE  0 0 0

Signification : Un seul périphérique accumule des erreurs d’écriture. Cela réduit la suspicion d’un composant global — mais ne l’élimine pas.
Un port défectueux sur un backplane est toujours un « composant global » déguisé.

Décision : Concentrez l’inspection physique sur ce slot/câble/chemin en premier. Si plusieurs périphériques affichent des erreurs READ/WRITE, élargissez à l’HBA/expander/alimentation.

Task 14: Force a controlled SMART self-test during maintenance (not during peak I/O)

cr0x@server:~$ sudo smartctl -t short /dev/sdg
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Self-test execution status|# 1|Completed"
Self-test execution status:      (  0) The previous self-test routine completed without error.
# 1  Short offline       Completed without error       00%     23145         -

Signification : Le test court réussit ; cela ne garantit pas la tenue du disque sur des écritures soutenues sous charge, mais c’est un point de données.

Décision : Si les erreurs de transport persistent, un test SMART passant n’innocente pas le chemin. Continuez à poursuivre les resets et les compteurs CRC.

Task 15: Clear counters the right way (and only after fixing the cause)

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

        NAME                        STATE  READ WRITE CKSUM
        tank                        DEGRADED 0 0 0
          raidz1-0                  DEGRADED 0 0 0
            ata-WDC_WD80EFAX_A1     ONLINE  0 0 0
            ata-WDC_WD80EFAX_B2     ONLINE  0 0 0
            ata-WDC_WD80EFAX_C3     ONLINE  0 0 0
            ata-WDC_WD80EFAX_D4     ONLINE  0 0 0

Signification : Les compteurs sont effacés. Cela ne répare rien ; cela vous donne juste une feuille propre pour voir si le problème réapparaît.

Décision : Effacez uniquement après remédiation (rebranchement du câble, déplacement de slot, mise à jour firmware, remplacement du disque), puis surveillez la récurrence.
Si les compteurs remontent, vous avez une preuve — pas juste des impressions.

Task 16: Controlled write test on a non-production spare (never the live vdev)

cr0x@server:~$ sudo fio --name=writecheck --filename=/mnt/testdisk/fio.dat --rw=write --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=120 --time_based=1
writecheck: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
writecheck: (groupid=0, jobs=1): err= 0: pid=25191: Wed Dec 25 01:58:23 2025
  write: IOPS=210, BW=210MiB/s (220MB/s)(25.2GiB/123000msec)
    clat (usec): min=950, max=420000, avg=7700.12, stdev=9500.10

Signification : C’est un test d’écriture soutenue basique. Il peut exposer des resets de transport lorsqu’il est couplé à la surveillance des logs.

Décision : Si les logs noyau montrent des resets pendant un simple run fio, vous avez reproduit le problème dans des conditions contrôlées.
Réparez le chemin. Ne blâmez pas ZFS pour le signalement.

Trois mini-récits d’entreprise tirés du réel

1) Incident causé par une mauvaise hypothèse : « SMART passé, donc le disque est sain »

Un SaaS de taille moyenne exploitait un cluster VM sur ZFS. Un hôte a commencé à rapporter quelques erreurs d’écriture sur un disque.
L’ingénieur on-call a fait le geste classique : smartctl indiquait « PASSED », pas de réallocations, pas de secteurs pending.
Ils ont effacé les erreurs du pool et sont passés à autre chose.

Deux jours plus tard, pendant la fenêtre de sauvegarde, le même disque est tombé hors ligne. Le pool s’est dégradé, le resilver a commencé, et
la latence de l’hôte est passée de « correcte » à « apocalypse helpdesk ». L’on-call a vu des resets de lien SATA dans les logs
mais a supposé que c’était un effet secondaire du resilver plutôt que la cause.

Un SRE senior a finalement regardé les attributs SMART à nouveau — spécifiquement les compteurs d’erreur d’interface.
Les erreurs UDMA CRC avaient augmenté régulièrement. Le disque ne ratait pas le stockage des données ; il ratait la communication fiable.
Le résumé santé « passed » était techniquement correct et opérationnellement inutile.

La réparation a été embarrassante, comme le sont souvent les bonnes réparations : remplacer un seul câble SATA et déplacer le disque vers un autre port backplane.
Les erreurs ont cessé. Le resilver s’est terminé. Plus de mises hors ligne.

La mauvaise hypothèse n’était pas que SMART ment. L’hypothèse était que SMART est la vérité primaire.
Dans les incidents ZFS, la vérité primaire est « quelles I/O le système n’a pas réussi à compléter », et ZFS est plus proche de cette vérité que le résumé marketing du disque.

2) Optimisation qui s’est retournée contre eux : « Plus de débit » par tuning agressif

Une autre entreprise possédait un nœud de stockage qui paraissait sous-dimensionné sur le papier : beaucoup de disques, une base de données très active, et une équipe allergique à l’achat de matériel.
Ils ont fait ce que font les ingénieurs quand l’approvisionnement dit non : du tuning.

Ils ont augmenté recordsize sans comprendre le profil I/O, modifié les paramètres de sync au nom du débit,
et augmenté les profondeurs de queue dans la pile du contrôleur pour « occuper les disques ». Les benchmarks se sont améliorés. Des slides ont été préparées.
En production, évidemment, cela a fait autre chose.

Sous pic de charge, le système a commencé à accumuler des erreurs d’écriture sur deux disques derrière le même expander.
Les logs noyau ont montré des timeouts et des resets. Le tuning avait augmenté la durée et la rafale des écritures, étirant
la tolérance de l’expander et amplifiant tout petit problème d’intégrité du signal. Le système n’a pas échoué immédiatement ; il a échoué de façon intermittente,
ce qui est le pire car cela gaspille le temps de tout le monde.

Ils ont annulé la plupart des réglages et remplacé un module expander/backplane marginal.
Le débit a un peu diminué, la latence extrême s’est beaucoup améliorée, et les erreurs d’écriture ont disparu.
L’équipe a appris la leçon que personne ne veut apprendre : un chemin plus rapide vers la panne reste un chemin vers la panne.

Blague n°2 : « On l’a optimisé pour la performance » est parfois juste une façon élégante de dire « on a rendu l’incident futur plus efficace ».

3) Pratique ennuyeuse mais correcte qui a sauvé la situation : discipline sur le nommage et remplacements planifiés

Une organisation financière exploitait OpenZFS sur Linux pour des services de fichiers internes. Pas glamour, mais ils le traitaient comme un vrai système :
noms de périphériques stables by-id dans les pools, sleds étiquetés, cartes de slots documentées, et une politique stricte où personne ne hot-swap rien
sans une seconde personne vérifiant le numéro de série.

Un après-midi, des erreurs d’écriture sont apparues sur un seul membre vdev. L’on-call a lancé zpool status -P,
a confirmé le chemin by-id, l’a mappé à un emplacement physique, et a vérifié les logs : réinitialisations intermittentes sur une phy.
Ils ont ouvert un ticket auprès des facilities pour une fenêtre de maintenance planifiée et ont pré-positionné un câble de remplacement et un disque de secours.

Pendant la fenêtre, ils ont déplacé le disque vers un nouveau slot et remplacé le câble. Ils ont effacé les erreurs et lancé un scrub.
Pas de récidive. Ils n’ont même pas eu besoin du disque de secours, mais l’avoir sous la main a évité le piège « on le commande et on attend ».

Personne n’a reçu de prix pour cela. C’est le but. Les pratiques ennuyeuses — nommage stable, étiquetage physique, contrôle des changements — ont transformé une panne probable
en une tâche de maintenance routinière.

Erreurs courantes : symptôme → cause racine → correction

1) « WRITE errors sur un disque, SMART indique PASSED »

Symptôme : ZFS affiche des erreurs d’écriture ; SMART overall-health est « PASSED », les attributs média semblent propres.

Cause racine : Instabilité du transport (CRC, resets de lien), port de backplane, câble, voie d’expander, ou accroc HBA.

Correction : Vérifiez les logs noyau pour des resets ; inspectez/remplacez le câble ; déplacez le disque vers un autre slot ; mettez à jour le firmware HBA/expander ; seulement ensuite envisagez le remplacement du disque.

2) « Le scrub a fini propre, mais les WRITE continuent d’augmenter »

Symptôme : Le scrub indique 0 erreurs, pourtant le compteur WRITE s’incrémente.

Cause racine : Le scrub est orienté lecture ; votre problème se situe sur les écritures (ou resets pendant les écritures). Le scrub ne valide pas le chemin d’écriture sous votre charge réelle.

Correction : Corrélez avec les périodes à forte écriture ; reproduisez avec des écritures contrôlées hors pointe ; stabilisez le chemin.

3) « Plusieurs disques affichent soudainement des WRITE »

Symptôme : Plusieurs membres vdev reçoivent des erreurs d’écriture en quelques minutes/heures.

Cause racine : Défaillance d’un composant partagé (HBA, expander, alimentation backplane, problèmes PCIe, bug firmware).

Correction : Arrêtez de remplacer des disques comme un rituel. Inspectez le matériel partagé, vérifiez les logs PCIe AER, revoyez les changements de firmware/noyau récents, et envisagez un rollback.

4) « Le périphérique tombe et revient ; le pool oscille »

Symptôme : Le disque passe FAULTED/REMOVED puis revient ONLINE après des resets.

Cause racine : Instabilité de lien ou intermittence d’alimentation, parfois un rail PSU marginal vers le backplane.

Correction : Traitez le flapping comme urgent. Remplacez câble/slot/backplane ; vérifiez les connecteurs d’alimentation ; confirmez la santé du PSU et la distribution sur le backplane.

5) « WRITE errors après changement des réglages de sync »

Symptôme : Après tuning de performance, des erreurs d’écriture apparaissent sous charge maximale.

Cause racine : Le tuning a augmenté la rafale/queue depth d’écriture, exposant des faiblesses du contrôleur/expander.

Correction : Revenez sur les réglages ; retestez ; ajoutez un SLOG seulement si vous comprenez le workload sync et que vous disposez de périphériques de qualité entreprise.

6) « Erreurs permanentes dans des fichiers malgré la redondance »

Symptôme : ZFS signale des erreurs permanentes pour des fichiers spécifiques.

Cause racine : Au moment de l’événement, la redondance n’a pas fourni une bonne copie (erreurs multiples, écritures partielles, ou dommage silencieux antérieur).

Correction : Restaurer depuis sauvegarde/réplica ; puis enquêter pourquoi la redondance n’a pas suffi (second périphérique défaillant, chemin instable, mauvaise configuration).

7) « Le resilver ne se termine jamais ; les erreurs persistent »

Symptôme : Le resilver ralentit ou redémarre ; les erreurs d’écriture/lecture continuent.

Cause racine : La charge de reconstruction déclenche la panne à répétition. C’est courant avec des câbles marginaux, des expanders ou des HBAs en surchauffe.

Correction : Réduisez la charge, améliorez le refroidissement, remplacez le composant de chemin suspect, et seulement ensuite relancez le resilver.

Checklists / plan étape par étape

Confinement immédiat (0–30 minutes)

1. Lancez zpool status -v et capturez la sortie dans les notes d’incident.
2. Identifiez si la redondance est intacte. Sinon, passez en mode protection des données : stoppez les écritures, snapshottez ce que vous pouvez, préparez la restauration.
3. Vérifiez si un scrub/resilver est actif. Si un resilver tourne, attendez-vous à ce que le système soit fragile.
4. Extraites les logs noyau pour resets/timeouts. Les erreurs de transport déplacent votre priorité de « santé du disque » à « stabilité du chemin ».
5. Mappez le périphérique au by-id et à l’emplacement physique. Ne touchez pas au matériel avant de savoir exactement ce que vous retirez.

Isolation de la cause racine (même journée)

1. Comparez les compteurs ZFS sur tous les périphériques. Un périphérique : probablement local. Plusieurs périphériques : composant partagé probable.
2. Vérifiez les attributs SMART qui indiquent des problèmes de chemin (CRC, timeouts de commande), pas seulement les secteurs réalloués.
3. Inspectez/rebranchez/remplacez le câble ; déplacez le disque vers un autre slot si le châssis le permet.
4. Revoyez les firmwares HBA/expander et les mises à jour du noyau récentes ; une régression est possible.
5. Effacez les erreurs ZFS seulement après remédiation pour confirmer si le problème récidive.

Récupération et validation (après intervention matérielle)

1. Si un disque a été remplacé, laissez le resilver se terminer en surveillant. Ne déclarez pas victoire à 3%.
2. Lancez un scrub après resilver pour valider la redondance et découvrir des problèmes de lecture latents.
3. Vérifiez l’intégrité applicative des données pour tout fichier que ZFS a marqué comme erreur permanente.
4. Configurez ou ajustez les alertes : write errors > 0 doit déclencher une alerte en heures ouvrables, pas attendre la dégradation du pool.

Renforcement (la partie qui évite les répétitions)

1. Utilisez le nommage by-id dans tous les pools. Si vous avez hérité d’un pool utilisant /dev/sdX, planifiez une migration contrôlée.
2. Standardisez les HBAs en mode IT et gardez les firmwares cohérents sur la flotte.
3. Étiquetez les sleds avec les numéros de série et maintenez une carte des emplacements. C’est ainsi que vous évitez les incidents « disque remplacé par erreur ».
4. Surveillez les messages de reset noyau et les compteurs SMART CRC en parallèle des compteurs d’erreurs ZFS.
5. Planifiez des scrubs réguliers et suivez les tendances, pas seulement un statut pass/fail.

FAQ

1) Les erreurs d’écriture ZFS signifient-elles toujours un disque défaillant ?

Non. Elles indiquent souvent que l’I/O d’écriture n’a pas pu être complétée avec succès, ce qui peut être le firmware du disque, mais très souvent c’est
le câblage, le backplane, l’expander, l’HBA ou l’alimentation. Vérifiez les logs de transport avant de commander une palette de disques.

2) Quelle est la différence entre erreurs d’écriture et erreurs de somme de contrôle dans ZFS ?

Les erreurs d’écriture signifient que ZFS n’a pas pu engager les données sur le périphérique/chemin. Les erreurs de checksum signifient que des données lues ne correspondaient pas à leur checksum —
corruption ou mauvaise livraison. Les deux sont graves ; ils pointent vers des couches différentes.

3) Si je lance un scrub et qu’il indique 0 erreur, suis-je en sécurité ?

Plus sûr, pas garanti. Le scrub est orienté lecture et valide les données stockées. Il ne prouve pas que votre chemin d’écriture est stable sous votre charge réelle.
Si les erreurs d’écriture augmentent, vous avez toujours un problème de fiabilité du chemin d’écriture.

4) Dois-je effacer les erreurs ZFS avec zpool clear ?

Oui, mais seulement après avoir corrigé quelque chose et vouloir valider que la correction a fonctionné. Effacer juste pour « faire taire l’alerte » fait évoluer l’incident.

5) Pourquoi les erreurs d’écriture apparaissent-elles souvent pendant un resilver ?

Le resilver est une activité d’écriture soutenue plus des lectures à travers le vdev. Il transforme les problèmes de transport marginaux en pannes évidentes.
Considérez le resilver comme un test de stress que vous n’avez pas planifié.

6) Mon pool est mirror. Si un côté a des erreurs d’écriture, ZFS peut-il quand même réussir ?

Souvent oui. Mais le miroir ne vous protège que si l’autre côté est sain et que le système peut compléter les transactions en toute sécurité.
Un périphérique qui oscille peut toujours provoquer des pics de latence et un risque opérationnel.

7) Ai-je besoin de RAM ECC pour éviter les erreurs d’écriture ?

L’ECC est fortement recommandé pour ZFS, mais les erreurs d’écriture sont spécifiquement des échecs de complétion I/O, pas généralement de la corruption mémoire.
L’ECC aide à prévenir les erreurs de checksum et la corruption silencieuse. Elle ne répare pas les mauvais câbles.

8) Un HBA peut-il provoquer des erreurs d’écriture sans aucun problème SMART disque ?

Absolument. Si l’HBA ou l’expander réinitialise des liens, gère mal les files d’attente, surchauffe ou a des bugs firmware, ZFS verra des échecs I/O d’écriture.
SMART peut sembler impeccable parce que le disque n’a jamais eu une chance propre de faire son travail.

9) Quel seuil d’alerte devrais-je utiliser pour les erreurs d’écriture ?

Pour la plupart des systèmes de production : toute erreur d’écriture non nulle sur un périphérique par ailleurs sain doit déclencher une investigation.
Si elles augmentent dans le temps, escaladez. Les tendances comptent plus qu’un seul chiffre, mais la première erreur d’écriture est l’alerte la plus précoce.

10) Si ZFS signale « permanent errors », est-ce une perte de données totale ?

Pas totale, mais cela signifie que ZFS n’a pas pu réparer certains blocs à partir de la redondance. Les fichiers/objets affectés doivent être restaurés depuis des backups ou réplicas.
Ensuite, vous devez comprendre pourquoi la redondance n’a pas suffi à ce moment-là.

Conclusion : étapes pratiques suivantes

Les erreurs d’écriture ZFS ne sont pas une statistique de trivia. Ce sont un schéma de panne. Elles prédisent les mises hors ligne parce qu’elles sont souvent le premier signe visible
que le chemin d’écriture — disque, lien, contrôleur, baie — ne peut pas compléter de façon fiable les I/O sous pression.

Faites trois choses la prochaine fois que vous voyez WRITE > 0 :

1. Corrélez immédiatement : compteurs ZFS + logs noyau + erreurs d’interface SMART. Trouvez la couche en défaut.
2. Stabilisez le chemin : rebranchez/remplacez câbles, changez de slot, vérifiez HBAs et firmware, et ne laissez pas un resilver ronger du matériel instable.
3. Prouvez la correction : effacez les compteurs après remédiation et surveillez la récurrence. Si le compteur remonte, arrêtez de négocier et remplacez les composants.

La fiabilité du stockage consiste surtout à refuser d’être surpris deux fois par la même panne.
ZFS vous donne une prévision. Utilisez-la.