ZFS : quand ajouter un vdev spécial (et quand c’est une mauvaise idée)

Ce qu’est vraiment un vdev spécial (et ce qu’il n’est pas)

Dans ZFS, un vdev spécial est une classe de vdev dédiée où ZFS peut stocker les métadonnées (et, optionnellement, les petits blocs de données)
sur des dispositifs plus rapides — généralement des SSD ou des NVMe — tandis que les données principales du pool restent sur des disques plus lents et de plus grande capacité.
Pensez : répertoires, blocs indirects, dnodes, pointeurs de blocs, cartes d’espace, une partie des métadonnées d’allocation, et (selon les paramètres) des blocs de petits fichiers.

L’objectif n’est pas un débit magique. C’est la latence et les IOPS là où ZFS en a le plus besoin :
charges de travail riches en métadonnées, charges avec beaucoup de snapshots, nombreux petits fichiers, traversées de système de fichiers, et stockage de VM avec IO aléatoires petits.

Ce que ce n’est pas

• Ce n’est pas L2ARC. L2ARC est un cache de lecture et peut être retiré à tout moment sans perte de pool. Le vdev spécial contient des blocs faisant autorité.
• Ce n’est pas un SLOG. Un SLOG sert au journal d’intention d’écriture synchrone (ZIL). Il accélère les écritures sync mais ne stocke pas les métadonnées normales de façon permanente.
• Ce n’est pas un « bouton performance gratuit ». Vous déplacez des structures critiques vers une classe de dispositifs qui doit être fiable et redondante.

Voici une vérité inconfortable : si vous ajoutez un vdev spécial et qu’il meurt, vous pouvez perdre le pool. Pas « certaines métadonnées ». Le pool.
C’est pourquoi la conception d’un vdev spécial ressemble plus à la « conception du périphérique de démarrage » qu’à celle d’un périphérique cache.

Première petite blague : un vdev spécial, c’est comme donner un espresso à ZFS — génial jusqu’à ce que vous réalisiez que le café n’a qu’une seule prise de courant.

Faits intéressants et contexte historique

• ZFS est né au milieu des années 2000 chez Sun Microsystems avec un focus impitoyable sur l’intégrité de bout en bout : checksums, copy-on-write, auto-réparation.
  Cette conception fait de la correction des métadonnées une priorité — donc la performance des métadonnées compte.
• Les vdevs spéciaux sont arrivés plus tard (pas dans les toutes premières versions de ZFS) comme réponse à un problème prévisible moderne :
  les disques magnétiques sont devenus énormes, mais leurs IOPS aléatoires ne l’ont pas fait.
• « Métadonnées sur SSD seulement » précède le vdev spécial en tant qu’idée d’architecture ; systèmes de fichiers et piles de stockage ont depuis longtemps séparé les chemins de métadonnées chaudes
  des données froides. ZFS a juste rendu cela administrativement propre.
• L’option « petits blocs » a changé la donne. Une fois que vous autorisez les données de petits fichiers sur le vdev spécial,
  vous n’accélérez plus seulement les traversées de répertoires — vous déplacez de vraies données utilisateur sur ces dispositifs.
• Les dnodes sont devenus plus paramétrables. Des fonctionnalités comme des dnodes plus grands ont amélioré l’efficacité des métadonnées (en particulier pour les attributs étendus, ACL et petits fichiers),
  mais elles ont aussi augmenté l’importance de l’emplacement des dnodes — le vdev spécial peut beaucoup aider ici.
• Les opérations intensives en snapshots sont intensives en métadonnées. Clones, listes de snapshots, énumération de datasets et planification de send/receive touchent les métadonnées et les blocs indirects
  selon des schémas qui adorent la faible latence.
• NVMe n’a pas seulement ajouté de la vitesse ; il a changé les modes de défaillance. Les dispositifs rapides sont souvent moins indulgents : bugs de firmware, throttling thermique, pertes d’alimentation surprises,
  et mort subite sans les avertissements SMART rassurants des HDD.
• Les baies d’entreprise font silencieusement la même chose en utilisant tiering et caching pour métadonnées. Le vdev spécial est la version DIY, avec des conséquences DIY.

Une citation opérationnelle (idée paraphrasée) : « L’espoir n’est pas une stratégie. » — souvent attribuée aux ingénieurs en culture de fiabilité ; le point est :
concevez le vdev spécial comme si vous attendiez qu’il tombe en panne.

Quand un vdev spécial est la bonne solution

1) Votre charge est limitée par les métadonnées, pas par le débit

Si votre pool réalise beaucoup de Mo/s mais que les opérations sont bloquées — listes de répertoires, création de fichiers, vagues de chmod/chown, gestion des snapshots —
vous êtes souvent limité par les lectures/écritures aléatoires des métadonnées. Les HDD sont mauvais pour ça. Pas « un peu moins bien ». Des ordres de grandeur en moins.

Le vdev spécial aide parce que ZFS n’a plus à aller chercher les métadonnées dans la couche la plus lente. Il peut garder les métadonnées sur des périphériques à faible latence
et réduire le nombre de seeks aléatoires sur la « rouille tournante ». Vous conservez les HDD pour les lectures/écritures séquentielles massives, pour lesquelles ils sont conçus.

2) Vous avez beaucoup de petits fichiers (ou de petits blocs) et pouvez contrôler ce qui migre

