Mathématiques de la reconstruction RAIDZ de ZFS : pourquoi une panne de plus peut vous tuer

Termes qui comptent (et ceux que l’on utilise mal)

RAIDZ n’est pas « RAID‑5 mais dans ZFS »

RAIDZ est la disposition RAID par parité de ZFS. RAIDZ1 tolère une panne de disque dans un vdev. RAIDZ2 tolère deux pannes. RAIDZ3 tolère trois.
La tolérance de panne d’un pool est celle de son vdev le moins tolérant. Si vous avez un vdev RAIDZ2 et un vdev miroir simple,
le miroir n’est pas le maillon faible. Mais un vdev RAIDZ1 dans la configuration l’est assurément.

Résilver vs reconstruction

« Rebuild » est le terme générique pour RAID. ZFS exécute un résilver : il reconstruit les données manquantes sur un périphérique de remplacement.
Le détail clé : ZFS peut souvent ne copier que les blocs alloués (pas le disque entier), donc les résilvers peuvent être beaucoup plus rapides que les reconstructions RAID d’antan.
Mais le vdev doit quand même lire beaucoup de données pour recomposer la parité et vérifier les sommes de contrôle. Si votre pool est presque plein, « seuls les blocs alloués »
devient « la plupart des blocs », et la différence devient théorique.

Scrub n’est pas une sauvegarde et n’est pas un résilver

Un scrub lit les données et vérifie les sommes de contrôle, réparant la corruption en utilisant la redondance. Il ne vous protège pas d’un « oups, on a supprimé la prod. »
Mais les scrubs réduisent la probabilité que la première fois que vous découvriez des erreurs de secteur latentes soit pendant un résilver — moment où vous êtes déjà à un disque de la catastrophe.

URE, erreurs latentes et pourquoi les chiffres des constructeurs trompent par omission

URE signifie « unrecoverable read error » (erreur de lecture irrécupérable). Les fabricants publient un « taux d’erreurs de bits irrécupérables » (UBER) comme 10^-14 ou 10^-15 bits.
Les gens l’interprètent comme « une erreur tous les X To », puis arrêtent de réfléchir. Le risque réel dépend de :
combien de bits vous lisez pendant le résilver, combien de disques vous lisez, ce que fait le firmware sous stress,
et si vous avez scrubbé récemment. Le chiffre publié est un point de départ, pas une promesse.

Une citation à garder sur votre bureau. L’idée bien connue de Richard Cook concernant les systèmes complexes est souvent résumée ainsi :
« La réussite dans les opérations complexes repose sur l’adaptation ; l’échec arrive quand les défenses sont épuisées. »
(idée paraphrasée, Richard Cook)

Blague n°1 : Un résilver, c’est comme déménager pendant que l’immeuble est en feu — techniquement faisable, mais vous découvrirez quelles boîtes sont fragiles.

Faits intéressants et courte histoire

• ZFS a été conçu au milieu des années 2000 pour considérer le stockage comme un système, pas un tas de périphériques, en intégrant sommes de contrôle bout en bout et auto‑réparation.
• RAIDZ existe pour éviter le « write hole » de RAID‑5 en intégrant les mises à jour de parité dans les groupes de transactions copy‑on‑write.
• Les premières déploiements ZFS étaient gourmands en mémoire ; le mythe « ZFS a besoin de tonnes de RAM » vient de la faim réelle de l’ARC sur les anciens systèmes, pas d’une superstition.
• La réalité des secteurs 4K a tout changé : les désalignements ashift (par ex. des lecteurs 512e forcés en alignement 512) peuvent taxer durablement les performances et les temps de reconstruction.
• Les capacités de disque ont crû plus vite que le débit ; les fenêtres d’exposition de reconstruction se sont allongées quand on est passé de centaines de Go à des dizaines de To.
• « Résilverer seulement l’espace utilisé » a été une révolution comparé au RAID classique, mais c’est aussi dépendant de la fragmentation et du taux d’occupation.
• Les sommes de contrôle ont rendu la corruption silencieuse visible ; l’effet indésirable est que vous découvrez la corruption pendant les scrubs/résilvers, quand le pool est stressé.
• L’expansion RAIDZ est arrivée tard par rapport aux souhaits ; opérationnellement, cela a signifié beaucoup de plans « on met juste des disques plus gros et on remplace un par un ».
• Les UBER des disques d’entreprise se sont améliorés, mais le comportement du firmware sous forte mise en file peut toujours produire des timeouts qui ressemblent à des « pannes aléatoires ».

Pourquoi une panne de plus peut vous tuer

En RAIDZ1, la panne d’un disque vous place dans un état où chaque bloc nécessitant le disque manquant doit être reconstruit à partir des disques restants.
Pendant le résilver, vous êtes en dégradé : vous n’avez plus de redondance. Une panne supplémentaire — un autre disque qui lâche, un câble défaillant, un reset du contrôleur,
une série d’URE sur le mauvais disque — peut transformer « résilver en cours » en « restauration depuis les sauvegardes », si tant est que vous en ayez.

