Panne du vdev spécial ZFS : comment survivre au pire scénario

Ce qu’est vraiment un vdev spécial (et pourquoi il est différent)

Un vdev spécial est une classe d’allocation dans ZFS conçue pour contenir les métadonnées et (optionnellement) les petits blocs de fichiers.
Ce n’est pas un cache. Ce n’est pas un tampon d’écriture. Ce n’est pas un « niveau SSD agréable à avoir ».
C’est du stockage réel du pool, qui participe aux règles de redondance — sauf que beaucoup de gens le configurent comme un disque scratch.

Vdev spécial : ce qu’il stocke

• Métadonnées : pointeurs de blocs, blocs indirects, dnodes, structures de répertoires, spacemaps, etc.
• Éventuellement petits blocs : selon special_small_blocks, les données de petits fichiers peuvent être placées sur le spécial.
• Ce n’est pas un cache : contrairement à L2ARC, les données sur le spécial sont autoritaires et nécessaires si elles y sont allouées.

La partie qui fait mal : la permanence d’allocation

Une fois qu’un bloc est alloué sur un vdev spécial, il y reste jusqu’à ce qu’il soit réécrit ailleurs.
Si vous perdez la seule copie, ZFS ne peut pas la « reconstruire » depuis des disques plus lents. Il n’existe pas de magie « reconstruire les métadonnées depuis la parité »
si les métadonnées n’ont jamais existé sur les vdevs principaux.

Les pannes de vdev spécial sont brutales parce que les métadonnées sont la carte. Perdre la carte signifie que vous pouvez avoir le territoire (vos blocs de données)
et ne pas savoir comment y accéder.

Faits intéressants et contexte historique (parce que le passé se répète)

1. Les classes d’allocation sont arrivées plus tard : les vdevs spéciaux sont apparus après que ZFS avait déjà établi sa réputation, donc beaucoup d’anciens documents « bonnes pratiques ZFS » les ignorent.
2. La fonction vient de douleurs réelles : de grands pools sur disque avec de petits fichiers étaient rapides en streaming, lents pour « ls -lR », et les ops ont exigé une solution autre que « achetez plus de RAM ».
3. ZFS a toujours traité les métadonnées comme prioritaires : checksums, copy-on-write et auto-réparation visaient à protéger la structure autant que le contenu.
4. On le confond avec SLOG : parce que ce sont deux « appareils rapides que l’on ajoute », mais SLOG concerne les écritures sync ; special concerne le placement persistant.
5. Les spacemaps comptent : ZFS moderne utilise des spacemaps pour suivre l’espace libre ; si le spécial contient des spacemaps critiques et qu’il meurt, l’importation du pool peut devenir impossible.
6. L’offload des petits blocs est devenu populaire avec la virtualisation : images VM et couches de conteneurs produisent beaucoup de métadonnées et d’IO aléatoire ; les vdevs spéciaux réduisent souvent fortement la latence.
7. Les domaines de défaillance se sont complexifiés : avec les vdevs spéciaux, votre pool peut être « RAIDZ2 » sur HDD et « SSD unique » pour les métadonnées. La vraie redondance du pool devient alors « SSD unique ».
8. L’endurance est une contrainte réelle : métadonnées et petits blocs subissent beaucoup d’écritures ; les SSD grand public ont souvent rendu l’âme prématurément en duty spécial, surtout avec atime ou charges bavardes.

Une règle sèche : si vous seriez mal à l’aise de stocker votre superbloc de système de fichiers sur un seul appareil, ne stockez pas non plus vos métadonnées ZFS de cette façon.

Scénarios cauchemardesques : que se passe-t-il réellement quand ça casse

Scénario A : le vdev spécial est dégradé, le pool s’importe toujours, tout est lent et bizarre

C’est le cas « chanceux ». Un appareil dans un special mirror est en train de lâcher mais pas encore mort.
Les lectures peuvent être réessayées, la latence pique, ZFS commence à lancer des erreurs de checksum, et votre application commence à timeouter.
La plupart des équipes perdent du temps à blâmer le réseau, puis l’hyperviseur, puis la base de données. Pendant ce temps, les lectures de métadonnées moulinent dans un SSD mourant.

Scénario B : le vdev spécial a disparu, le pool ne s’importe pas

Si le spécial était sur un seul disque (ou que le mirror a perdu trop de membres), vous pouvez vous retrouver avec un pool inimportable.
ZFS peut signaler des appareils manquants, ou pire : il « importe » mais les datasets échouent à se monter ou la traversée des répertoires renvoie des erreurs I/O.
À ce stade vous n’êtes plus en train de remplacer un disque. Vous faites de la réponse à incident avec une trousse de chirurgie filesystem.

Scénario C : le pool se suspend pendant des IO