Avec le paramètre special_small_blocks, ZFS peut placer des blocs de données plus petits qu’un seuil sur le vdev spécial.
Cela peut être transformateur pour :

• Images de VM avec IO aléatoire petit (surtout avec un petit volblocksize)
• Arbres de source, dépôts de paquets, couches de conteneurs
• Workloads de type Maildir (si vous vous infligez ça, oui)
• Partages NFS/SMB riches en métadonnées et en petits fichiers

Mais c’est une arme à double tranchant. Fixez le seuil trop haut et vous migrerez silencieusement une grande fraction des données utilisateur vers le vdev spécial.
Alors vous n’« accélérez pas les métadonnées », vous « construisez un second pool que vous n’avez pas dimensionné comme un pool ».

3) Les snapshots, clones et l’énumération de datasets sont lents

Les opérations sur snapshots sont des festivals de recherche de pointeurs. Lister les snapshots, les garder, calculer l’espace utilisé et planifier la réplication
peuvent tous punir les chemins de métadonnées. Si ces tâches dominent votre douleur administrative, le vdev spécial est un levier sérieux.

4) Vous avez besoin d’une latence plus faible plus que d’un débit plus élevé

En production, les utilisateurs ne se plaignent pas que votre pool fait 1,5 Go/s en lecture séquentielle sur un benchmark. Ils se plaignent que « l’ouverture d’un dossier prend 10 secondes ».
Le vdev spécial s’adresse à ce type de souci ressenti par les humains.

5) Vous pouvez vous permettre redondance et soin opérationnel

Si vous n’êtes pas prêt à mettre le vdev spécial en miroir (ou à utiliser une redondance équivalente) et à le surveiller comme un faucon, n’en faites rien.
Le vdev spécial n’est pas fait pour « j’ai trouvé deux SSD grand public dans un tiroir ».

Quand c’est une mauvaise idée (et comment ça casse)

Vous pensez pouvoir « l’essayer puis le retirer plus tard »

Le retrait des vdevs spéciaux a historiquement été limité et opérationnellement délicat. Même quand la suppression existe, ce n’est pas toujours faisable,
pas toujours rapide, et pas toujours supporté comme vous le souhaitez sous pression. Planifiez comme si c’était permanent.

Vous ne pouvez pas le mettre en miroir

Un vdev spécial à appareil unique est une responsabilité pour tout le pool. S’il contient des métadonnées, le pool en dépend. Le perdre peut signifier perdre le pool.
S’il contient aussi des petits blocs de données, vous jouez vraiment avec des munitions réelles.

Vous corrigez le mauvais goulot

Si votre vrai problème est :

• des écritures sync sans SLOG approprié
• trop peu de RAM / thrashing de l’ARC
• recordsize/volblocksize mal adaptés au workload
• un CPU surchargé par checksums/compression
• problèmes réseau sur NFS/SMB

…un vdev spécial ne vous sauvera pas. Il peut même masquer le problème assez longtemps pour l’aggraver ensuite.

Vous utilisez des SSD/NVMe douteux ou un chemin d’alimentation instable

Les dispositifs du vdev spécial subissent de fortes charges d’IO aléatoires. Ils deviennent aussi critiques pour l’intégrité du pool.
Les SSD grand public avec une protection contre la perte d’alimentation faible et un firmware optimiste ne sont pas recommandables.

Votre pool est déjà proche de la capacité

La saturation du vdev spécial n’est pas une défaillance douce. S’il se remplit, les allocations de métadonnées peuvent échouer de façons excitantes pour les canaux d’incident.
Si votre pool principal tourne à 85–90% et que vous espérez le meilleur, vous n’êtes pas émotionnellement prêt pour un vdev spécial.

Deuxième petite blague : ajouter un vdev spécial non mirroir à un pool de production, c’est comme jongler avec des couteaux pour impressionner votre chat. Le chat reste indifférent.

Règles de conception : redondance, dimensionnement et agencement

Règle 1 : Mettez le vdev spécial en miroir (au minimum)

Traitez un vdev spécial comme « faisant partie de l’ossature du pool ». Mettez-le en miroir. Si vous voulez être encore plus conservateur, utilisez un miroir à 3 voies,
surtout pour des pools critiques et des charges très lourdes en métadonnées.

RAIDZ pour un vdev spécial est possible, mais les vdevs spéciaux mirroir sont le choix le plus courant car ils offrent de bonnes performances de lecture aléatoire
et des caractéristiques de défaillance simples. Vous voulez des IOPS et de la prévisibilité.

Règle 2 : Dimensionnez pour l’avenir, pas pour la démo

Le sous-dimensionnement est l’échec classique. Les métadonnées croissent avec le nombre de fichiers, les snapshots, les clones et les schémas de fragmentation — pas seulement la taille brute des données.
Si vous activez les petits blocs, la croissance s’accélère et devient dépendante du workload.

Conseils pratiques de dimensionnement (subjectifs, parce que vous l’avez demandé) :

• Vdev spécial uniquement métadonnées : commencez à penser en faibles pourcentages simples de la taille logique du pool, mais validez avec des chiffres réels.
  Si votre workload est « millions de petits fichiers et beaucoup de snapshots », prévoyez plus grand.
• Métadonnées + petits blocs : traitez-le comme une vraie couche, pas comme un cache. Si vous réglez special_small_blocks au-dessus de 0,
  assumez que des données utilisateur s’y retrouveront. Dimensionnez en conséquence.