RAIDZ2 vous achète du temps et des options. Pas une sécurité infinie, mais un espace de respiration. Vous pouvez survivre à une seconde panne pendant un résilver.
Et plus important : vous pouvez encaisser quelques erreurs de lecture sans que le vdev ne se retrouve coincé. La différence pratique est psychologique :
les ingénieurs cessent de faire des mouvements précipités et risqués.

Les modes de défaillance ne sont pas indépendants

Les beaux calculs supposent des pannes indépendantes : un disque meurt, les autres ont des URE aléatoires aux taux annoncés, etc.
La réalité est plus salissante :

• Les disques d’un même lot tombent souvent proches les uns des autres.
• Les charges de résilver sont punissantes : lectures soutenues, forte profondeur de file, et beaucoup d’IO aléatoire si le pool est fragmenté.
• Les contrôleurs et expanders sont mis sous tension ; des câbles marginaux cessent d’être « corrects ».
• Le thermique change : un ventilateur défaillant ou un châssis à mauvaise circulation transforme les reconstructions en test de chauffe.
• Facteurs humains : quelqu’un voit « DEGRADED » et commence à remplacer le matériel comme au jeu du marteau.

La résilience que vous pensiez avoir achetée avec la parité est souvent consommée par des problèmes « non‑disque » pendant la fenêtre de résilver.
C’est pourquoi la phrase « une panne de plus peut vous tuer » est opérationnelle, pas poétique.

Mathématiques de reconstruction utiles

1) Temps d’exposition : combien de temps vous vivez dangereusement

Le modèle le plus simple et le plus utile est : le risque augmente avec le temps passé en dégradé. Si votre résilver prend 2 heures, vous êtes exposé 2 heures.
S’il prend 2 jours, vous êtes exposé 2 jours. Les détails comptent, mais ceci suffit à expliquer pourquoi les vdevs RAIDZ1 surdimensionnés sont un piège.

Une estimation pratique du temps de résilver :

• Données à copier ≈ octets alloués sur le vdev (pas le pool), majorés pour la fragmentation et l’overhead des métadonnées.
• Débit effectif ≈ minimum de (bande passante lecture disque, bande passante écriture vers le nouveau disque, calcul de parité du vdev, limites contrôleur/expander, et interférence avec la charge du pool).
• Temps de résilver ≈ données-à-copier / débit-effectif.

Si vous êtes à 80–90% d’occupation du pool, attendez‑vous à ce que « données à copier » soit inconfortablement proche du disque entier, et attendez que l’IO aléatoire domine.
C’est pourquoi les opérateurs expérimentés gardent les pools RAIDZ sous ~70–80% sauf raison majeure.

2) Math URE : l’argument classique « pourquoi RAID5 a succombé à grande échelle » (et ce que ZFS change)

Le calcul canonique de coin de table est :
la probabilité d’au moins une URE lors de la lecture de B bits est approximativement :
P ≈ 1 − (1 − p)^B,
où p est la probabilité URE par bit (ex. 10^-14).

Si vous lisez beaucoup de bits, P monte. Rapidement. L’erreur est de traiter cela comme un évangile dans un sens ou dans l’autre :
« une URE arrivera forcément » ou « les URE n’arrivent jamais en pratique ». Les deux postures sont paresseuses.

Ce que ZFS change :

• ZFS vérifie les sommes de contrôle, donc il peut détecter les mauvaises données au lieu de les servir silencieusement.
• Avec la redondance (RAIDZ2/3), ZFS peut souvent réparer autour d’un secteur défectueux en utilisant la parité et d’autres copies.
• Pendant un résilver dégradé RAIDZ1, une erreur de lecture sur un bloc critique peut devenir irrécupérable parce que le disque manquant supprime votre dernière marge.

3) « Combien de disques faut‑il lire ? » en pratique

Pendant un résilver RAIDZ, le système lit depuis tous les disques restants du vdev pour reconstruire les données manquantes. Cela signifie :
plus il y a de disques dans le vdev, plus de lectures agrégées, plus d’opportunités pour :
timeouts, UREs, et « ce disque allait bien jusqu’à ce que vous lui demandiez de tout lire ».

Les vdevs larges peuvent être excellents pour le débit séquentiel. Ils sont aussi excellents pour concentrer le risque pendant la reconstruction.
RAIDZ2 avec une largeur raisonnable tend à être le choix adulte pour de grands pools HDD.

4) Math de performance qui mord : petits blocs et fragmentation

La vitesse du résilver n’est pas que « MB/s disque ». Si votre dataset est rempli de petits blocs (bases de données, VMs, boîtes mail),
ZFS fait plus de traversée de métadonnées, effectue plus de seeks, et votre débit effectif s’effondre.
Si vous avez la compression, vous pouvez lire moins physiquement que la taille logique. Si vous avez la déduplication, vous compliquez d’autres aspects.

La vraie mathématique de reconstruction est un mélange :
fenêtre d’exposition × probabilité de pannes supplémentaires par unité de temps × probabilité d’erreurs de lecture irrécupérables par donnée lue.
Vous n’avez pas besoin d’un doctorat pour l’utiliser. Il suffit d’arrêter de prétendre que le temps de reconstruction est constant.

Comment le résilver ZFS fonctionne vraiment (et pourquoi il gagne parfois)

Copy‑on‑write et groupes de transactions

