ZFS : Les 3 métriques qui prédisent un plantage de pool avant qu’il n’arrive

Les 3 métriques qui prédisent réellement un plantage

Les défaillances ZFS dans la vraie vie ressemblent rarement aux caricatures. Vous n’obtenez pas toujours un joli « disque mort, remplacez le disque ». Plus souvent vous avez :

• Une catastrophe I/O au ralenti qui provoque des timeouts dans les applications, suivie de réinitialisations puis de la déconnexion d’un périphérique.
• La détection silencieuse de corruption (checksums) qui commence petit et devient « pourquoi réécrivons-nous la moitié du pool ? »
• Une pression de capacité qui transforme les écritures normales en cauchemar d’allocation, puis en latence, puis en panique.

Voici donc les trois métriques qui m’intéressent parce qu’elles ont tendance à bouger avant que le pool ne prenne feu :

1) Compteurs d’erreurs qui évoluent dans le temps

Ce n’est pas le fait d’avoir un nombre non nul une fois dans l’histoire. C’est la pente. Si les compteurs READ/WRITE/CKSUM bougent entre deux scrubs, entre deux redémarrages ou entre deux points « connus bons », le pool vous dit qu’il perd sa contractuelle réalité.

2) Latence + pression de file d’attente au niveau pool/vdev

Le débit est un métrique de vanité. La latence est la vérité. La croissance des files et les temps de service longs sont la façon de repérer une déconnexion imminente d’un périphérique, un pool en thrashing, ou un design qui était « correct en staging ».

3) Marge de capacité et fragmentation

ZFS peut tolérer beaucoup, mais pas un pool proche de la saturation tout en étant fragmenté et soumis à des écritures aléatoires. Le prédicteur ici n’est pas « 80% utilisé ». C’est « nous sommes du mauvais côté de la courbe et les scrubs/reslivers prennent maintenant une éternité ».

Une idée paraphrasée de Deming (les spécialistes de la fiabilité le citent constamment pour une raison) : Sans données vous n’êtes qu’une autre personne avec une opinion. Idée paraphrasée, mais le point reste—collectez les bonnes données.

Une blague (1/2) : ZFS ne « plante » pas « aléatoirement ». Il attend juste que vous soyez en vacances puis dépose une plainte détaillée sous forme de latence.

Métrique 1 : compteurs d’erreurs qui bougent (READ/WRITE/CKSUM)

ZFS vous offre un cadeau que la plupart des piles de stockage n’ont pas : un checksum bout-en-bout avec un comptage d’erreurs explicite. Mais il faut le lire comme un opérateur, pas comme un touriste.

Ce qui compte comme « prédictif » ici

• Nouvelles erreurs de checksum (CKSUM) sur un seul périphérique, augmentant lentement : souvent câblage, backplane, contrôleur, firmware ou média marginal.
• Erreurs de lecture en hausse : le périphérique n’a pas pu renvoyer les données (ou n’a pas pu le faire dans la patience du pilote). Si ça bouge, le disque est candidat au remplacement.
• Erreurs d’écriture en hausse : peut être le périphérique, mais aussi les chemins HBA/contrôleur, l’alimentation ou des timeouts sous charge.
• Erreurs liées à des blocs précis qui réapparaissent après un scrub : vous êtes face à une corruption persistante ou à un « correctif » qui n’a pas résolu le problème.

Comment un plantage survient à partir de « quelques erreurs »

Un plantage de pool, en pratique, est souvent une cascade :

1. Le périphérique commence à renvoyer des erreurs occasionnelles ou à prendre trop de temps.
2. ZFS réessaie ; la file grandit ; la latence explose ; les timeouts applicatifs commencent.
3. Le pilote réinitialise le périphérique ; ZFS le marque FAULTED ou DEGRADED.
4. Un resilver démarre ; la charge augmente ; d’autres périphériques marginaux sont stressés.
5. Vous n’êtes plus qu’à un incident de perdre la redondance.

C’est pourquoi « ce n’est que 3 erreurs de checksum » n’est pas rassurant. C’est une phrase qui devrait déclencher une enquête et une analyse de tendance, car de petits compteurs sont souvent le générique d’ouverture.

Que faire avec des compteurs non nuls

Vous décidez en fonction de la persistance, de la localisation et de la corrélation :

• Persistance : Les erreurs continuent-elles d’augmenter après un scrub et après avoir resserré/rebranché les câbles ?
• Localité : Est-ce un seul périphérique ou plusieurs ? Un seul chemin suggère le matériel. Plusieurs suggèrent contrôleur, backplane, firmware ou alimentation.
• Corrélation : Les erreurs coïncident-elles avec des pics de charge, la température ou un hôte spécifique ?

Métrique 2 : latence et pression de file d’attente (le pool « respire fort »)