• Gardez une marge. Opérationnellement, évitez de pousser le vdev spécial au-dessus d’environ ~70–80% en steady state. Ce n’est pas une loi physique ; c’est une loi humaine.

Règle 3 : Choisissez les dispositifs comme si vous les achetiez pour les pannes, pas pour les benchs

Ce que vous voulez :

• SSD/NVMe entreprise avec protection contre la perte d’alimentation
• latence cohérente sous charge d’écriture
• bon historique de firmware
• endurance suffisante pour des écritures aléatoires soutenues

Ce que vous ne voulez pas :

• NVMe grand public mystérieux qui thermal-throttle sous charge réelle
• SSD bon marché avec pauses dramatiques de garbage collection
• périphériques qui mentent via SMART jusqu’à leur mort soudaine

Règle 4 : Soyez délibéré avec special_small_blocks

special_small_blocks est une propriété de dataset. C’est une bonne nouvelle : vous pouvez le scoper.
Activez-le pour les datasets qui en tirent bénéfice : volumes de VM, stockages de conteneurs, partages riches en métadonnées.
Laissez-le désactivé pour les archives médias volumineuses où il ne ferait que gaspiller du flash coûteux sur des données froides.

Comprenez aussi la permanence : les blocs existants ne se déplacent généralement pas juste parce que vous avez changé une propriété.
Les nouvelles écritures suivent la nouvelle politique. Cela compte pour les migrations et pour les plaintes « pourquoi ça n’a rien amélioré ? ».

Règle 5 : Surveillez la santé et la saturation du vdev spécial comme si c’était critique (parce que c’est le cas)

Alertez sur :

• erreurs de périphérique, secteurs réalloués/erreurs média, erreurs de checksum
• pics de latence inhabituels
• tendance d’allocation sur le vdev spécial en forte hausse
• opérations métadonnées du pool devenant à nouveau plus lentes (ça arrive)

Tâches pratiques : commandes, ce que signifie la sortie, et quelle décision prendre

L’intérêt d’une décision sur le vdev spécial, c’est la preuve. Ci‑dessous des tâches pratiques que vous pouvez lancer aujourd’hui. Chacune contient :
une commande, un extrait réaliste de sortie, ce que cela signifie, et la décision à prendre.

Task 1: Identify whether a special vdev already exists

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Signification : Le pool a déjà une classe de vdev special, en miroir. Bien. Votre prochaine question est « que stocke‑t‑il ? ».

Décision : S’il existe et n’est pas en miroir, considérez cela comme une priorité de réduction de risque.
S’il n’existe pas, validez d’abord que les métadonnées sont votre goulot avant d’en ajouter un.

Task 2: Check pool I/O saturation vs latency symptoms

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        42.3T  29.1T    210    180   28.1M  35.7M
  raidz2-0                  42.3T  29.1T    210    180   28.1M  35.7M
    sda                         -      -     32     27   3.9M   4.4M
    sdb                         -      -     34     28   4.0M   4.5M
    sdc                         -      -     36     31   4.1M   4.6M
    sdd                         -      -     33     29   4.0M   4.5M
--------------------------  -----  -----  -----  -----  -----  -----

Signification : Le débit est modeste. Les opérations sont modérées. Si les utilisateurs voient encore des « listings lents », c’est probablement la latence/métadonnées, pas la saturation du débit.

Décision : Poursuivez l’investigation de la pression sur les métadonnées. Un vdev spécial peut aider.
Si le débit ou les opérations sont saturés, vous aurez peut‑être besoin de plus de vdevs, d’un autre agencement, ou de corriger le comportement des écritures sync.

Task 3: See dataset properties related to special vdev behavior

cr0x@server:~$ zfs get -r special_small_blocks,recordsize,atime,compression tank/data
NAME        PROPERTY              VALUE                  SOURCE
tank/data   special_small_blocks  0                      default
tank/data   recordsize            128K                   default
tank/data   atime                 off                    local
tank/data   compression           zstd                   local

Signification : Les petits blocs ne sont pas redirigés vers le vdev spécial pour ce dataset. Seules les métadonnées iraient là (si un vdev spécial existe).

Décision : Si vous souhaitez accélérer les IO aléatoires petits pour ce dataset (p.ex. stockage de VM),
envisagez d’activer special_small_blocks prudemment et uniquement pour les dataset(s) qui en profitent.

Task 4: Check ARC size and pressure (metadata often lives here first)

cr0x@server:~$ arc_summary | head -n 18
ARC Summary:
    Memory Throttle Count:                    0
    ARC Size:                            62.1 GiB
    Target Size:                         64.0 GiB
    Min Size (Hard Limit):               16.0 GiB
    Max Size (Hard Limit):               64.0 GiB

ARC Misc:
    Deleted:                                1.2 GiB
    Mutex Misses:                           0
    Evict Skips:                            0

ARC Efficiency:
    Cache Hit Ratio:                       86.3%

Signification : L’ARC est sain et obtient de bons hits. Si les opérations sur les métadonnées sont toujours lentes, vous manquez peut‑être de métadonnées chaudes dans l’ARC à cause de la taille du working set,
ou votre goulot est la latence disque lors des cache misses.