ZFS est copy‑on‑write. Il écrit de nouveaux blocs, puis met à jour les pointeurs. Cela réduit l’exposition au « write hole » parce que ZFS peut maintenir un état disque cohérent
via les groupes de transactions. La parité RAIDZ est intégrée à ces écritures.

Pourquoi « seulement les blocs alloués » est à la fois vrai et trompeur

ZFS résilver en fonction de ce qu’il croit être utilisé, pas « chaque LBA du disque ». C’est bien.
Mais il y a trois pièges :

• Taux d’occupation du pool : si vous êtes à 85% d’occupation, les blocs alloués représentent la majeure partie du disque.
• Fragmentation : les blocs alloués sont dispersés, donc le résilver devient de l’IO aléatoire.
• Overhead des métadonnées : blocs indirects, spacemaps, et gang blocks ajoutent des lectures et du travail CPU.

Résilver séquentiel vs résilver « healing »

ZFS peut effectuer différents modes de résilver selon l’implémentation et la situation (par exemple des comportements de scan séquentiel),
mais opérationnellement vous devriez supposer :
le résilver provoque des lectures soutenues sur le vdev, consomme le budget IO, et dégrade les performances.
Si vous exécutez une charge de production lourde en même temps, vous choisissez une fenêtre d’exposition plus longue.

Blague n°2 : Le résilver le plus rapide est celui que vous planifiez avant que le disque ne lâche — hélas, les disques refusent les invitations de calendrier.

Ce qui ralenti vraiment un résilver

1) Le pool est occupé, et ZFS fait preuve de courtoisie

ZFS évite intentionnellement de prendre tout le système en otage. L’IO de résilver concurrence l’IO normal.
C’est excellent pour les utilisateurs. C’est terrible pour « retrouver la redondance le plus vite possible ».
Vous pouvez régler cela, mais le faire aveuglément peut empirer la latence de production et provoquer des timeouts qui ressemblent à des pannes matérielles.

2) Un seul disque lent traîne tout le vdev

Les vdevs RAIDZ se comportent comme une équipe d’avirons. Un rameur a la gueule de bois, tout le monde tourne en rond.
Un disque marginal qui n’a pas « échoué » peut goulotter les lectures, entraînant de longs résilvers et plus de stress.

3) Contrôleurs, expanders et câblage

Les reconstructions exposent souvent les éléments jamais testés : un port d’expander SAS capricieux, un câble qui est « correct » à l’arrêt,
un bug de firmware du contrôleur, ou un backplane qui chauffe et commence à lâcher des erreurs.
Si vos logs montrent des resets de lien pendant le résilver, traitez‑le comme un incident de fiabilité, pas une énigme de performance.

4) Les erreurs d’ashift sont définitives

Si un pool a été créé avec le mauvais ashift, chaque écriture est désalignée. Cela gonfle l’IO et ralentit le résilver.
Vous ne pouvez pas corriger ashift en place. Il faut reconstruire le pool correctement. Voilà pourquoi « faire un pool rapidement » est une décision dangereuse pour la carrière.

5) Le CPU n’est généralement pas le goulot — jusqu’à ce qu’il le soit

Les CPU modernes gèrent généralement bien la parité RAIDZ et les sommes de contrôle. Mais la compression lourde, le chiffrement et des charges IOPS élevées peuvent inverser la situation.
Surveillez le CPU pendant le résilver. Si vous êtes à 100%, vos disques attendent des calculs.

Mode d’emploi pour un diagnostic rapide

Quand un résilver est lent, vous n’avez pas de temps pour un débogage artisanal. Triez‑le comme une panne.
L’objectif est de trouver le seul facteur limitant que vous pouvez changer rapidement.

Première étape : confirmer le domaine de défaillance et le vrai périmètre

• Est‑ce qu’un seul vdev est dégradé, ou plusieurs ?
• Le pool renvoie‑t‑il réellement des erreurs, ou est‑il juste en reconstruction ?
• Y a‑t‑il des erreurs de somme de contrôle (mauvaises données) ou seulement des erreurs de périphérique (chemin défaillant) ?

Seconde étape : identifier la classe de goulot

• Disque unique lent : un disque montrant une latence élevée / faible débit.
• Problème de bus/chemin : resets de lien, erreurs SAS, timeouts, multipath instable.
• Contention de charge : l’IO de production prive le résilver.
• Pression CPU/mémoire : compression/chiffrement ou thrash ARC qui ralentit tout.

Troisième étape : prendre l’action corrective la moins risquée

• Si un disque se comporte clairement mal, remplacez‑le immédiatement plutôt que de « patienter ».
• Si le chemin est instable, corrigez le câblage/firmware avant d’épuiser d’autres disques.
• Si la charge de production est le problème, limitez les clients, déplacez des charges, ou planifiez une fenêtre de maintenance pour prioriser le résilver.

La bonne réponse est souvent ennuyeuse : réduire la charge, laisser le résilver finir, puis scrubber.
La mauvaise réponse est le tuning de héros appliqué à un pool déjà dégradé.

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

Ci‑dessous des tâches de terrain que vous pouvez exécuter maintenant. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision à prendre.
Noms d’hôtes, pools et périphériques sont des exemples ; adaptez‑les à votre environnement.