Quand des pools ZFS « plantent », ils ne sont souvent pas réellement morts. Ils sont juste coincés dans une latence pathologique : tout fonctionne techniquement, mais rien ne se termine à temps pour vos applis. Opérationnellement, c’est indistinguable d’une indisponibilité.

À quoi ressemblent les signaux de latence dans ZFS

Vous voulez surveiller au niveau du pool et des vdev, pas seulement les IOPS par disque :

• Await élevé / temps de service long pendant des charges normales.
• Profondeur de file en hausse (les requêtes s’entassent parce que le pool ne peut pas se vider).
• Scrub/resilver prenant nettement plus de temps que les bases historiques.
• Pression d’écriture synchrone (surtout avec un SLOG mal conçu ou sans SLOG pour des charges sync-intensives).

Pourquoi cela prédit des déconnexions de périphérique

Les timeouts et réinitialisations sont souvent d’abord une histoire de latence. Beaucoup de « pannes de disque » sont des « disques devenus trop lents et l’OS a abandonné ». Cette distinction compte parce que la solution change :

• Si un seul disque est lent : remplacez-le.
• Si tous les disques ralentissent en même temps : examinez HBA, expander, firmware, erreurs PCIe, saturation, pression ARC, ou comportement lié à un pool trop plein.
• Si seules les écritures sync sont lentes : vérifiez SLOG, paramètres sync et sémantiques de la charge.

Une blague (2/2) : La profondeur de file, c’est comme les e-mails : plus elle grandit, moins il y a de chances que quelque chose d’important reçoive une réponse.

Métrique 3 : marge de capacité + fragmentation (metaslabs et la falaise)

La performance de ZFS n’est pas linéaire avec le taux d’utilisation. Le pool subit une transition de phase : l’allocation devient plus difficile, l’espace libre est morcelé en petits morceaux, et les écritures deviennent plus coûteuses. Le pool n’a pas besoin d’être à 99% pour se comporter comme s’il mourait.

La marge n’est pas une impression ; c’est un bouton de contrôle

Si vous exploitez des pools ZFS en production, vous devriez avoir une politique de marge explicite. Ma base d’opinion :

• Charges mixtes générales : rester sous ~80% utilisé.
• Fortes écritures aléatoires, métadonnées lourdes, snapshots partout : viser sous ~70% utilisé.
• Vdevs rustiques avec petits blocs : être plus strict ; la fragmentation vous pénalise plus tôt.

Ce ne sont pas des lois physiques ; ce sont des garde-fous. Le signal réel est la tendance : quand l’allocation ralentit et que la fragmentation augmente, vous êtes passé hors de la zone confortable.

Fragmentation et pourquoi elle devient « comme un plantage »

ZFS alloue à partir de metaslabs. À mesure que l’espace libre se fragmente, les allocations exigent plus de seek, plus de travail métadonnées, plus d’opérations I/O, et des temps de commit de transaction group (TXG) plus longs. Les symptômes incluent :

• La latence d’écriture qui grimpe même si le débit semble « correct ».
• Les scrubs/reslivers qui passent d’heures à des jours.
• Des blocages en rafales où les applis s’arrêtent pendant la synchronisation des TXG.

Les problèmes de capacité amplifient aussi d’autres risques : les resilvers sur des pools presque pleins prennent plus de temps, augmentant la fenêtre d’exposition où vous êtes à un disque d’une perte de données.

Playbook de diagnostic rapide

Ceci est l’ordre que j’utilise quand une appli dit « le stockage est lent » ou quand la surveillance montre une dégradation de la santé du pool. Il est conçu pour trouver rapidement le goulot, pas pour satisfaire la curiosité.

Première étape : le pool est-il logiquement sain ou déjà en train de saigner ?

• Vérifiez zpool status pour DEGRADED/FAULTED, les compteurs d’erreurs, et tout resilver/scrub en cours.
• Si les compteurs d’erreurs bougent : traitez ceci comme un incident, pas comme une session de tuning.

Deuxième étape : est-ce de la latence/pression de file (systémique) ou un mauvais acteur isolé (un vdev/périphérique) ?

• Utilisez zpool iostat -v pour identifier quel vdev est lent, pas seulement quel dataset est occupé.
• Corrélez avec iostat et les logs noyau pour les réinitialisations/timeouts.

Troisième étape : la capacité/fragmentation est-elle la coupable cachée ?

• Vérifiez l’allocation du pool et les indicateurs de fragmentation. Si vous êtes près de la falaise, les « bugs » de performance sont généralement physiques.
• Validez la croissance des snapshots et les workloads à petits blocs (VMs, bases de données, boîtes mail) qui accélèrent la fragmentation.

Quatrième étape : confirmez les sémantiques de la charge (sync, recordsize, special vdevs)

• NFS intensif en sync ? Images VM avec petits writes ? Un SLOG « astucieux » ? Un special vdev ? Ceux-ci façonnent le chemin I/O et les modes de défaillance.
• Ne devinez pas. Récupérez les propriétés des datasets et observez les schémas I/O réels.

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