ZFS peut suspendre un pool lorsqu’il détecte des erreurs suffisamment graves que continuer risquerait une corruption supplémentaire.
Vous verrez « pool I/O is currently suspended » et les services tomberont en masse.
Considérez cela comme un frein de sécurité, pas comme une nuisance.

Blague #1 : Un pool suspendu, c’est ZFS qui dit : « Je peux continuer, mais je préfère ne pas être tenu pour responsable plus tard. » C’est le logiciel le plus responsable dans votre baie.

Scénario D : vous « réparez » et les performances ne reviennent jamais

Parfois la récupération réussit mais le pool fonctionne désormais avec les métadonnées sur HDD parce que vous avez retiré le spécial ou parce qu’il n’est plus utilisé efficacement.
Le système est « up », mais les utilisateurs se plaignent que l’interface ressemble à une page rendue sur une connexion commutée. Vous avez survécu au feu ; maintenant vous vivez dans la fumée.

Ce qui détermine l’ampleur des dégâts

• Redondance du vdev spécial : miroir vs simple ; largeur du mirror ; qualité des appareils.
• Quantité allouée au spécial : uniquement métadonnées, ou métadonnées plus petits blocs.
• Durée de fonctionnement en état dégradé : les réessais et la corruption s’empilent ; le temps de resilver augmente.
• Hygiène opérationnelle : scrubs, alertes, disques de spare, et procédures de récupération documentées.

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

C’est l’ordre qui coupe souvent la confusion. L’objectif est de répondre rapidement à trois questions :
« Le pool est-il sain ? » « Le vdev spécial est-il impliqué ? » « Quelle est l’action la plus rapide et sûre ? »

Premier : confirmer la santé du pool et identifier l’état du spécial

• Exécuter zpool status -v et regarder spécifiquement les vdevs de classe special et les compteurs d’erreurs.
• Vérifier si le pool est SUSPENDED, DEGRADED ou FAULTED.
• Scanner dmesg/logs système pour des resets NVMe, timeouts ou enlèvements d’appareil.

Second : déterminer le rayon d’impact (métadonnées seulement vs petits blocs aussi)

• Vérifier zfs get special_small_blocks sur les datasets principaux.
• Rechercher les symptômes : listes de répertoires lentes (métadonnées), ou lectures de petits fichiers échouant (petits blocs sur special).
• Vérifier les flags de fonctionnalités du pool et si le spécial est requis pour l’import (généralement oui si des blocs y sont alloués).

Troisième : choisir une voie d’action sûre

• Si le spécial est en mirror et qu’un seul appareil a échoué : remplacer immédiatement, puis scrub, puis surveiller le resilver.
• Si le spécial est en simple et qu’il est mort : arrêtez l’improvisation. Décidez entre restaurer depuis la sauvegarde, tenter de récupérer l’appareil, ou essais d’import forensiques spécialisés.
• Si le pool est suspendu : stabiliser le hardware, exporter si possible, et planifier une importation contrôlée ; ne le marteler pas avec des retries applicatifs.

La seule « réparation rapide » est celle qui n’aggrave pas la récupération. Beaucoup d’équipes perdent le pool en effectuant des écritures frénétiques pendant une panne de métadonnées.

Tâches de récupération pratiques (commandes, sorties, décisions)

Ci-dessous se trouvent des tâches pratiques que vous pouvez exécuter sur un hôte Linux avec OpenZFS. Les commandes sont réelles. Les sorties sont représentatives.
L’important n’est pas la formulation exacte ; c’est ce que vous en déduisez et ce que vous faites ensuite.

Task 1: Identify the failure and confirm it’s special

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 0 days 00:19:21 with 0 errors on Thu Dec 26 01:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-HDD1                ONLINE       0     0     0
            ata-HDD2                ONLINE       0     0     0
            ata-HDD3                ONLINE       0     0     0
            ata-HDD4                ONLINE       0     0     0
            ata-HDD5                ONLINE       0     0     0
            ata-HDD6                ONLINE       0     0     0
        special
          mirror-1                  DEGRADED     7     0   118
            nvme-SAMSUNG_SSD_A      FAULTED     7     0   118  too many errors
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : le pool est dégradé parce qu’un appareil dans la classe special est faulted.
Les lectures/erreurs CKSUM sur special sont particulièrement sérieuses car c’est là que résident les métadonnées.

Décision : remplacer le NVMe fautif immédiatement. Ne « attendez pas la fenêtre de maintenance ». Vous y êtes déjà.

Task 2: Check if the pool is suspended

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
action: The pool can be imported using its name or numeric identifier.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0

Ce que cela signifie : pas de suspension ici. Si vous aviez vu state: SUSPENDED, cela change le jeu : arrêter les IO, stabiliser, et planifier une récupération contrôlée.

Décision : continuer avec le remplacement et le resilver en limitant la charge, mais vous n’avez pas encore besoin de manœuvres d’export/import d’urgence.