Task 1: Verify pool health and resilver status

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Dec 26 02:20:17 2025
        3.12T scanned at 410M/s, 1.84T issued at 242M/s, 6.20T total
        1.84T resilvered, 29.68% done, 6:05:11 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     2
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
            sdg                     ONLINE       0     0     0
            sdh                     ONLINE       0     0     0
            replacing-1             DEGRADED     0     0     0
              sdi                   FAULTED      0     0     0  too many errors
              sdz                   ONLINE       0     0     0  (resilvering)

errors: No known data errors

Signification : « issued » est le travail réellement effectué ; « scanned » peut être supérieur. Les erreurs CKSUM sur un disque survivant (sdb) sont un signal d’alerte.

Décision : Si les CKSUM augmentent pendant le résilver, traitez cela comme une instabilité média ou de chemin ; prévoyez de remplacer ou de recâbler ce disque.

Task 2: See per-vdev I/O to spot a slow device

cr0x@server:~$ zpool iostat -v tank 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        92.1T  28.7T  1.02K   210   310M  52.1M
  raidz2-0                  92.1T  28.7T  1.02K   210   310M  52.1M
    sda                         -      -    120    25  38.5M  6.3M
    sdb                         -      -     11    24   1.2M  6.2M
    sdc                         -      -    121    25  38.7M  6.2M
    sdd                         -      -    122    24  38.8M  6.1M
    sde                         -      -    121    26  38.6M  6.4M
    sdf                         -      -    120    25  38.5M  6.3M
    sdg                         -      -    121    25  38.6M  6.2M
    sdh                         -      -    120    25  38.4M  6.1M
    sdz                         -      -    287    22  66.1M  5.9M
--------------------------  -----  -----  -----  -----  -----  -----

Signification : sdb contribue presque pas en lecture comparé à ses pairs.

Décision : Inspectez sdb immédiatement (SMART, câblage, chemin contrôleur). Un disque « lent mais online » peut tuer votre fenêtre de résilver.

Task 3: Check recent ZFS events for device flaps

cr0x@server:~$ zpool events -v | tail -n 20
TIME                           CLASS
Dec 26 2025 02:14:03.129812000  sysevent.fs.zfs.dev_remove
    pool = tank
    vdev_path = /dev/sdi
    vdev_guid = 1234567890123456789
Dec 26 2025 02:16:44.410223000  sysevent.fs.zfs.config_sync
    pool = tank
Dec 26 2025 02:20:17.004901000  sysevent.fs.zfs.resilver_start
    pool = tank
    vdev_path = /dev/sdz

Signification : Confirme la chronologie remove/replace ; utile pour corréler avec les logs et les actions humaines.

Décision : Si vous voyez des événements remove/add répétés, considérez plutôt une instabilité du chemin (expander/câble/HBA) qu’un « mauvais disque ».

Task 4: Confirm what ZFS thinks about errors

cr0x@server:~$ zpool status -x
pool 'tank' is not healthy

Signification : Toujours dégradé ; pas de nuance, mais c’est un contrôle rapide pour tableaux de bord et runbooks.

Décision : Utilisez‑le pour conditionner l’alerte de rétablissement seulement après avoir revu le statut détaillé.

Task 5: Pull SMART health and error counters for the suspicious disk

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Model|Serial|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Error|SMART overall"
Device Model:     WDC WD140EDGZ-11B2DA2
Serial Number:    9JH3K1AB
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       3

Signification : Sectors pending/offline uncorrectable sont mauvais ; les erreurs CRC suggèrent un câble / backplane / HBA défaillant.

Décision : Sectors pending pendant un résilver ? Remplacez le disque. CRC en hausse ? Reseat/remplacez le câble, vérifiez les logs d’expander/HBA.

Task 6: Run a short SMART test (if you can afford it)

cr0x@server:~$ sudo smartctl -t short /dev/sdb
Please wait 2 minutes for test to complete.
Test will complete after Fri Dec 26 03:01:42 2025

Signification : Un test court peut révéler des défaillances évidentes rapidement.

Décision : Si le disque ne peut pas terminer un test court ou signale des échecs de lecture, arrêtez les débats et remplacez‑le.

Task 7: Watch kernel logs for link resets and timeouts

cr0x@server:~$ sudo dmesg -T | egrep -i "sas|scsi|reset|timeout|link|I/O error" | tail -n 12
[Fri Dec 26 02:44:18 2025] sd 5:0:7:0: [sdb] tag#913 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Fri Dec 26 02:44:18 2025] sd 5:0:7:0: [sdb] CDB: Read(16) 88 00 00 00 00 10 2a 3f 00 00 00 00 80 00 00 00
[Fri Dec 26 02:44:19 2025] sas: phy-7: reset complete
[Fri Dec 26 02:44:22 2025] sd 5:0:7:0: [sdb] Sense Key : Medium Error [current]
[Fri Dec 26 02:44:22 2025] sd 5:0:7:0: [sdb] Add. Sense: Unrecovered read error

Signification : Timeouts + erreurs medium pendant des lectures lourdes sont exactement ce que le résilver induit.

Décision : Erreurs medium : remplacez le disque. Resets PHY répétés sur plusieurs disques : suspectez expander/HBA/câblage/firmware.