Ci-dessous se trouvent des actions pratiques que vous pouvez exécuter aujourd’hui. Chacune comprend : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre. Ce sont les manœuvres ennuyeuses qui maintiennent votre pool en vie.

Task 1: Read pool health and error slope

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 03:18:22 with 0 errors on Sun Feb  4 01:10:43 2026
config:

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

errors: No known data errors

Ce que cela signifie : Un disque a 2 erreurs de checksum. ZFS les a corrigées et signale aucune erreur de données connue. Ce n’est pas « correct » ; c’est « à investiguer ».

Décision : Vérifiez si le compteur CKSUM augmente dans le temps. S’il s’incrémente à nouveau après un scrub ou après avoir rebranché les câbles, planifiez le remplacement du disque et inspectez le câblage/backplane.

Task 2: Clear errors only after you’ve captured evidence

cr0x@server:~$ sudo zpool clear tank

Ce que cela signifie : Les compteurs sont remis à zéro. C’est utile pour mesurer les tendances, mais cela détruit aussi votre comparaison avant/après si vous ne l’avez pas enregistrée.

Décision : Ne clear qu’après avoir capturé la sortie de zpool status (ticket/notes) et que vous êtes prêt à observer si les erreurs réapparaissent.

Task 3: Confirm whether a scrub is running and how it behaves

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Feb  3 00:12:10 2026
        3.42T scanned at 1.21G/s, 1.88T issued at 684M/s, 8.10T total
        0B repaired, 23.19% done, 0:02:53 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
errors: No known data errors

Ce que cela signifie : Le scrub progresse rapidement. Comparez les taux scan/issue aux scrubs précédents.

Décision : Si la vitesse du scrub se réduit soudainement de moitié (ou pire) sans changement de charge intentionnel, enquêtez sur la latence et la fragmentation ; c’est un avertissement précoce.

Task 4: Identify which vdev is slow under load

cr0x@server:~$ sudo zpool iostat -v tank 2 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        6.12T  1.98T    320    610  42.1M  81.7M
  raidz2-0                  6.12T  1.98T    320    610  42.1M  81.7M
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M
    ata-WDC_WD80...-part1      -      -     41     88  5.0M  11.8M
    ata-WDC_WD80...-part1      -      -     39     92  5.2M  12.3M
    ata-WDC_WD80...-part1      -      -     40    250  5.0M  35.0M
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.1M
    ata-WDC_WD80...-part1      -      -    120      0  16.7M   0.0
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Un disque reçoit de façon disproportionnée des écritures (250 ops) et un autre prend la plupart des lectures (120 ops). Cela peut être normal selon la disposition de parité et la charge, mais un déséquilibre persistant peut indiquer un périphérique lent faisant attendre les autres.

Décision : Si un périphérique montre systématiquement une bande passante plus faible avec plus d’opérations (I/O petites) et que les logs système montrent des timeouts, traitez ce périphérique/chemin comme suspect.

Task 5: Get latency stats (OpenZFS) to spot service-time explosions

cr0x@server:~$ sudo zpool iostat -v -l tank 1 3
                              capacity     operations     bandwidth    latency
pool                        alloc   free   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----
tank                        6.12T  1.98T    310    590  41.0M  79.0M  2.1ms  18.4ms
  raidz2-0                  6.12T  1.98T    310    590  41.0M  79.0M  2.1ms  18.4ms
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M  1.8ms  12.2ms
    ata-WDC_WD80...-part1      -      -     40     90  5.0M  12.0M  1.9ms  12.4ms
    ata-WDC_WD80...-part1      -      -     40     90  5.2M  12.1M  2.0ms  12.6ms
    ata-WDC_WD80...-part1      -      -     40    240  5.0M  33.0M  2.1ms  85.0ms
    ata-WDC_WD80...-part1      -      -     40     90  5.1M  12.0M  2.0ms  12.5ms
    ata-WDC_WD80...-part1      -      -    110      0  15.6M   0.0  2.2ms   0.0ms
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Un disque affiche 85ms de latence d’écriture tandis que les pairs sont à ~12ms. Voilà votre futur rapport d’incident.

Décision : Corrélez avec les logs noyau ; planifiez le remplacement ou la réparation du chemin. Ne « tunez » pas autour d’un disque qui développe une personnalité.

Task 6: Check pool usage and ashift implications

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,health,ashift tank
NAME  SIZE  ALLOC   FREE  CAP  HEALTH  ASHIFT
tank  8.10T  6.12T  1.98T   75%  ONLINE  12

Ce que cela signifie : 75% utilisé, ashift=12 (secteurs 4K). Bonne base pour disques/SSDs modernes.