Décision : Si l’ARC est minuscule par rapport au workload, ajoutez de la RAM avant d’ajouter un vdev spécial.
Si l’ARC est sain mais que les misses sont douloureux sur HDD, le vdev spécial devient plus attractif.

Task 5: Inspect metadata-vs-data cache behavior (Linux example)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'hits|misses|mfu_hits|mru_hits|metadata|demand_data|demand_metadata' | head -n 12
hits                            4    123456789
misses                          4     19654321
demand_data_hits                4     62123456
demand_metadata_hits            4     51234567
demand_data_misses              4      9234567
demand_metadata_misses          4     10419754
mru_hits                        4     31234567
mfu_hits                        4     92222222

Signification : Les misses de métadonnées sont significatifs. C’est précisément là où le vdev spécial peut réduire la latence queueing : quand les métadonnées ne sont pas en cache.

Décision : Si les misses de métadonnées à la demande sont élevés et corrélés à une latence visible par les utilisateurs, le vdev spécial est probablement utile — après avoir vérifié
que le pool n’est pas mal configuré pour d’autres raisons.

Task 6: Confirm special vdev allocation (is it filling?)

cr0x@server:~$ zfs list -o name,used,available,refer,mounted -r tank | head
NAME          USED  AVAIL  REFER  MOUNTED
tank         42.3T  29.1T   192K  yes
tank/data    31.8T  29.1T  31.8T  yes
tank/vm       8.9T  29.1T   8.9T  yes
tank/backup   1.6T  29.1T   1.6T  yes

Signification : Ceci ne montre pas directement l’utilisation du vdev spécial. Pour cela vous avez besoin de vues d’allocation au niveau du pool et parfois des statistiques par périphérique.

Décision : Continuez avec zdb et des vérifications au niveau du pool. Si vous ne pouvez pas quantifier la croissance du vdev spécial, vous naviguez à l’aveugle.

Task 7: Use zpool list -v to see special vdev space

cr0x@server:~$ zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        72.8T  42.3T  30.5T        -         -    18%    58%  1.00x  ONLINE  -
  raidz2-0  72.8T  42.3T  30.5T        -         -    18%    58%
  special   1.82T   612G  1.22T        -         -     9%    33%
    mirror-1 1.82T  612G  1.22T        -         -     9%    33%

Signification : La classe special a ~33% d’utilisation. C’est acceptable. Si cela monte vers 80–90%, vous vous dirigez vers un incident évitable.

Décision : Si le special augmente rapidement, planifiez l’extension tôt (ajouter un autre vdev spécial mirroir, selon votre conception).
N’attendez pas que cela devienne « intéressant ».

Task 8: Measure metadata-heavy operations directly

cr0x@server:~$ time ls -U tank/data/bigdir >/dev/null

real    0m8.412s
user    0m0.031s
sys     0m0.402s

Signification : ls a mis 8 secondes juste pour énumérer les entrées (sortie jetée). C’est une latence classique liée aux métadonnées.

Décision : Corrélez cela avec la latence disque et les statistiques ARC. Si confirmé, le vdev spécial est un candidat.
Si la liste de répertoire est rapide mais que les applications sont lentes, le goulot est ailleurs.

Task 9: Check device latency at the OS level (Linux example)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              32.0    28.0   4096    4608   24.5   3.2    92.0
sdb              33.0    27.0   4120    4512   23.8   3.1    91.5
sdc              34.0    29.0   4180    4620   25.1   3.3    93.2
sdd              31.0    30.0   4012    4700   26.4   3.4    94.1
nvme0n1         120.0    80.0  15360    9216    0.6   0.1    12.0
nvme1n1         118.0    78.0  15040    9152    0.7   0.1    11.5

Signification : Les HDD montrent un await élevé et une utilisation très forte. Les NVMe sont à faible latence et peu chargés.
Si les métadonnées sont sur HDD, c’est là que se situe votre douleur. Si le special existe déjà, cela suggère peut‑être qu’il n’est pas utilisé comme prévu.

Décision : Si la latence HDD corrèle avec les opérations métadonnées, placez les métadonnées sur le special.
Si le special existe mais que les HDD souffrent encore, vérifiez si vos métadonnées y arrivent effectivement et si l’ARC ne thrash pas.

Task 10: Verify ashift and alignment of the special devices

cr0x@server:~$ zdb -C tank | egrep 'vdev_tree|type:|path:|ashift' | head -n 30
        vdev_tree:
            type: 'root'
            type: 'raidz'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'mirror'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'

Signification : ashift: 12 (secteurs 4K) est typique. Un ashift mismatching ou trop petit peut nuire aux performances et à l’endurance.

Décision : Si l’ashift est incorrect sur les dispositifs spéciaux (rare mais possible lors de migrations), vous devrez peut‑être reconstruire ce vdev correctement.
N’ignorez pas l’alignement sur des dispositifs qui prendront des IO aléatoires toute la journée.

Task 11: Add a mirrored special vdev (the real operation)

cr0x@server:~$ sudo zpool add tank special mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8-part1 /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8B-part1

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

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          raidz2-0                                        ONLINE       0     0     0
            sda                                           ONLINE       0     0     0
            sdb                                           ONLINE       0     0     0
            sdc                                           ONLINE       0     0     0
            sdd                                           ONLINE       0     0     0
        special
          mirror-1                                        ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8-part1                ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8B-part1               ONLINE       0     0     0

errors: No known data errors