Task 8: Identify if the pool is too full (resilver will drag)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -S used tank | head
NAME            USED  AVAIL  REFER  MOUNTPOINT
tank            92.1T  28.7T   128K  /tank
tank/vm         41.8T  28.7T  41.8T  /tank/vm
tank/backups    28.2T  28.7T  28.2T  /tank/backups
tank/home       13.4T  28.7T  13.4T  /tank/home

Signification : ~76% alloué. Gérable, mais si c’était 90%+, la douleur du résilver augmente fortement.

Décision : Si >80% utilisé, prévoyez de libérer de l’espace ou d’ajouter de la capacité après l’incident ; ne normalisez pas des pools RAIDZ « presque pleins ».

Task 9: Check fragmentation (a quiet resilver killer)

cr0x@server:~$ zpool list -o name,alloc,free,frag,cap,health
NAME   ALLOC   FREE  FRAG  CAP  HEALTH
tank   92.1T  28.7T   41%  76%  DEGRADED

Signification : 41% de fragmentation transformera « copier les blocs alloués » en beaucoup de seeks.

Décision : Frag élevé + résilver lent : réduisez la charge, attendez‑vous à une fenêtre plus longue ; envisagez une refonte future (plus de vdevs, recordsize différent, garder des pools moins pleins).

Task 10: Check ashift (alignment) of the vdev

cr0x@server:~$ zdb -C tank | egrep "vdev|ashift" | head -n 20
        vdev_tree:
            type: 'raidz'
            id: 0
            guid: 9876543210123456789
            ashift: 12
            nparity: 2

Signification : ashift 12 signifie alignement 4K. Bon pour HDD/SSD modernes. ashift 9 sur du 4K‑native/512e est une erreur classique.

Décision : Si ashift est mauvais, ne « tunez » pas pour vous en sortir. Planifiez une migration correcte vers un pool recréé correctement.

Task 11: Confirm recordsize / volblocksize for key datasets (impacts layout and resilver behavior)

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,volblocksize tank/vm tank/home
NAME      PROPERTY     VALUE
tank/vm   volblocksize 16K
tank/home recordsize   128K

Signification : Zvols VM en 16K peuvent être gourmands en seeks ; dataset home en 128K est plus favorable au séquentiel.

Décision : Si les résilvers sont chroniquement lents sur des pools VM‑lourds, envisagez des vdevs spéciaux (métadonnées), plus de vdevs, ou des miroirs pour les niveaux IOPS‑sensibles.

Task 12: Pause competing work: locate top I/O consumers

cr0x@server:~$ sudo iostat -x 5 2
Linux 6.5.0 (server)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.41    0.00    6.32   18.77    0.00   62.50

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda             98.1    22.4  39512    6821   28.4   3.1   95.2
sdb             11.3    21.9   1290    6720  412.7  10.2   99.8
sdz            210.4    18.2  67711    5812   16.9   2.7   89.4

Signification : sdb a 400ms d’attente et 99.8% d’utilisation en faisant de petites lectures. C’est le rameur avec la gueule de bois.

Décision : Si la latence d’un disque est extrême, n’attendez pas qu’il « récupère ». Remplacez‑le ou réparez son chemin ; sinon, votre résilver sera un désastre au ralenti.

Task 13: Find checksum errors at the dataset level (silent corruption surfacing)

cr0x@server:~$ zpool status -v tank | sed -n '/errors:/,$p'
errors: Permanent errors have been detected in the following files:

        tank/home@daily-2025-12-25:/documents/finance.xlsx

Signification : Vous avez au moins une erreur permanente : ZFS n’a pas pu réparer ce bloc à partir de la redondance.

Décision : Déclenchez la réponse incident : identifiez les propriétaires de données affectés, restaurez depuis sauvegarde/snapshot ou réplication, et réévaluez le niveau de redondance et la cadence des scrubs.

Task 14: Start a scrub after the resilver (validation pass)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -A3 "scan:"
  scan: scrub in progress since Fri Dec 26 09:02:11 2025
        1.34T scanned at 620M/s, 410G issued at 190M/s, 120T total
        0B repaired, 0.34% done, 178:22:10 to go

Signification : Le scrub est plus lent sur de grands pools ; « repaired » restant à 0 est bon, mais le « to go » importe pour la planification.

Décision : Si le scrub révèle de nouvelles erreurs, considérez cela comme une instabilité média/chemin persistante — ne déclarez pas victoire parce que le résilver s’est terminé.

Trois mini‑récits d’entreprise (anonymisés, plausibles, douloureux)

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

Une entreprise SaaS de taille moyenne gérait un pool ZFS unique pour « tout ce qui n’est pas dans la base de données ». C’était en RAIDZ1 parce que quelqu’un se souvenait
que RAIDZ2 « gaspille trop d’espace », et les tableurs aiment gagner les débats.

Un disque est tombé un vendredi soir. L’astreinte l’a remplacé et a regardé la barre de progression du résilver. Elle avançait, lentement.
L’équipe a supposé que le seul risque était « un autre disque doit tomber », ce qui semblait peu probable pendant le week‑end.
Ils ont laissé le pool servir la production complète parce que « les clients ne peuvent pas avoir de downtime ».