Décision : Si ashift est incorrect (p.ex. 9 sur des disques 4K), vous ne pouvez pas le corriger sur place ; planifiez une reconstruction/migration. Un ashift erroné est une taxe de performance à long terme qui peut devenir un problème de stabilité sous charge.

Task 7: Inspect dataset properties that change the I/O path

cr0x@server:~$ sudo zfs get -o name,property,value -s local recordsize,compression,atime,sync,logbias xattr tank/vmstore
NAME          PROPERTY     VALUE
tank/vmstore  recordsize   16K
tank/vmstore  compression  lz4
tank/vmstore  atime        off
tank/vmstore  sync         standard
tank/vmstore  logbias      latency
tank/vmstore  xattr        sa

Ce que cela signifie : Ce dataset est réglé pour des blocs petits façon VM (recordsize 16K), compression lz4, atime off, logbias latency. Bien, mais cela implique une sensibilité aux écritures sync et une intensité métadonnées.

Décision : Vérifiez que vous possédez réellement un SLOG sain si la latence des écritures sync compte. Ne définissez pas recordsize petit « parce que les bases de données » ; mesurez d’abord la taille réelle de vos I/O.

Task 8: Identify snapshot pressure (capacity predictor)

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer -s used | head
NAME                                USED  REFER
tank/vmstore@auto-2026-02-04-0000    48G   3.1T
tank/vmstore@auto-2026-02-03-0000    44G   3.1T
tank/vmstore@auto-2026-02-02-0000    39G   3.1T
tank/vmstore@auto-2026-02-01-0000    33G   3.1T

Ce que cela signifie : Les snapshots consomment de l’espace réel (USED), même si REFER reste similaire. Cela peut manger silencieusement la marge et provoquer de la fragmentation.

Décision : Mettez en place une politique de rétention et vérifiez qu’elle supprime réellement les snapshots. Si USED par snapshot grandit plus vite que prévu, votre churn est élevé et les resilvers feront plus mal.

Task 9: Measure ARC pressure (latency predictor in disguise)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01   612   118     16    44    6    60    8    14    2   46.2G  64.0G
12:10:02   590   121     17    50    7    55    8    16    3   46.2G  64.0G
12:10:03   640   130     17    52    7    61    8    17    3   46.3G  64.0G

Ce que cela signifie : La taille de l’ARC est stable ; le taux de miss ~16–17%. Si le taux de miss explose et que vous commencez à saturer les disques, la latence suit.

Décision : Si l’ARC est contraint (limites de conteneur, ballooning VM, zfs_arc_max mal configuré), corrigez la pression mémoire d’abord. Ne blâmez pas les disques pour ce que la RAM n’a pas mis en cache.

Task 10: Spot error/reset patterns in kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i 'reset|timeout|error|ata|nvme' | tail -n 12
[Mon Feb  3 13:42:11 2026] ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
[Mon Feb  3 13:42:11 2026] ata7.00: irq_stat 0x08000000, interface fatal error
[Mon Feb  3 13:42:12 2026] ata7: hard resetting link
[Mon Feb  3 13:42:17 2026] ata7: link is slow to respond, please be patient (ready=0)
[Mon Feb  3 13:42:22 2026] ata7: COMRESET failed (errno=-16)
[Mon Feb  3 13:42:22 2026] ata7.00: disabled

Ce que cela signifie : Réinitialisations de lien et échecs COMRESET pointent vers des problèmes de câblage/backplane/chemin HBA, pas forcément « ZFS mauvais ». C’est un précurseur classique aux périphériques qui tombent du pool.

Décision : Remplacez les câbles, changez de port, vérifiez l’alimentation et le backplane. Si les erreurs suivent le port, votre disque est innocent et votre châssis ment.

Task 11: Verify SMART/NVMe health for the suspect device

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|CRC_Error_Count|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       14

Ce que cela signifie : « PASSED » est du marketing. Les secteurs en attente + les non-correctables sont sérieux. Les erreurs CRC suggèrent des problèmes de câblage/chemin.

Décision : Si les erreurs CRC augmentent, fixez le câblage/backplane d’abord. Si les secteurs en attente persistent/augmentent, planifiez le remplacement—surtout si la redondance est réduite.

Task 12: Check scrub schedule and ensure scrubs aren’t silently failing to run

cr0x@server:~$ systemctl status zfs-scrub@tank.timer
● zfs-scrub@tank.timer - ZFS scrub timer for tank
     Loaded: loaded (/lib/systemd/system/zfs-scrub@.timer; enabled; preset: enabled)
     Active: active (waiting) since Sun Feb  2 00:00:01 2026
    Trigger: Mon Feb  17 00:00:00 2026

Ce que cela signifie : Les scrubs sont programmés et activés.

Décision : Si les scrubs ne s’exécutent pas régulièrement, vous perdez la détection précoce. Activez et surveillez l’achèvement des scrubs et les compteurs d’erreurs.