Task 3: Correlate with kernel errors (timeouts/resets)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Thu Dec 26 02:14:03 2025] nvme nvme1: I/O 123 QID 6 timeout, completion polled
[Thu Dec 26 02:14:03 2025] nvme nvme1: Abort status: 0x371
[Thu Dec 26 02:14:04 2025] nvme nvme1: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10
[Thu Dec 26 02:14:06 2025] nvme nvme1: Removing after probe failure status: -19

Ce que cela signifie : l’appareil a disparu ou a redémarré à répétition. Ce n’est pas un « bug ZFS ». C’est de l’instabilité hardware/firmware/PCIe/alimentation.

Décision : traiter l’appareil comme non fiable même s’il revient après un reboot. Remplacez-le ; ne lui faites pas à nouveau confiance pour des métadonnées.

Task 4: Identify by-id names (avoid the wrong disk problem)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'nvme-SAMSUNG_SSD_A|nvme-SAMSUNG_SSD_B'
lrwxrwxrwx 1 root root 13 Dec 26 01:59 nvme-SAMSUNG_SSD_A -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Dec 26 01:59 nvme-SAMSUNG_SSD_B -> ../../nvme0n1

Ce que cela signifie : vous avez des identifiants stables. Bien. Si vous n’utilisez que /dev/nvme1n1, vous êtes à un reboot de remplacer le mauvais disque.

Décision : effectuer toutes les opérations ZFS en utilisant les chemins /dev/disk/by-id.

Task 5: Confirm dataset policy for small blocks (blast radius check)

cr0x@server:~$ sudo zfs get -r -o name,property,value special_small_blocks tank
NAME                 PROPERTY              VALUE
tank                 special_small_blocks  0
tank/vm              special_small_blocks  16K
tank/home            special_small_blocks  0
tank/containers      special_small_blocks  8K

Ce que cela signifie : certains datasets placent de petits blocs de fichiers sur special (vm, containers).
Une perte du vdev spécial ici n’est pas juste une « gêne métadonnées ». Elle peut emporter de vrais contenus de fichiers.

Décision : prioriser la récupération pour ces datasets ; envisager plus tard une redondance plus stricte et des seuils conservateurs.

Task 6: Check whether special devices are mirrored (they should be)

cr0x@server:~$ sudo zpool status tank | sed -n '/special/,$p'
        special
          mirror-1                  DEGRADED     7     0   118
            nvme-SAMSUNG_SSD_A      FAULTED     7     0   118  too many errors
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : vdev spécial en miroir. Vous avez encore une copie des métadonnées. Vous êtes en « mode réparation », pas en « mode forensique ».

Décision : remplacer le membre défaillant et résilver ASAP, tout en protégeant le SSD survivant (surveiller températures, queue depth, erreurs).

Task 7: Replace the failed special device

cr0x@server:~$ sudo zpool replace tank nvme-SAMSUNG_SSD_A /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
cannot open 'nvme-SAMSUNG_SSD_A': no such device in pool

Ce que cela signifie : vous avez utilisé la mauvaise chaîne d’identification. ZFS veut le token vdev exactement tel qu’il apparaît dans zpool status, ou le chemin GUID.

Décision : copier-coller le token exact depuis zpool status ou utiliser zpool status -g pour référencer le GUID en toute sécurité.

cr0x@server:~$ sudo zpool status -g tank | sed -n '/special/,$p'
        special
          mirror-1                  DEGRADED
            12293847561234567890    FAULTED  too many errors
            99887766554433221100    ONLINE

Ce que cela signifie : les GUIDs sont disponibles. Cela évite l’ambiguïté si les chemins d’appareil ont changé.

Décision : remplacer par GUID.

cr0x@server:~$ sudo zpool replace tank 12293847561234567890 /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
invalid vdev specification
use '-f' to override the following errors:
/dev/disk/by-id/nvme-SAMSUNG_SSD_NEW is part of potentially active pool 'rpool'

Ce que cela signifie : le nouveau périphérique contient d’anciennes étiquettes ZFS (peut-être provenant d’un autre hôte, ou déjà utilisé).
C’est courant avec les « disques de stock ».

Décision : effacer les labels ZFS sur le nouveau disque avec précaution, puis retenter le remplacement.

Task 8: Wipe old labels on the replacement disk (carefully)

cr0x@server:~$ sudo zpool labelclear -f /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW

Ce que cela signifie : le label a été effacé avec succès (la commande est silencieuse en cas de succès).

Décision : poursuivre avec zpool replace.

cr0x@server:~$ sudo zpool replace tank 12293847561234567890 /dev/disk/by-id/nvme-SAMSUNG_SSD_NEW
cr0x@server:~$ sudo zpool status tank | sed -n '/scan/,$p'
  scan: resilver in progress since Thu Dec 26 02:21:12 2025
        19.2G scanned at 1.12G/s, 2.88G issued at 170M/s, 19.2G total
        2.90G resilvered, 14.98% done, 0:01:12 to go