Douze heures plus tard, ZFS a commencé à logger des erreurs de somme de contrôle sur un autre disque. SMART affichait « PASSED », donc l’équipe a écarté l’alerte comme du bruit.
Le résilver a continué. Puis le second disque a jeté une série de secteurs illisibles exactement sur les blocs nécessaires pour reconstruire les données du disque manquant.
RAIDZ1 n’avait pas de parité supplémentaire pour contourner cela. Le vdev a planté suffisamment fort pour que le pool ne soit plus fiable.

La mauvaise hypothèse n’était pas « un second disque ne tombera pas ». Elle était plus subtile : « si le pool est encore online, on est OK. »
ZFS continue d’essayer jusqu’à ce qu’il ne puisse plus. Être online n’est pas la même chose qu’être sûr.

Leur récupération a été un mélange chaotique : restauration depuis des backups objet pour la plupart des données, acceptation de pertes pour quelques locataires,
et un mois passé à reconstruire le stockage en RAIDZ2 avec une politique de scrub plus stricte. Le postmortem fut sans détour :
« Nous avons traité la parité comme une assurance, puis nous avons annulé la police le seul week‑end où nous en avions besoin. »

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

Une plateforme analytics interne utilisait un pool ZFS pour une ferme de VMs. Des plaintes de performance sont arrivées : pics de latence en écriture,
stalls occasionnels pendant les snapshots. Un ingénieur bien intentionné a optimisé pour le débit : vdevs RAIDZ plus larges (parce que « plus de disques = plus rapide »),
compression agressive sur tout, et recordsize plus grand sur les datasets parce que « les gros IO sont efficients ».

En benchs, ça avait l’air super. Les lectures séquentielles ont décollé. Les plaintes ont diminué. Tout le monde a passé à autre chose.
Six mois plus tard, un disque a lâché. Le résilver fut glacial. Pas des « heures », mais des « jours », même si le pool n’était pas presque plein.

Le piège : la charge était majoritairement de petites lectures/écritures aléatoires des VMs, avec churn de métadonnées et snapshots fréquents.
Le vdev large impliquait plus de disques dans chaque opération de reconstruction. La compression a augmenté le travail CPU pendant le résilver
au moment où le système faisait déjà de la parité et de la vérification de somme de contrôle. Et le grand recordsize, mal adapté, a accru l’amplification d’écriture et la fragmentation.

Pendant le long résilver, un second disque a commencé à subir des timeouts — pas mort, juste lent et chaud. Le contrôleur a logué des resets.
L’équipe a dû limiter toute la grappe VM pour laisser le résilver avancer, ce qui a quand même créé un incident visible pour les clients.
Ils avaient optimisé le chemin heureux et rendu le chemin de défaillance insupportable.

Après coup, ils ont redesigné : vdevs plus petits et plus nombreux ; RAIDZ2 ; tuning dataset réfléchi (les VMs traitées différemment du stockage en masse) ;
et une règle selon laquelle tout changement de performance doit inclure « que se passe‑t‑il pendant un résilver » comme critère d’acceptation.
L’optimisation n’a pas échoué parce qu’elle était stupide. Elle a échoué parce qu’elle ignorait la mathématique de récupération.

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

Une équipe d’entreprise conservatrice gérait le stockage pour une plateforme interne riche en fichiers. Rien de glamour : beaucoup de documents, artefacts de build,
quelques gros datasets qui croissaient régulièrement. Ils avaient la réputation de dire « non » aux raccourcis excitants.

Leur design était volontairement peu remarquable : vdevs RAIDZ2 de largeur modérée, hot spares disponibles, tests SMART longs mensuels,
et scrubs à une cadence correspondant à leur domaine de défaillance. Ils maintenaient aussi une cible stricte d’utilisation : quand les pools s’en approchaient,
le travail d’extension de capacité était budgété et ticketé comme toute autre tâche de production.

Quand un disque a lâché, l’astreinte a suivi le runbook : capturer zpool status -v, zpool events -v, et dmesg -T,
réduire les jobs batch non essentiels, remplacer le disque, surveiller le résilver, puis lancer un scrub. Le résilver a fini en heures, pas en jours, parce que le pool avait de la marge et peu de fragmentation.

Une semaine plus tard, un autre disque montrait des secteurs pending en hausse. Il n’était pas encore mort. Ils l’ont remplacé proactivement pendant une fenêtre de maintenance.
Pas d’indisponibilité. Pas de drame. Le « coût » a été quelques disques en plus et du temps sur le calendrier. C’est pas cher.

Ce qui les a sauvés n’était pas un flag magique de ZFS. C’était la discipline de traiter le stockage comme un système qui doit rester récupérable,
pas seulement rapide. Leur pratique ennuyeuse a empêché l’incident excitant.

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

1) Le résilver est « bloqué » à un faible pourcentage

Symptôme : « resilver in progress… 2% done… time remaining: days » bouge à peine.

Cause racine : Fragmentation sévère, charge IO aléatoire lourde, ou un disque lent unique qui bride les débits de lecture.

Correctif : Identifiez le disque lent via zpool iostat -v et iostat -x ; réduisez la charge ; remplacez le disque suspect ; maintenez les pools moins pleins à long terme.