Signification : La classe special existe et est mirroirée. Les allocations de métadonnées commenceront à l’utiliser.
Les métadonnées existantes ne se relocent pas nécessairement ; cela améliore surtout les nouvelles allocations et les opérations dont les lectures frappent des métadonnées maintenant stockées là.

Décision : Ensuite, décidez d’activer ou non special_small_blocks pour des datasets sélectionnés.
Mettez aussi en place la surveillance de l’utilisation du special et de la santé des dispositifs immédiatement.

Task 12: Enable special_small_blocks for a VM dataset (scoped and intentional)

cr0x@server:~$ sudo zfs set special_small_blocks=16K tank/vm

cr0x@server:~$ zfs get special_small_blocks tank/vm
NAME     PROPERTY              VALUE  SOURCE
tank/vm  special_small_blocks  16K    local

Signification : Les nouveaux blocs de données ≤ 16K dans tank/vm iront vers le vdev spécial.
Cela correspond souvent mieux aux patterns IO aléatoires des VM que de tout placer là.

Décision : Si l’utilisation du special croît rapidement, baissez le seuil ou restreignez-le à moins de datasets.
Si la latence VM s’améliore sans que le special se remplisse, vous avez trouvé un bon compromis.

Task 13: Validate improvement with a before/after metadata test

cr0x@server:~$ time find tank/data/bigdir -maxdepth 2 -type f -print >/dev/null

real    0m14.227s
user    0m0.081s
sys     0m0.913s

Signification : C’est un test de traversée lourd en métadonnées. Exécutez‑le avant et après l’ajout d’un vdev spécial (ou le changement de propriétés).
L’objectif est une preuve directionnelle, pas la perfection.

Décision : Si cela n’améliore pas, vous n’aviez probablement pas un goulot métadonnées — ou l’ARC l’absorbe déjà — ou le dataset n’utilise pas le special comme prévu.
Retournez au diagnostic.

Task 14: Check special vdev error counters and scrub results

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Feb  4 02:00:26 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Signification : Un scrub propre et zéro erreur est ce que vous voulez, surtout sur les dispositifs spéciaux.
Quelques erreurs de checksum sur le special doivent déclencher une vraie inquiétude : vous corrompez le système nerveux du pool.

Décision : Si vous voyez des erreurs sur le special, remplacez agressivement les dispositifs et investiguez câblage/backplane/firmware.
Ne vous contentez pas de « surveiller un peu ». C’est ainsi qu’on finit par restaurer depuis une sauvegarde en expliquant la situation aux adultes.

Task 15: Confirm sync write behavior (to avoid mis-attributing latency)

cr0x@server:~$ zfs get sync tank/vm
NAME     PROPERTY  VALUE  SOURCE
tank/vm  sync      standard  default

Signification : Les écritures sync ne sont pas désactivées de force. Si votre workload est NFS/VM avec écritures sync, un SLOG manquant ou faible peut dominer la latence.

Décision : Si vous chassez la latence et que votre workload fait beaucoup d’écritures sync, évaluez le SLOG séparément.
N’utilisez pas le vdev spécial comme substitut à un chemin d’écriture sync correctement conçu.

Task 16: Check fragmentation and how it affects metadata churn

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap tank
NAME  SIZE  ALLOC  FREE  FRAG  CAP
tank  72.8T  42.3T  30.5T   18%   58%

Signification : Fragmentation modérée. Une fragmentation élevée peut augmenter l’overhead des métadonnées et la seekiness sur HDD.

Décision : Si la frag est très élevée et que les performances s’effondrent, le vdev spécial peut aider mais peut traiter un symptôme.
Envisagez de réécrire/répliquer des datasets pour les re‑packer, et revoyez la politique de rétention des snapshots.

Mode opératoire de diagnostic rapide : trouvez le goulot avant d’acheter du NVMe

C’est la séquence « arrêtez de discuter et obtenez des faits ». Exécutez‑la dans l’ordre. L’objectif est de classifier le ralentissement en minutes, pas en jours.

Première étape : est‑ce la latence des métadonnées ou autre chose ?

1. Lancez un simple test métadonnées (time ls dans un énorme répertoire, ou find limité en profondeur). S’il est lent, vous avez un suspect.
2. Vérifiez la latence des périphériques au niveau OS (iostat -x). Si le await des HDD est élevé tandis que le débit est modeste, c’est « douleur IO aléatoire ».
3. Vérifiez le taux de hit ARC et les misses de métadonnées. Si les misses de métadonnées sont significatifs et corrélés aux symptômes, vous êtes en territoire vdev spécial.

Deuxième étape : confirmez que ZFS ne vous pénalise pas pour des écritures sync

1. Vérifiez la propriété sync du dataset.
2. Identifiez le workload : NFS avec sync, bases de données, stockage VM, etc.
3. Recherchez une latence élevée lors des écritures même si les lectures sont correctes. C’est souvent le SLOG ou le flush du dispositif sous-jacent.

Troisième étape : validez la capacité/fragmentation et les mines opérationnelles

1. Capacité du pool : si vous êtes au‑dessus d’environ ~80%, corrigez cela d’abord. ZFS sous pression de capacité peut mal se comporter.
2. Fragmentation : une frag élevée + snapshots lourds peut rendre les métadonnées plus coûteuses.
3. Si vous avez déjà un vdev spécial, vérifiez son utilisation et ses erreurs. Un special malade peut sembler être une « bizarrerie aléatoire du pool ».