config:

        NAME                          STATE     READ WRITE CKSUM
        tank                          DEGRADED     0     0     0
          raidz2-0                    ONLINE       0     0     0
            ata-HDD1                  ONLINE       0     0     0
            ata-HDD2                  ONLINE       0     0     0
            ata-HDD3                  ONLINE       0     0     0
            ata-HDD4                  ONLINE       0     0     0
            ata-HDD5                  ONLINE       0     0     0
            ata-HDD6                  ONLINE       0     0     0
        special
          mirror-1                    DEGRADED     0     0     0
            replacing-0               DEGRADED     0     0     0
              12293847561234567890    FAULTED     0     0     0  too many errors
              nvme-SAMSUNG_SSD_NEW    ONLINE       0     0     0  (resilvering)
            99887766554433221100      ONLINE       0     0     0

Ce que cela signifie : le resilver est en cours ; ZFS reconstruit la réplique manquante sur le nouveau SSD.
Pendant cette fenêtre, le SSD survivant est votre seule bonne copie des métadonnées. Protégez-le.

Décision : réduire la charge si possible, éviter les reboots, et surveiller les erreurs IO sur l’appareil survivant.

Task 9: Monitor resilver completion and error counts

cr0x@server:~$ watch -n 10 'sudo zpool status tank'
  pool: tank
 state: ONLINE
  scan: resilvered 19.2G in 0 days 00:03:18 with 0 errors on Thu Dec 26 02:24:30 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-HDD1                ONLINE       0     0     0
            ata-HDD2                ONLINE       0     0     0
            ata-HDD3                ONLINE       0     0     0
            ata-HDD4                ONLINE       0     0     0
            ata-HDD5                ONLINE       0     0     0
            ata-HDD6                ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme-SAMSUNG_SSD_NEW    ONLINE       0     0     0
            nvme-SAMSUNG_SSD_B      ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : le resilver s’est terminé proprement. Vous avez de nouveau de la redondance.

Décision : maintenant scrub et valider ; ne pas déclarer victoire sur un resilver seul.

Task 10: Run a scrub to confirm end-to-end checksums

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,18p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 02:27:01 2025
        412G scanned at 1.88G/s, 64.1G issued at 291M/s, 2.41T total
        0B repaired, 2.59% done, 0 days 02:19:31 to go

Ce que cela signifie : le scrub lit et vérifie les checksums sur tout le pool, réparant depuis la redondance si possible.

Décision : laisser terminer. S’il rapporte des réparations, investiguez la cause (câble défectueux, contrôleur instable, disque mourant).

Task 11: Check SMART/NVMe health for the surviving and new devices

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'critical_warning|media_errors|percentage_used|data_units_written'
Critical Warning:                   0x00
Percentage Used:                   12%
Media and Data Integrity Errors:   0
Data Units Written:                9,812,334

Ce que cela signifie : pas d’alerte critique, usure faible, pas d’erreurs média. Ce SSD semble sain.

Décision : le garder. Si Media and Data Integrity Errors ou Critical Warning sont non-zéro, planifier un remplacement même si ZFS est pour l’instant satisfait.

Task 12: Measure whether metadata is the bottleneck (latency triage)

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         1.2T  1.1T    820    410  62.1M  28.4M
  raidz2-0                   1.2T  1.1T    120    360  51.2M  26.9M
    ata-HDD1                    -      -     20     60  8.40M  4.60M
    ata-HDD2                    -      -     19     60  8.22M  4.58M
    ata-HDD3                    -      -     21     60  8.62M  4.56M
    ata-HDD4                    -      -     20     60  8.51M  4.51M
    ata-HDD5                    -      -     20     60  8.70M  4.54M
    ata-HDD6                    -      -     20     60  8.75M  4.55M
special                         -      -    700     50  10.9M  1.50M
  mirror-1                      -      -    700     50  10.9M  1.50M
    nvme-SAMSUNG_SSD_NEW         -      -    350     25  5.40M  0.76M
    nvme-SAMSUNG_SSD_B           -      -    350     25  5.50M  0.74M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : un nombre d’opérations élevé sur special par rapport à la bande passante suggère des IO riches en métadonnées (beaucoup de petites lectures aléatoires).
C’est normal pour les scans de répertoires, les conteneurs, ou la forte churn des métadonnées.

Décision : si la latence du special est élevée ou génère des erreurs, réparer le special d’abord. Si le special est sain mais que le raidz est saturé, le goulot est ailleurs.

Task 13: Confirm special vdev usage and metadata pressure

cr0x@server:~$ sudo zdb -bbbs tank | sed -n '1,24p'
Dataset tank [ZPL], ID 53, cr_txg 5, 3.12T, 2 objects
Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
     1    2   128K    16K  3.20K    512   16.0K  100.0  DMU dnode
    17    1   128K    16K  3.20K    512   16.0K  100.0  ZAP