Task 13: Detect near-full datasets and quota surprises

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -S used | head
NAME           USED  AVAIL  REFER  MOUNTPOINT
tank/vmstore   5.4T   520G  3.1T   /tank/vmstore
tank/backups   580G  2.2T   580G   /tank/backups
tank/home      120G  2.7T   120G   /tank/home

Ce que cela signifie : vmstore consomme la majeure partie de l’espace ; seulement 520G « disponibles » au niveau dataset peuvent être serrés selon le churn et le comportement des snapshots.

Décision : Si ce dataset a un churn élevé (VMs), augmentez la marge en supprimant des snapshots, en déplaçant des données ou en agrandissant le pool avant que la performance ne s’effondre.

Task 14: Check for special vdev and understand the blast radius

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SSDPE...     ONLINE       0     0     0
            nvme-INTEL_SSDPE...     ONLINE       0     0     0

Ce que cela signifie : Un special vdev existe (métadonnées/petits blocs selon les réglages). Ses modalités de défaillance peuvent être sévères si des métadonnées critiques y sont stockées.

Décision : Traitez les special vdevs comme des citoyens de première classe : mettez-les en miroir, surveillez-les, maintenez le firmware à jour et ne lésinez pas sur l’endurance.

Task 15: Confirm sync behavior when latency spikes are “only for some writes”

cr0x@server:~$ sudo zfs get -o name,property,value sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

Ce que cela signifie : Les écritures sync sont honorées. Si votre charge est sync-intensive et que vous n’avez pas un SLOG capable (ou que le vôtre est mauvais), vous le ressentirez.

Décision : Ne définissez pas sync=disabled comme « astuce performance » à moins d’avoir explicitement accepté les sémantiques de perte de données. Si vous avez besoin d’une faible latence sync, concevez correctement le SLOG.

Trois mini-récits du monde de l’entreprise

Mini-récit 1 : l’incident causé par une mauvaise hypothèse

Ils exploitaient une flotte d’hôtes de virtualisation avec des pools ZFS locaux. Configuration confortable : SSD en miroir pour le boot, raidz pour le stockage VM, et scrubs hebdomadaires. L’hypothèse de l’équipe était simple : les erreurs de checksum signifient « le disque est mort ». C’était ce que disaient les graphiques, et les graphiques n’avaient jamais tort.

Un hôte a commencé à accumuler un petit nombre d’erreurs CKSUM sur deux disques, pas un. L’astreignant a remplacé le premier disque. Les erreurs ont continué. Puis ils ont remplacé le second. Toujours en hausse. Personne n’aimait l’idée, mais l’équipe a commencé à planifier une maintenance plus large : « peut-être qu’on a reçu un lot défectueux ».

Pendant ce temps, le schéma d’incident est devenu plus vilain. Sous forte charge d’écriture, un disque disparaissait brièvement, ZFS dégradait le vdev, et les VMs gelaient assez longtemps pour que les OS invités paniquent. Puis le périphérique revenait, parfois. Les compteurs grimpaient comme un escalier—mais seulement pendant des fenêtres de trafic spécifiques.

La cause racine était un chemin de backplane : un connecteur marginal qui se comportait jusqu’à ce que la température soutenue et les vibrations le fassent basculer. L’hypothèse « le disque est mauvais » a retardé la bonne réparation d’une semaine et a consommé plusieurs fenêtres de maintenance. Une fois qu’ils ont déplacé les disques vers d’autres baies (et remplacé le backplane), les compteurs de checksum ont cessé d’augmenter. Même disques. Même données. Réalité différente.

Leçon : Une erreur de checksum n’est pas un diagnostic disque ; c’est une alarme d’intégrité des données. Quand les erreurs se répandent sur plusieurs appareils, suspectez d’abord les composants partagés : câblage, backplane, HBA, expander, alimentation.

Mini-récit 2 : l’optimisation qui s’est retournée contre eux

Une équipe de plateforme de données voulait un NFS plus rapide pour un cluster d’analytics chargé. Le backend était ZFS sur un bon ensemble de HDD avec beaucoup de RAM. La latence semblait correcte jusqu’aux jobs batch nocturnes, quand les écritures sync s’accumulaient et que tout le monde se plaignait.

Quelqu’un a proposé un gain rapide : ajouter un NVMe « rapide » consommateur comme SLOG. Sur le papier c’était parfait—pas cher, benchmarks fulgurants, installation facile. Ils ont aussi changé quelques propriétés de dataset dans la même fenêtre pour « aligner pour les petits writes ». Le benchmark s’est amélioré. Une salve de félicitations a suivi. C’est comme ça que ça commence toujours.