2) CKSUM en hausse sur un disque « ONLINE » pendant le résilver

Symptôme : zpool status montre des incréments CKSUM sur un périphérique survivant.

Cause racine : Erreurs média réelles ou (très souvent) chemin instable : resets de lien SAS, câble défectueux, problèmes d’expander.

Correctif : Vérifiez dmesg pour resets/timeouts ; contrôlez les compteurs SMART CRC ; reseat/remplacez les câbles ; mettez à jour le firmware HBA ; remplacez le disque si des secteurs pending ou des erreurs medium apparaissent.

3) Le pool devient FAULTED pendant une reconstruction RAIDZ1

Symptôme : Après un second problème « mineur », le pool devient indisponible ou signale des erreurs permanentes.

Cause racine : RAIDZ1 n’avait aucune marge ; une URE ou une seconde panne périphérique/chemin a rendu certains blocs irréparables.

Correctif : Restaurer depuis sauvegardes/snapshots ; reconstruire en RAIDZ2 ou miroirs ; augmenter la cadence des scrubs ; arrêter d’utiliser RAIDZ1 pour de grands vdevs HDD en production.

4) La reconstruction est lente seulement sur un châssis / shelf

Symptôme : Des pools similaires ailleurs reconstruisent plus vite ; celui‑ci traîne toujours.

Cause racine : Backplane/expander goulot, throttling thermique, ou câblage défectueux localisé à cette baie.

Correctif : Comparez les logs d’erreur entre hôtes ; échangez les câbles ; déplacez un disque sain pour reproduire ; vérifiez les températures ; validez la compatibilité firmware de l’expander.

5) Les scrubs trouvent toujours « quelques erreurs », mais personne ne s’en soucie

Symptôme : Réparations de checksum régulières ou erreurs permanentes occasionnelles sont banalisées.

Cause racine : Dégradation média sous‑jacente ou chemin IO instable ; le scrub joue le rôle de canari.

Correctif : Traitez les réparations de scrub comme des incidents avec seuils ; remplacez les disques suspects ; validez le câblage ; assurez‑vous que le niveau de redondance peut supporter la réalité.

6) Plus de tuning a empiré le résilver

Symptôme : Après un « tuning performance », le résilver prend plus de temps et la latence monte.

Cause racine : Tuning qui augmente l’amplification IO ou la charge CPU ; vdevs plus larges ; recordsize inapproprié ; trop de compression/chiffrement sans marge.

Correctif : Annulez les changements ; réévaluez avec des tests axés sur le chemin de panne ; concevez pour la reconstruction, pas seulement pour les tableaux de bord.

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

Quand un disque tombe (RAIDZ) : le runbook incident

1. Geler la scène : capturez zpool status -v, zpool events -v, et dmesg -T pour la chronologie.
2. Confirmer la redondance restante : RAIDZ1 dégradé = marge zéro. RAIDZ2 dégradé = une marge. Ajustez l’urgence selon le cas.
3. Vérifier un second disque faible : lancez SMART sur tous les disques du vdev, au moins les suspects usuels (même modèle, même baie, même chaîne d’expander).
4. Stabiliser le chemin : erreurs CRC ou resets de lien signifient : corrigez le câblage/HBA avant d’épuiser d’autres disques.
5. Remplacer correctement le périphérique : utilisez zpool replace avec des IDs persistants ; évitez le roulette des noms /dev/sdX.
6. Réduire la charge concurrente : mettez en pause les jobs batch lourds, ralentissez les migrations de VMs, reportez les sauvegardes qui frappent fort le pool.
7. Surveiller le taux de résilver et les erreurs : guettez la croissance des CKSUM et le ralentissement du débit qui signalent une seconde panne en formation.
8. Après le résilver, scrub : validez le pool et faites émerger la corruption latente tant que vous avez encore de la redondance.
9. Faire une revue post‑incident capacité/design : si le résilver a pris « trop longtemps », c’est un problème de conception, pas de la malchance.

Checklist de conception : construire un RAIDZ qui survit à la mathématique de reconstruction

1. Privilégiez RAIDZ2 pour les grands vdevs HDD : considérez RAIDZ1 comme réservé à l’archivage ou aux petits disques où la fenêtre d’exposition est courte.
2. Gardez une largeur de vdev raisonnable : les vdevs plus larges augmentent le fan‑out de lecture et la concentration du risque.
3. Maintenez les pools sous une cible d’utilisation : planifiez 70–80% comme « normal », pas « gaspillé ».
4. Programmez les scrubs à une cadence explicable : assez fréquent pour détecter les erreurs latentes avant une panne ; pas si fréquent qu’ils noient la prod.
5. Standardisez les noms de périphérique persistants : chemins by‑id, pas /dev/sdX.
6. Testez le comportement de résilver : en staging, simulez un remplacement de disque et mesurez le temps de reconstruction avec vos charges typiques.
7. Gardez des spares physiques et des personnes compétentes : un hot spare est bien ; une personne qui connaît la procédure est mieux.

FAQ

1) Le résilver RAIDZ est‑il plus sûr que les reconstructions RAID classiques ?