Ce que cela signifie : zdb peut vous montrer les structures de métadonnées et leurs tailles. Ce n’est pas un outil quotidien, mais utile pour prouver « ce workload est riche en métadonnées ».

Décision : si votre environnement est dominé par de petits fichiers/métadonnées VM, dimensionnez le special en conséquence et miroirisez-le comme il se doit.

Task 14: If import fails, list importable pools and missing devices

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing devices and try again.
   see: zpool-import(8)
config:

        tank                        UNAVAIL  missing device
          raidz2-0                  ONLINE
            ata-HDD1                ONLINE
            ata-HDD2                ONLINE
            ata-HDD3                ONLINE
            ata-HDD4                ONLINE
            ata-HDD5                ONLINE
            ata-HDD6                ONLINE
        special
          nvme-SAMSUNG_SSD_A         UNAVAIL

Ce que cela signifie : le pool est indisponible parce que l’appareil du special est manquant. Si ce special était sur un seul disque, c’est aussi sérieux que ça en a l’air.

Décision : n’essayez pas des imports forcés aléatoires avec -f. Votre meilleure option est de récupérer ce chemin d’appareil (fixer le hardware) ou basculer sur une sauvegarde/réplication.

Task 15: If the pool is suspended, confirm and stop churn

cr0x@server:~$ sudo zpool status -x
pool 'tank' is suspended

Ce que cela signifie : ZFS a mis les IO en pause pour protéger l’intégrité. Vos applications vont continuer à réessayer et empirer la situation.

Décision : arrêter les services à fort volume, mettre l’hôte en quarantaine si nécessaire, et travailler sur la récupération du stockage sans une horde d’IO.

Task 16: Verify special vdev is actually present in pool layout (post-recovery audit)

cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim tank
ashift  12
autotrim on

Ce que cela signifie : ashift est fixé lors de la création du pool ; un mismatch peut affecter les performances et la longévité SSD. autotrim aide le comportement SSD dans la durée.

Décision : garder autotrim=on pour des vdevs special basés sur SSD sauf raison spécifique contraire. Si ashift est mauvais, planifier une migration ; ne pas « bricoler » pour compenser.

Trois mini-récits d’entreprise depuis le terrain

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

Une entreprise SaaS de taille moyenne a déployé un nouveau stockage pour une plateforme de conteneurs. L’ingénieur en charge avait un modèle mental simple :
vdevs HDD en miroir pour la capacité, et un « SSD rapide » pour les métadonnées. Il avait déjà utilisé L2ARC et a supposé que le vdev spécial se comportait pareil.
« Au pire on perd un peu de perf », a-t-il dit. Ça semblait raisonnable. Personne n’a contesté.

La charge était un mix classique riche en métadonnées : couches d’images de conteneurs, des tonnes de petits fichiers de config, et un CI qui décompressait et supprimaient des arbres toute la journée.
Le SSD spécial est rapidement devenu chaud — pas en bande passante, mais en IOPS. Il est aussi devenu le périphérique le plus critique du pool.
Ils n’avaient pas d’alertes sur les erreurs NVMe parce que le template de monitoring ciblait le SMART des HDD.

Un vendredi, le SSD a commencé à lancer des resets. ZFS l’a marqué faulted. Le pool est devenu indisponible au reboot.
Leur première réaction a été de « juste importer avec force », car les vdevs rust étaient corrects et ils voyaient tous les disques.
L’import n’a pas marché. Puis ils ont réessayé. Et encore. Pendant ce temps, l’automatisation tentait des montages et des démarrages de services, inondant l’hôte d’IO.

Finalement quelqu’un a remarqué que la config du pool incluait un vdev special et que c’était un point de défaillance unique.
La réparation n’a pas été brillante : ils ont trouvé un SSD identique, l’ont déplacé dans un slot connu, et ont réussi à récupérer suffisamment l’appareil original pour le cloner au niveau bloc.
Ce sauvetage leur a permis d’importer et d’envoyer les données ailleurs.

La leçon postmortem était cruellement basique : un vdev spécial n’est pas un stockage optionnel. C’est structurel.
Leur hypothèse (« c’est comme un cache ») leur a coûté un week-end et les a forcés à vérifier combien d’autres « ajouts rapides » étaient en fait critiques.

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

Une organisation finance avait un pool ZFS hébergeant des home directories utilisateurs et beaucoup de petits fichiers de projet. Les plaintes de performances étaient constantes :
recherches lentes, traversées de répertoires lentes, indexation IDE lente. Le stockage était blâmé, puis le réseau, puis les endpoints.
Quelqu’un a proposé des vdevs spéciaux avec special_small_blocks=128K sur le dataset principal. « Mettons tout ce qui est petit sur SSD, problème résolu. »