Point de décision

• Ajouter un vdev spécial si : les opérations métadonnées sont lentes, la latence HDD est élevée pendant ces opérations, et les misses metadata de l’ARC sont significatifs.
• Ne pas ajouter de vdev spécial si : le vrai problème est le chemin d’écritures sync, la famine d’ARC, le CPU ou le réseau.

Trois mini-récits d’entreprise issus du terrain

Incident : la mauvaise hypothèse (« le special, c’est comme un cache, non ? »)

Une entreprise de taille moyenne gérait un pool ZFS pour un système CI interne et un dépôt d’artefacts. Les plaintes de performance étaient constantes mais pas catastrophiques :
les checkouts de job étaient lents, les caches de build semblaient « collants », et les opérations sur répertoires étaient douloureuses aux heures de pointe.
Un ingénieur a proposé d’ajouter un seul « SSD rapide » comme vdev spécial pour « mettre en cache les métadonnées ».

L’hypothèse était simple et fausse : que le special se comporte comme L2ARC — agréable mais sans risque de perte. Le changement a été effectué pendant une fenêtre de maintenance.
Cela a effectivement amélioré la vitesse perçue immédiatement. Ce retour positif est dangereux ; il convainc tout le monde que la conception était correcte.

Quelques semaines plus tard, le SSD a commencé à signaler des erreurs média. Il n’est pas mort d’un coup ; il a corrompu des lectures occasionnellement et logué des timeouts.
Le pool a commencé à rapporter des erreurs de checksum. Puis les services ont commencé à échouer de façons non évidentes : accès fichiers aléatoires erronés, résultats ENOENT bizarres,
et comportements « impossibles » durant les opérations de snapshot.

La récupération a été désagréable mais instructive : ils ont dû traiter cela comme une défaillance menaçant le pool, remplacer le dispositif en urgence,
et se démener pour valider les répliques. Le postmortem ne visait pas à blâmer. Il portait sur la sémantique : le vdev spécial n’est pas un cache.
Ils ont refait la conception avec une paire miroir de SSD entreprise et ajouté la surveillance des compteurs d’erreurs.

La leçon durable : des améliorations de performance rapides peuvent être le début d’un lent désastre si vos hypothèses sont incorrectes.

Optimisation qui a mal tourné : « Fixons special_small_blocks haut et gagnons pour toujours »

Une autre organisation hébergeait des bureaux virtuels et une foule de petits services internes sur ZFS. Ils ont ajouté un vdev spécial miroir, puis se sont montrés ambitieux.
Quelqu’un a réglé special_small_blocks sur une valeur élevée au niveau du dataset parent parce que « les petits IO sont lents et le flash est rapide ».
Ça sonnait rationnel en réunion. Les réunions font ça.

Pendant un mois, tout le monde était content. Les vagues de boot étaient moins pénibles. La latence de connexion s’est améliorée. Les graphiques étaient plus jolis et les questions ont cessé.
Puis les alarmes de capacité ont commencé à sonner — pas sur le pool principal, mais sur le vdev spécial.
Il a grimpé régulièrement parce que de plus en plus de blocs de données réels remplissaient la condition « petit ».

Le special est passé de « couche métadonnées » à « couche données chaudes » sans que personne ne l’admette. Lorsqu’il a approché une haute utilisation,
les nouvelles allocations ont été contraintes et les performances sont devenues étranges : blocages soudains, latences en queue longue, et quelques échecs d’allocation pendant les fenêtres chargées.
L’équipe a d’abord accusé ZFS, puis l’hyperviseur, puis le réseau (évidemment).

La solution n’a pas été glamour. Ils ont abaissé special_small_blocks pour la plupart des datasets, l’ont laissé activé seulement pour les volumes VM qui en profitaient réellement,
et ont étendu la classe special avec une autre paire miroir. Ils ont aussi ajouté une règle : tout changement à special_small_blocks nécessite une projection de capacité et un plan de rollback.

La leçon durable : déplacer des données sur le special est facile. Les faire revenir est la partie qui coûte.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « on a mis en miroir, surveillé, et répété »

Une entreprise proche du secteur financier utilisait ZFS pour un service de fichiers avec un fort churn de métadonnées : millions de fichiers, usage intensif d’ACL, et un régime strict de snapshots/réplication.
Leur ingénieur stockage a insisté sur un vdev spécial miroir avec NVMe entreprise, plus surveillance SMART, plus scrubs réguliers, plus alerting sur la capacité du special.
Personne n’a fait la fête pour ce plan. C’est comme ça qu’on sait qu’il est bon.

Des mois plus tard, un NVMe du miroir spécial a commencé à signaler une hausse d’erreurs média.
Les alertes ont déclenché tôt, avant que le pool montre des symptômes visibles par les utilisateurs. Ils ont planifié un remplacement accéléré.
Pendant le remplacement, le pool est resté en ligne ; la redondance a fait son travail ; aucune prouesse héroïque nécessaire.

Le compte‑rendu post‑action était ennuyeux. Il consistait surtout en « les alertes ont marché » et « la procédure a correspondu à la réalité ».
C’est le compliment le plus élevé qu’on puisse faire à une pratique opérationnelle.

La leçon durable : le vdev spécial est sûr quand vous le traitez comme une infrastructure critique, pas comme un accessoire performance.