Deux mois plus tard, le pool n’a pas exactement planté. Il a fait quelque chose de plus subtil et plus coûteux : il a commencé à se bloquer pendant des secondes, puis des dizaines de secondes. Les clients NFS accrochaient. Les logs noyau montraient des erreurs NVMe occasionnelles. Le SLOG n’était pas mort, juste intermittemment lent et se réinitialisant de temps en temps. Chaque reset forçait un comportement de retry douloureux, et parce que le SLOG était dans le chemin critique des écritures sync, tout le service paraissait indisponible.

Le déclencheur final fut un événement d’alimentation dans le rack. Le NVMe consommateur manquait de la protection contre perte de puissance qu’on souhaite réellement sur un dispositif de log. Après le reboot, l’équipe a passé une longue nuit à valider l’intégrité des données et la sémantique de replay. Ils ont eu de la chance, mais la chance n’est pas une architecture.

Leçon : Le SLOG n’est pas « un cache ». C’est un dispositif de journal d’écriture avec des exigences de fiabilité et de latence. Si vous ajoutez un SLOG, prenez du matériel de qualité entreprise, mettez-le en miroir si la charge l’exige, et surveillez-le comme s’il était en production—parce qu’il l’est.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise SaaS de taille moyenne utilisait ZFS sur des nœuds de stockage dédiés pour l’object storage et les sauvegardes internes. Rien d’extraordinaire. Ils avaient une politique presque comiquement stricte : scrubs mensuels, enregistrement obligatoire de la durée du scrub, et une règle simple—tout périphérique avec des erreurs récurrentes après remédiation est remplacé avant le prochain cycle de maintenance.

Cela n’était pas populaire au début. Les scrubs créent de la charge. Remplacer des disques coûte de l’argent. Et noter les durées de scrub semblait bureaucratique. Mais ils ont persisté parce que leurs revues d’incident jugeaient inacceptables les « on ne savait pas ».

Un mois, la durée du scrub sur un pool clé a fortement augmenté sans croissance des données totales. Personne n’avait touché à la configuration. Les compteurs d’erreurs étaient encore à zéro. Mais l’équipe a traité « le temps de scrub a doublé » comme un signal de défaillance et a commencé à creuser. Ils ont trouvé un ensemble de disques encore en ligne mais avec un temps de récupération de lecture dramatiquement augmenté. L’OS ne timeoutait pas encore ; ZFS ne s’était pas plaint. C’était la fenêtre.

Ils ont remplacé deux disques de façon contrôlée et en période de faible charge—avant que le pool soit dégradé, avant qu’un resilver doive concurrencer le trafic de production, avant qu’ils ne soient à une surprise d’une mauvaise journée. Une semaine plus tard, l’un de ces disques retirés a échoué à un diagnostic fournisseur.

Leçon : Les baselines sont une assurance bon marché. La durée des scrubs et des resilvers sont des indicateurs précoces même quand la « santé » semble verte.

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

1) « Quelques erreurs de checksum, mais le scrub indique 0 réparé »

Symptôme : CKSUM augmente ; le scrub rapporte aucune réparation ; les applis semblent ok.

Cause racine : Corruption transitoire sur le chemin (câble/backplane/HBA) ou média marginal qui n’a pas encore forcé une réparation ; les compteurs peuvent refléter des corrections via la redondance sans nécessiter de réparation lors du scrub.

Correction : Capturez zpool status -v, clear les compteurs, reseate/remplacez les câbles, vérifiez les logs pour réinitialisations, lancez un autre scrub. Si les compteurs reviennent, remplacez le périphérique ou corrigez le matériel partagé.

2) « Le pool est ONLINE mais tout fait des timeouts »

Symptôme : Pas d’erreurs ZFS évidentes, mais les applications bloquent ; iowait en pic.

Cause racine : Effondrement de latence dû à un périphérique lent, fragmentation proche de la saturation, goulot d’écriture sync, ou un resilver/scrub qui concurrence la charge.

Correction : Utilisez zpool iostat -v -l pour trouver le vdev lent. Vérifiez la capacité, l’activité scrub/resilver, et le chemin sync (SLOG). Limitez les scrubs si nécessaire et corrigez le composant lent réel.

3) « Le resilver prend maintenant une éternité »

Symptôme : Remplacer un disque prenait des heures avant ; maintenant ça prend des jours.

Cause racine : Le pool est plus plein, plus fragmenté, et/ou la charge est plus lourde ; possible aussi ralentissements au niveau périphérique augmentant le temps de service.

Correction : Augmentez la marge (supprimez des snapshots, migrez des données froides), planifiez les resilvers en période de faible charge, envisagez des vdevs plus larges prudemment, et vérifiez qu’aucun périphérique n’est en retard via les stats de latence.

4) « Nous avons corrigé la performance en mettant sync=disabled » (et ensuite…)

Symptôme : La performance s’améliore dramatiquement ; plus tard il y a perte de données après un crash/événement d’alimentation.

Cause racine : Changement sémantique : les écritures synchrones ne sont plus durables au commit.