Souvent plus sûr parce que ZFS a des sommes de contrôle bout en bout et peut résilver seulement les blocs alloués, pas chaque LBA.
Mais RAIDZ1 dégradé reste sur un fil : une panne additionnelle (disque, chemin, ou secteur illisible) peut arrêter le vdev.

2) Pourquoi « scanned » dépasse « issued » dans zpool status ?

« Scanned » est la quantité que ZFS a examinée ; « issued » est l’IO réellement envoyé pour le résilver. Le scan peut inclure la traversée de métadonnées et du travail qui ne se traduit pas 1:1 en écritures.
Si le taux issued est faible, vous êtes souvent limité par de l’IO aléatoire, de la contention, ou un disque lent.

3) Dois‑je monter la priorité du résilver pour finir plus vite ?

Parfois, mais seulement avec intention. Si vous affamez trop l’IO de production, vous pouvez déclencher des timeouts et des pannes secondaires.
La démarche la plus sûre est de réduire d’abord la charge (pause batch, drain de VMs), puis tuner si nécessaire.

4) RAIDZ2 garantit‑il que je ne perdrai pas de données pendant la reconstruction ?

Non. Il tolère deux pannes de disque dans un vdev, mais il ne vous protège pas contre : bugs firmware, erreurs d’opérateur, mauvais câblage, resets de contrôleur affectant plusieurs disques,
ou trois pannes simultanées. Il rend juste le « mauvais jour » courant survivable.

5) Quelle largeur pour un vdev RAIDZ2 ?

Il n’y a pas un nombre magique. Opérationnellement, une « largeur raisonnable » signifie : le temps de reconstruction est acceptable, et la latence d’un disque unique ne domine pas.
Pour les pools HDD, de nombreuses équipes choisissent des vdevs RAIDZ2 de largeur modérée plutôt que des monstres ultra‑larges. Mesurez votre charge.

6) Pourquoi mon résilver a‑t‑il ralenti à 60% alors qu’il était plus rapide à 10% ?

Les phases initiales peuvent toucher des régions plus séquentielles ou des métadonnées en cache. Les phases ultérieures rencontrent plus d’allocations fragmentées, des données plus froides et des blocs plus petits.
Aussi, d’autres charges peuvent remonter quand les gens supposent « c’est presque fini ».

7) Si SMART indique PASSED, le disque est‑il OK ?

Non. Le statut global SMART est un résumé grossier. Regardez les secteurs pending, offline uncorrectables, et les erreurs CRC.
Un disque peut « PASS » tout en sabotant activement votre résilver.

8) Dois‑je scrubber plus souvent ou moins souvent ?

Plus souvent que « jamais », moins souvent que « constamment ». L’objectif est de faire émerger les erreurs latentes tant que vous avez encore de la redondance et avant qu’une panne force un résilver.
Si les scrubs impactent la prod, planifiez‑les et contrôlez la charge ; ne les abandonnez pas.

9) Miroirs vs RAIDZ pour le risque de reconstruction — quel est le compromis ?

Les miroirs résilverent en copiant d’un disque survivant vers le disque de remplacement, typiquement plus vite et avec moins de fan‑out de lecture.
RAIDZ a une meilleure efficacité de capacité mais un rayon d’impact de reconstruction plus large. Si votre charge est IOPS‑sensibles ou que votre objectif de RTO est strict, les miroirs gagnent souvent.

10) Puis‑je simplement « ajouter un disque de plus » à un vdev RAIDZ pour réduire le risque ?

Le risque dépend surtout du niveau de parité, du temps d’exposition à la reconstruction et du comportement des erreurs. Ajouter des disques peut augmenter le débit, mais aussi élargir le domaine de défaillance.
Si vous avez besoin de plus de sécurité, augmentez la parité (RAIDZ2/3) ou changez la topologie des vdevs — pas seulement la largeur.

Prochaines actions à mener cette semaine

Si vous exécutez RAIDZ en production, traitez la mathématique du résilver comme un budget. Vous dépensez de la sécurité à chaque heure passée en dégradé.
Le travail consiste à raccourcir la fenêtre et augmenter la marge.

1. Auditez le niveau de parité : repérez tous les vdevs RAIDZ1 qui soutiennent des données importantes. Si les disques sont de grands HDD, planifiez une migration vers RAIDZ2 ou des miroirs.
2. Mesurez le temps réel de résilver : pas les MB/s du constructeur. Faites un exercice de remplacement contrôlé en staging ou sur un pool non critique et enregistrez les temps.
3. Définissez cadence et seuils de scrub : décidez quel nombre de réparations/erreurs de checksum déclenche le remplacement de disque ou l’inspection du câblage.
4. Vérifiez l’occupation du pool et la fragmentation : si vous vivez au‑dessus de 80%, vous choisissez des reconstructions plus longues et plus risquées.
5. Renforcez le trivial : noms de périphériques persistants, disques de rechange, firmware validé, et runbooks qui n’assument pas des super‑héros.

Le jour où vous perdez des données n’est généralement pas le jour où le premier disque a lâché. C’est le jour où vous découvrez que vos hypothèses de reconstruction étaient des fantasmes.
Rendre les mathématiques réelles maintenant, tant que vous pouvez encore choisir la forme de votre panne.