Erreurs fréquentes : symptômes → cause → correctif

1) Symptom: Pool is ONLINE but apps see random ENOENT / I/O errors

Cause racine : Le vdev spécial est dégradé ou renvoie des erreurs ; les lectures de métadonnées échouent ou sont corrompues.

Correctif : Vérifiez zpool status -v. Remplacez immédiatement les dispositifs spéciaux défaillants. Scrub. Inspectez le contrôleur/backplane/firmware.

2) Symptom: You added special vdev and nothing got faster

Cause racine : Le workload n’est pas limité par les métadonnées (ou l’ARC les cache déjà), ou le dataset ne génère pas de nouvelles métadonnées sur le chemin chaud.

Correctif : Relancez le playbook de diagnostic rapide. Vérifiez les misses metadata de l’ARC, le await des HDD, et où le temps est passé (écritures sync, réseau, CPU).

3) Symptom: Special vdev is filling much faster than expected

Cause racine : special_small_blocks est activé trop largement ou défini trop haut, déplaçant des blocs utilisateur vers le special.

Correctif : Baissez/désactivez special_small_blocks pour les datasets généraux. Conservez‑le seulement là où il est justifié. Agrandissez la capacité du special avant d’atteindre un seuil critique.

4) Symptom: After enabling special_small_blocks, endurance on NVMe looks scary

Cause racine : Les écritures de petits blocs sont lourdes ; les dispositifs spéciaux subissent une vraie charge d’écriture, pas seulement des mises à jour de métadonnées.

Correctif : Réduisez le seuil. Envisagez de ramener des datasets lourds en écriture sur des vdevs HDD ou augmentez la capacité mirroir spéciale avec des dispositifs à endurance plus élevée.

5) Symptom: Great performance for weeks, then sudden tail latency spikes

Cause racine : Les dispositifs spéciaux subissent des pauses de GC firmware, throttling thermique, ou approchent d’une forte utilisation provoquant des contentions d’allocation.

Correctif : Vérifiez les températures/latences NVMe au niveau OS, la tendance de capacité du special, et envisagez une autre classe de SSD. Gardez l’utilisation du special dans une bande plus sûre.

6) Symptom: “zfs list -t snapshot” is painfully slow

Cause racine : Traversée métadonnées intensive sur HDD ; misses metadata de l’ARC ; possiblement un nombre extrême de snapshots.

Correctif : Le vdev spécial aide ici. Rationalisez aussi la rétention des snapshots. Vérifiez les taux de misses metadata et envisagez d’augmenter la RAM.

7) Symptom: Metadata operations improved, but VM write latency still bad

Cause racine : Le chemin d’écritures sync domine (NFS sync, fsync excessifs) et il n’y a pas de SLOG approprié ou le flush du dispositif sous-jacent est lent.

Correctif : Concevez un SLOG approprié (sujet séparé), confirmez les paramètres sync, et mesurez spécifiquement la latence d’écriture. Ne blâmez pas les métadonnées pour la douleur sync.

8) Symptom: Special vdev mirror shows checksum errors but disks “look fine”

Cause racine : Souvent câblage, problèmes PCIe/backplane, instabilité d’alimentation, ou bugs de contrôleur ; pas toujours le NAND lui‑même.

Correctif : Changez les slots, vérifiez le firmware, l’alimentation, lancez des scrubs, remplacez les composants suspects. Traitez les erreurs de checksum comme un signal réel, pas du bruit.

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

Étape par étape : décider d’ajouter un vdev spécial

1. Prouvez que c’est les métadonnées.
   Lancez un test lourd en métadonnées (ls/find), et corrélez avec la latence HDD (iostat -x) et les misses metadata de l’ARC.
2. Éliminez les goulots non liés aux métadonnées.
   Vérifiez la pression RAM/ARC, le comportement d’écritures sync, la saturation CPU, et le réseau.
3. Choisissez la portée.
   Métadonnées uniquement ? Ou métadonnées + petits blocs sur datasets sélectionnés ? Par défaut, privilégiez métadonnées uniquement jusqu’à justification.
4. Concevez la redondance.
   Mettez en miroir (minimum). Préférez SSD/NVMe entreprise. Planifiez la surveillance.
5. Dimensionnez avec marge.
   Estimez la croissance avec les snapshots et le nombre de fichiers. Ne laissez pas le special presque plein.
6. Planifiez opérationnellement.
   Fenêtre de maintenance, attentes de rollback (limitées), scrub après, seuils d’alerte, et mise à jour du runbook d’astreinte.

Checklist d’implémentation (faites ceci, dans cet ordre)

1. Vérifiez l’identité des dispositifs via /dev/disk/by-id/, pas en devinant /dev/nvme0n1.
2. Confirmez la santé du pool : zpool status -x.
3. Ajoutez un vdev spécial mirroir : zpool add pool special mirror ....
4. Vérifiez qu’il est présent et ONLINE : zpool status, zpool list -v.
5. Optionnel : définissez special_small_blocks seulement sur des datasets spécifiques (commencez bas, p.ex. 8K–16K, et mesurez).
6. Scrub peu après le changement (et régulièrement) : zpool scrub, puis vérifiez les résultats.
7. Mettez en place la surveillance : utilisation du special, erreurs SMART/media NVMe, outliers de latence.
8. Relancez le même test métadonnées et capturez l’avant/après.