Correction : Remettez sync=standard. Si vous avez besoin de performance sync, concevez SLOG et comportement de la charge. Si vous acceptez vraiment le risque, documentez-le comme un contrat avec le métier.

5) « Les lectures aléatoires sont terribles sur un pool SSD »

Symptôme : Latence anormalement élevée ; IOPS faibles.

Cause racine : Mauvais ashift, partitions mal alignées, ou problème de firmware/contrôleur SSD ; parfois aussi un mismatch recordsize provoquant une amplification de lecture.

Correction : Confirmez ashift et l’alignement. Si c’est incorrect, planifiez une reconstruction. Validez la santé et le firmware des SSD ; adaptez recordsize au workload.

6) « Le special vdev a accéléré, puis le pool est devenu fragile »

Symptôme : L’accélération des métadonnées/petits blocs a aidé—jusqu’à ce que des erreurs sur le special vdev commencent et que tout devienne inquiétant.

Cause racine : Le special vdev contient des allocations critiques ; s’il est sous-protégé ou utilise des périphériques faibles, sa défaillance menace la disponibilité du pool et parfois les données.

Correction : Mettez le special vdev en miroir, utilisez des périphériques haute endurance, surveillez SMART/NVMe, et gardez des spares prêts. Traitez-le comme faisant partie du pool, pas comme un plugin.

Listes de vérification / plan étape par étape

Checklist quotidienne/continue (quoi grapher et alerter)

• Pente d’erreur : alerter quand tout compteur vdev READ/WRITE/CKSUM augmente depuis la dernière baseline.
• Durée de scrub : alerter quand la durée augmente au-delà d’un seuil par rapport aux 3 dernières exécutions.
• Durée de resilver : suivre le temps de complétion ; une tendance à la hausse augmente l’exposition au risque.
• Percentiles de latence : latence d’écriture au niveau pool et vdev (p95/p99), pas seulement le débit moyen.
• Marge de capacité : cap du pool + tendance « jours avant plein » ; inclure la croissance des snapshots.

Quand vous voyez de nouvelles erreurs (réponse pas à pas)

1. Capturer les preuves : zpool status -v, zpool events -v (si disponible), lignes pertinentes des logs noyau.
2. Identifier l’étendue : un appareil vs plusieurs vs tout le chemin contrôleur.
3. Si plusieurs appareils affectés : investiguez d’abord les composants partagés (HBA, expander, backplane, alimentation).
4. Lancer/vérifier un scrub si approprié et sûr sous la charge courante.
5. Clear les compteurs après avoir une baseline, puis observer la réapparition.
6. Remplacez le matériel de façon proactive si les compteurs récidivent ou si la latence se dégrade, même si le pool reste ONLINE.

Quand la latence explose (réponse pas à pas)

1. Vérifiez si un scrub/resilver est en cours et concurrence la production.
2. Exécutez zpool iostat -v -l et identifiez le vdev ou périphérique le plus lent par latence.
3. Vérifiez les logs OS pour réinitialisations/timeouts sur ce chemin.
4. Vérifiez la saturation du pool et le churn de snapshots ; si proche de la falaise, créez immédiatement de la marge.
5. Validez la charge sync et la santé du SLOG si la latence sync domine.
6. Ce n’est qu’après avoir éliminé le matériel et la capacité que vous pouvez tuner des propriétés comme recordsize et compression.

Plan de maintenance trimestriel (ennuyeux, correct, efficace)

• Revoir les temps de scrub et les tendances d’erreurs pour chaque pool ; mettre à jour les baselines après changements majeurs.
• Revoir la rétention des snapshots et vérifier que les suppressions s’effectuent réellement.
• Tester un workflow de remplacement de disque sur un système non critique : étiquetage, zpool replace, surveillance du resilver, et scrub post-check.
• Auditer les versions de firmware pour HBAs et SSDs ; appliquer des mises à jour approuvées par le fournisseur en fenêtre contrôlée.
• Planification de capacité : prévoir la croissance et planifier des expansions avant d’atteindre votre politique de marge.

Faits intéressants et contexte historique (parce que le stockage a sa tradition)