Ça a effectivement résolu les plaintes. Pendant un certain temps.
L’indexation s’est accélérée, les opérations git se sont améliorées, et la file d’aide s’est réduite. L’équipe stockage a déclaré victoire et est passée à autre chose.
Mais les périphériques special étaient des SSD entreprise de petite capacité dimensionnés pour « métadonnées », pas pour « métadonnées plus une montagne de contenus de petits fichiers ».

Six mois plus tard, le pool était sain mais le vdev spécial presque plein. ZFS n’a pas explosé immédiatement, ça devenait juste gênant :
les allocations se sont resserrées, la fragmentation a augmenté, et certaines opérations sont redevenues lentes.
Puis un SSD a présenté un pic d’erreurs média et le resilver du miroir a dû écrire beaucoup de données — parce que le special contenait beaucoup de blocs de fichiers réels.

Le resilver a pris plus de temps que prévu, et le SSD survivant a été martelé. Il a survécu, mais seulement après une journée tendue à surveiller les compteurs d’erreurs.
Ils ont eu de la chance. L’optimisation avait changé le mode de défaillance de « disque métadonnées meurt, on le remplace rapidement » à « le special contient des fichiers utilisateurs critiques et subit beaucoup d’écritures pendant le resilver ».

Le rétrospectif n’a pas dit « n’utilisez jamais special_small_blocks ». Il a dit « traitez-le comme un stockage tier-0 ».
Si vous allez y stocker des blocs de données, dimensionnez-le, miroirisez-le correctement, et surveillez-le comme s’il était critique en production — parce que c’est le cas.

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

Une société média utilisait ZFS pour une charge mixte : stockage VM, artefacts de build, et beaucoup de petits assets.
Leur responsable stockage était résolument anti-romantique. Chaque pool avait un vdev spécial en miroir, et chaque miroir special avait des SSD du même modèle avec protection contre perte d’alimentation.
Ils faisaient des scrubs programmés, testaient des restaurations, et avaient un runbook pour « remplacer un membre special » avec des commandes copy-paste.

Un après-midi, un NVMe dans le miroir special a commencé à loguer des erreurs média.
Le monitoring l’a détecté parce qu’ils avaient des alertes explicites pour les métriques NVMe et les erreurs de checksum ZFS, pas seulement « disque en ligne ».
L’ingénieur on-call n’a pas tergiversé. Ils ont mis en quarantaine les jobs lourds, remplacé le disque, et surveillé le resilver.

Le resilver s’est achevé rapidement. Ils ont lancé un scrub. Pas de réparations. Pas de drame.
La plupart de l’entreprise n’a jamais su que quelque chose s’était passé, ce qui est le bon résultat pour un incident stockage.

Le meilleur : l’équipe avait aussi documenté quels datasets utilisaient special_small_blocks et pourquoi.
Donc quand la direction a demandé « peut-on réduire le budget SSD le trimestre prochain », ils n’ont pas inventé des réponses.
Ils ont montré quels workloads dépendaient du special et à quoi ressemblait une défaillance. Les discussions budgétaires ont été plus simples parce que la réalité était déjà consignée.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: Pool won’t import, rust vdevs look fine

• Cause racine : vdev spécial single-disk manquant (les métadonnées allouées là-bas sont requises pour l’import).
• Correction : récupérer le chemin d’appareil manquant (hardware/PCIe/alimentation), ou restaurer depuis sauvegarde/réplication. Si le special n’était pas en miroir, vos options sont limitées et douloureuses.

2) Symptom: “ls” and stat-heavy workloads are painfully slow, but throughput tests look okay

• Cause racine : vdev spécial dégradé ou malsain ; les lectures de métadonnées sont réessayées, amplifiant la latence.
• Correction : vérifier zpool status -v, zpool iostat -v, et les logs NVMe ; remplacer le membre spécial défaillant ; scrub ensuite.

3) Symptom: After replacement, performance still worse than before

• Cause racine : le vdev spécial a été retiré/n’a jamais été utilisé comme prévu, ou la politique special_small_blocks a changé et les blocs n’ont pas été réalloués.
• Correction : confirmer les propriétés des datasets ; comprendre que les blocs existants ne bougent pas sauf réécriture ; planifier une migration basée sur la réécriture (send/recv ou recopier) si vous devez repopuler le special.

4) Symptom: Pool suspends during peak load

• Cause racine : erreurs IO sévères sur le vdev spécial provoquant ZFS à se protéger ; parfois un HBA/backplane défaillant aggrave la situation.
• Correction : arrêter l’IO intense, stabiliser le hardware, puis remplacer les appareils. Ne laissez pas les services réessayer dans un pool suspendu.

5) Symptom: Special vdev keeps filling up unexpectedly

• Cause racine : special_small_blocks réglé trop haut pour des datasets contenant beaucoup de fichiers petits à moyens ; le special stocke désormais une part significative des données.
• Correction : baisser special_small_blocks pour les nouvelles allocations (cela ne déplacera pas les anciens blocs), ajouter de la capacité au special (vdevs en miroir), et planifier une réécriture si vous devez évacuer.