Checklist opérationnelle (la partie qui évite les pages nocturnes)

• Alertez si l’utilisation du vdev spécial franchit un seuil choisi (warning ~70%, critique ~80–85%).
• Alertez sur toute erreur READ/WRITE/CKSUM des membres du vdev spécial.
• Suivez l’endurance NVMe et les erreurs média dans le temps.
• Gardez des dispositifs de rechange ou une voie d’achat qui n’implique pas « expédier depuis un marketplace ».
• Entraînez‑vous au remplacement de dispositif sur un pool non‑prod si votre équipe ne l’a pas déjà fait.

FAQ

1) Un vdev spécial va‑t‑il tout accélérer ?

Non. Il accélère ce qui est limité par la latence des métadonnées (et éventuellement les IO petits blocs). Les lectures séquentielles de gros fichiers ne changeront généralement pas beaucoup.
Si votre problème est les écritures sync, la pression ARC, le CPU ou le réseau, il ne corrigera pas cela.

2) Un vdev spécial est‑il sûr en mode appareil unique ?

En production, non. S’il contient des métadonnées, le perdre peut coûter le pool. Mettez‑le en miroir au minimum.
Un vdev spécial à appareil unique appartient aux labos, démos, ou environnements qui acceptent un risque catastrophique.

3) Le vdev spécial, c’est la même chose que L2ARC ?

Pas du tout opérationnellement. L2ARC est un cache et peut être retiré sans perte de données (vous perdez juste le contenu du cache).
Le vdev spécial stocke des blocs faisant autorité. Traitez‑le comme un stockage critique.

4) Quel réglage pour special_small_blocks ?

Commencez conservateur et dataset‑spécifique. 8K ou 16K sont des points de départ courants pour des IO de type VM.
Ne le mettez pas haut sur des datasets larges sauf si vous avez dimensionné le special comme une vraie couche et acceptez que des données utilisateur s’y logent.

5) Puis‑je déplacer les métadonnées existantes vers le vdev spécial après l’avoir ajouté ?

ZFS place plutôt les nouvelles allocations selon les règles actuelles ; il ne réécrit pas automatiquement tout le système.
Certaines améliorations arrivent immédiatement parce que de nouvelles métadonnées et une partie de l’activité se déplacent, mais une migration complète nécessite généralement une réécriture (p.ex. réplication vers un nouveau dataset).

6) Comment savoir si je suis limité par les métadonnées ?

Cherchez des listes/traversées de répertoires lentes, une énumération de snapshots lente, un await HDD élevé à débit modeste, et des misses metadata significatifs de l’ARC.
Si tout cela se recoupe, vous êtes probablement limité par les métadonnées.

7) Ajouter un vdev spécial change‑t‑il ma stratégie de sauvegarde/réplication ?

Cela doit modifier votre évaluation du risque, pas les fondamentaux. Sauvegardes et réplication restent obligatoires.
Mais vous devez maintenant traiter les dispositifs spéciaux comme critiques pour le pool et assurer surveillance, rechanges et procédures de remplacement robustes.

8) Dois‑je ajouter un vdev spécial ou simplement plus de RAM ?

Si l’ARC est clairement à la famine, ajoutez d’abord de la RAM. La RAM est la couche de métadonnées la plus rapide que vous puissiez acheter.
Le vdev spécial aide quand les misses ARC sont inévitables et que la latence HDD vous tue malgré tout.

9) Un vdev spécial aidera‑t‑il les partages NFS/SMB ?

Souvent oui, surtout pour des partages avec beaucoup de petits fichiers, des répertoires profonds, des vérifications ACL, et un fort churn de métadonnées.
Mais si la douleur vient du réseau, du comportement client, ou des écritures sync, il faudra régler ces points séparément.

10) Quel est le plus gros signal d’alerte après l’ajout d’un special ?

Toute erreur sur les dispositifs du vdev spécial, et une croissance rapide de l’allocation du special que vous n’aviez pas prévue. Les deux méritent une attention immédiate.

Prochaines étapes réalisables cette semaine

1. Exécutez le playbook de diagnostic rapide et capturez les sorties : zpool iostat, iostat -x, statistiques ARC, et un chronométrage de traversée métadonnées.
   Si vous ne pouvez pas montrer de preuve, vous ne prenez pas une décision d’ingénierie — vous prenez un achat.
2. Si c’est limité par les métadonnées, concevez un vdev spécial en miroir avec des SSD/NVMe fiables et protection contre perte d’alimentation, et dimensionnez avec marge.
3. Ajoutez le vdev spécial et surveillez‑le immédiatement. Si vous n’alertez pas sur l’utilisation et les erreurs du special, vous êtes à un incident nocturne près.
4. Activez special_small_blocks uniquement là où c’est rentable (datasets VM, stockages de conteneurs), en commençant prudemment et en surveillant la croissance du special.
5. Rédigez le runbook pour la défaillance d’un dispositif spécial : comment identifier, comment remplacer, comment vérifier via scrub et status, et qui appeler.

Le vdev spécial est l’un des outils de performance les plus efficaces « en vrai » pour ZFS — parce qu’il cible la latence que les humains ressentent.
C’est aussi l’un des moyens les plus faciles de transformer un pool résilient en un pool fragile si vous le traitez comme un cache. Ne le faites pas.