• ZFS a été créé chez Sun Microsystems au milieu des années 2000 comme système de fichiers intégré + gestionnaire de volumes, explicitement pour réduire la douleur du « RAID + filesystem mismatch ».
• Le checksum bout-en-bout était un objectif de conception central : détecter la corruption silencieuse plutôt que de faire confiance aux couches inférieures.
• Le Copy-on-Write (CoW) explique pourquoi ZFS peut faire des snapshots cohérents à faible coût, mais aussi pourquoi la fragmentation et le comportement près de la saturation peuvent mordre pour des charges d’écriture aléatoires.
• Les scrubs existent parce que les disques mentent : ils peuvent renvoyer de mauvaises données sans signaler d’erreur. Les scrubs ZFS valident les checksums dans le pool.
• RAIDZ n’est pas RAID5 dans un pilote : il est intégré à l’allocateur et au modèle de transaction, ce qui est puissant mais rend la performance sensible au recordsize et à la forme du workload.
• ashift est devenu une leçon opérationnelle durable : choisir un mauvais alignement de taille de secteur ne casse pas les données, mais taxe la performance pour toujours.
• Le « SLOG » est constamment mal compris : il n’est utilisé que pour les écritures synchrones ; il n’accélère pas les écritures asynchrones normales, et un mauvais SLOG peut vous nuire.
• OpenZFS a évolué sur plusieurs plateformes (Illumos, FreeBSD, Linux) et a convergé en une base de code partagée, raison pour laquelle certaines commandes/fonctionnalités varient légèrement selon l’OS et la version.
• Les special vdevs sont des armes opérationnelles relativement modernes : puissants pour métadonnées/petits blocs, mais ils créent de nouveaux domaines de défaillance qui exigent une discipline opérationnelle mature.

FAQ

1) Quelle est la métrique la plus prédictive d’un « douleur imminente » ?

Nouveaux compteurs d’erreurs combinés à une latence d’écriture croissante. Les erreurs prédisent le risque d’intégrité ; la latence prédit le risque de disponibilité. Quand les deux bougent, vous êtes en zone dangereuse.

2) Si zpool status indique « No known data errors », puis-je me relaxer ?

Non. Cela signifie que ZFS estime avoir réparé ou évité un dommage visible par l’utilisateur. Ça ne signifie pas que la cause sous-jacente a disparu. Suivez les tendances des compteurs et vérifiez les logs.

3) Les erreurs de checksum signifient-elles toujours un disque défectueux ?

Non. Elles peuvent provenir du câblage, du backplane, du HBA, de l’expander, du firmware ou de l’alimentation. Si plusieurs disques affichent des CKSUM en hausse, suspectez d’abord l’infrastructure partagée.

4) Pourquoi un pool « donne l’impression d’avoir planté » alors qu’il est juste lent ?

Parce que vos applications ont des timeouts. Un système de stockage qui renvoie des résultats après 60 secondes est effectivement hors service pour des systèmes qui attendent 200ms.

5) Quel taux d’utilisation du pool est « trop plein » ?

Cela dépend du workload, mais beaucoup de pools de production commencent à mal se comporter au-delà d’environ ~80% utilisé, plus tôt pour des workloads écriture-aléatoire-intensifs. Utilisez les tendances de durée de scrub/resilver pour trouver votre falaise.

6) Dois-je lancer des scrubs hebdomadaires ou mensuels ?

Le mensuel est une base courante ; des scrubs plus fréquents peuvent se justifier pour des données de haute valeur ou du matériel instable. L’important est la constance et le suivi des temps d’achèvement et des erreurs.

7) Ajouter un SLOG est-il toujours une bonne idée ?

Non. Il n’aide que pour les écritures synchrones. Un SLOG faible ou instable peut détériorer les charges sync et devenir un amplificateur de défaillance. Choisissez avec soin.

8) Sur quoi dois-je alerter pour les erreurs ZFS ?

Alertez sur toute augmentation des compteurs READ/WRITE/CKSUM par périphérique, états DEGRADED/FAULTED, démarrage/fin et durée des scrub/resilver, et latence élevée soutenue au niveau vdev.

9) Si les resilvers sont lents, puis-je les « accélérer » en toute sécurité ?

Vous pouvez influencer le comportement en réduisant la charge concurrente et en assurant de la marge. Un tuning agressif peut priver les applications ou augmenter le risque. L’accélération la plus sûre est moins de problèmes : marge et disques sains.

10) Quand remplacer un disque si SMART dit PASSED ?

Quand les preuves opérationnelles montrent une tendance à l’aggravation : augmentation des secteurs en attente, non-correctables, erreurs ZFS récurrentes, ou latence anormale par rapport aux pairs. « PASSED » n’est pas une garantie.

Conclusion : prochaines étapes pratiques

Si vous voulez prédire un plantage de pool ZFS, arrêtez de regarder ce qui vous donne l’impression d’être informé et commencez à regarder ce qui change vos décisions :

1. Suivez la tendance des compteurs d’erreurs (READ/WRITE/CKSUM) par appareil et alertez sur les augmentations, pas seulement les valeurs non nulles.
2. Mesurez la latence et la pression de file au niveau vdev, et considérez une latence outlier comme un incident matériel/chemin jusqu’à preuve du contraire.
3. Appliquez une politique de marge et suivez la durée des scrub/resilver comme votre alerte précoce que le pool franchit sa falaise de performance.

Puis faites la chose ingrate : notez des baselines, gardez les scrubs réguliers, et remplacez des composants avant que le pool ne vous y force. ZFS est extrêmement honnête. Il n’est simplement pas poli sur le timing.