6) Symptom: Resilver takes forever and the pool is sluggish

• Cause racine : le vdev spécial contient un volume important de petits blocs ; le resilver est IOPS-intensive et concurrence la production.
• Correction : planifier le resilver sous charge réduite, s’assurer que le SSD ne thermal-throttle pas, et envisager des mirrors plus larges ou des appareils plus rapides pour le special.

7) Symptom: You replaced a disk and now a different disk “vanished”

• Cause racine : instabilité des noms d’appareils, mauvais slot, backplane défectueux, ou dépendance aux noms /dev/nvmeXn1.
• Correction : utiliser /dev/disk/by-id ; vérifier le câblage/les lanes PCIe ; éviter le chaos hotplug sans plan.

Prévention efficace (et ce qui est du cargo cult)

Mirrorisez les vdevs spéciaux. Toujours.

Si vous retenez une chose : un vdev spécial sur disque unique rend tout votre pool dépendant de ce seul appareil.
Ce n’est pas « un peu risqué ». C’est une erreur de conception.
Miroirisez-le, idéalement avec deux appareils du même modèle et de la même classe d’endurance. Si votre environnement est vraiment critique, envisagez un miroir 3‑voies.

Choisissez des SSD comme un adulte

Les métadonnées et l’IO de petits blocs sont write-heavy et sensibles à la latence. Vous voulez :
protection contre perte de courant, latence prévisible sous charge, et endurance adaptée à votre churn.
Les SSD grand public peuvent fonctionner en labo et vous trahir en production à 2h du matin, moment où le hardware exprime ses sentiments.

Blague #2 : Des SSD grand public en duty spécial, c’est comme donner sudo à des stagiaires — parfois brillant, parfois catastrophique, toujours au pire moment.

Soyez délibéré avec special_small_blocks

special_small_blocks est puissant. C’est aussi le moyen le plus simple de transformer un « appareil métadonnées » en « contenant des blocs utilisateur ».
Cela peut être exactement ce que vous voulez pour des boot storms VM, des couches de conteneurs, ou des dépôts riches en petits fichiers.
Mais ça change votre capacity planning, le comportement du resilver, et le rayon d’impact d’une panne.

• Si vous le réglez : dimensionnez le special pour des données, pas juste pour des métadonnées.
• Gardez-le par dataset : ne l’appliquez pas aveuglément sur tout le pool à moins de comprendre chaque workload.
• Documentez pourquoi : le vous du futur va oublier et blâmer la mauvaise chose.

Surveillez ce qui compte (ZFS plus NVMe)

Vous voulez des alertes sur :
erreurs de checksum ZFS, erreurs d’appareil, anomalies de resilver/scrub, et erreurs média/d’intégrité NVMe.
« Disque en ligne » est une métrique inutile. Les disques peuvent être en ligne et mentir.

La discipline opérationnelle bat les héros

Les scrubs programmés détectent les problèmes latents avant qu’un rebuild vous force à lire tout sous pression.
Des spares connus bons réduisent la tentation d’utiliser des disques récupérés avec une histoire inconnue.
Un runbook réduit les risques de taper le mauvais vdev quand l’adrénaline guide vos doigts.

Une citation fiabilité (idée paraphrasée)

Idée paraphrasée : l’état d’esprit opérationnel de Gene Kranz : être « dur et compétent » en crise — rester discipliné, utiliser des checklists, et ne pas improviser son chemin vers une pire panne.

Checklists / plan étape par étape

Checklist A : Quand le vdev spécial devient DEGRADED (miroir)

1. Exécuter zpool status -v ; confirmer que les erreurs sont sur special et identifier le token/GUID de l’appareil.
2. Geler les changements risqués : arrêter les déploiements, reporter les reboots, réduire les jobs IO intensifs.
3. Vérifier les logs kernel pour resets/timeouts ; confirmer que ce n’est pas un problème de contrôleur/backplane partagé.
4. Valider que vous avez le bon disque de remplacement et effacer les anciens labels si nécessaire.
5. Faire zpool replace ; surveiller la progression du resilver et les compteurs d’erreurs.
6. Après le resilver, lancer un scrub ; vérifier « 0 errors ».
7. Post-incident : récupérer les logs SMART/NVMe, enregistrer le mode de défaillance, et ajuster les seuils de monitoring.

Checklist B : Quand le vdev spécial est UNAVAIL et que le pool ne s’importe pas

1. Exécuter zpool import ; identifier les appareils manquants et confirmer qu’il s’agit du special.
2. Stop. Ne lancez pas d’import forcés en boucle. Chaque tentative peut aggraver la contrainte sur l’appareil ou créer de la confusion.
3. Travailler le hardware en premier : reseater, déplacer dans un slot connu bon, vérifier les erreurs BIOS/PCIe, alimentation, câbles/backplane.
4. Si l’appareil est visible même de façon intermittente, prioriser la récupération des données : cloner, imager, ou le stabiliser assez longtemps pour l’import.
5. Si le special n’était pas mirror et que l’appareil est mort : pivoter vers les backups/réplication. Être honnête ; ne promettez pas de magie.
6. Après récupération : revoir la conception du pool. Un special single-disk doit être traité comme un « plus jamais ».

Checklist C : Après récupération (la partie que les équipes zappent)

1. Confirmer que le pool est ONLINE et que le scrub est propre.
2. Vérifier les réglages special_small_blocks sur les datasets critiques et documenter la raison.
3. Auditer la capacité et la réserve du vdev special ; planifier une extension avant que ça soit tendu.
4. Revoir le monitoring : erreurs ZFS, santé NVMe, throttling thermique, événements PCIe AER.
5. Réaliser un test de restauration ou un drill de basculement de réplication dans le mois. Si vous ne testez pas, vous ne l’avez pas vraiment.

FAQ

1) Is a special vdev basically the same as L2ARC?

Non. L2ARC est un cache ; le perdre est pénible. Le spécial est du stockage autoritaire ; le perdre peut empêcher l’import ou rendre des fichiers inaccessibles.

2) Is a special vdev basically the same as SLOG?

Non. SLOG accélère les écritures synchrones pour certains workloads et peut être retiré avec des conséquences limitées. Special contient des métadonnées et possiblement des blocs de données.

3) If I mirror my main vdevs with RAIDZ2, do I still need to mirror special?

Oui. La redondance du pool est limitée par le composant le moins redondant et requis. Un appareil spécial unique peut devenir le vrai point de défaillance unique.

4) What’s the safest special_small_blocks setting?

Pour beaucoup de workloads mixtes : 0 (métadonnées seulement) est le plus sûr. Si vous le définissez, faites-le par dataset et dimensionnez le special pour du stockage réel.

5) Can I remove a special vdev after I added it?

En pratique, considérez que « non » pour la planification opérationnelle. Même si votre plateforme supporte certaines suppressions, les blocs alloués là doivent être traités en toute sécurité.
Traitez special comme une partie permanente de la conception du pool.

6) If a special device is failing, should I reboot?

Pas comme premier geste. Un reboot peut remapper les noms d’appareils, déclencher d’autres resets, et réduire les chances d’une récupération stable.
Remplacez l’appareil dans des conditions contrôlées si possible.

7) Why does everything look fine in throughput benchmarks but users complain?

Beaucoup d’opérations visibles par les utilisateurs sont riches en métadonnées : traversée de répertoires, appels stat, ouverture de petits fichiers.
Les problèmes de vdev special affectent d’abord les IOPS/la latence, pas le débit séquentiel.

8) After replacing special, do I still need a scrub?

Oui. Le resilver restaure la redondance pour les blocs alloués mais ne remplace pas un passage de vérification bout-en-bout.
Le scrub confirme l’intégrité sur tout le pool et peut révéler d’autres appareils faibles.

9) Can I “recover” from losing a single-disk special vdev without backups?

Parfois on peut récupérer si l’appareil n’est pas vraiment mort (visibilité intermittente, quirks de firmware, problèmes de slot).
S’il est définitivement mort et qu’il était la seule copie, attendez-vous à une perte de données et planifiez autour de sauvegardes/réplication.

10) What’s the best early warning that special is in trouble?

L’augmentation des erreurs de checksum sur special, les erreurs média/d’intégrité NVMe, et les logs kernel montrant timeouts/resets.
Les pics de latence avec faible bande passante sont aussi un signe classique.

Conclusion : prochaines étapes à réaliser cette semaine

La panne d’un vdev spécial est un de ces incidents où la vérité technique est brute : si vous avez rendu les métadonnées dépendantes d’un seul appareil, vous avez rendu tout le pool dépendant de lui.
La sortie ne tient pas à des commandes ingénieuses. Elle tient à la redondance, à la vérification, et à refuser de considérer les appareils tier‑0 comme des accessoires.

Faites ceci

• Audit : exécuter zpool status et confirmer que les vdevs spéciaux sont mirrorisés partout.
• Vérification des politiques : inventorier special_small_blocks par dataset ; décider où c’est justifié et où c’est accidentel.
• Monitoring : alerter sur les erreurs de checksum ZFS et les erreurs média/d’intégrité NVMe, pas seulement « en ligne ».
• Pratique : répéter un remplacement de membre special sur un pool non production ; le rendre ennuyeux.
• Sauvegardes/réplication : valider que vous pouvez restaurer ou basculer sans héroïsme. Si vous ne pouvez pas, corrigez cela avant que le prochain disque ne décide de partir.

Le scénario cauchemar devient survivable quand vous traitez les vdevs spéciaux pour ce qu’ils sont : le système nerveux du système de fichiers.
Protégez-le, surveillez-le, et quand il tressaute, agissez comme si ça comptait.