Dimensionnement du vdev spécial ZFS : quelle taille lui donner (pour ne pas le regretter)

Ce que fait réellement le vdev spécial

Un pool ZFS stocke normalement les blocs de données et les blocs de métadonnées sur ses vdev « normaux » (HDD, SSD, peu importe ce que vous avez construit).
Un vdev spécial est une classe d’allocation additionnelle qui peut contenir les métadonnées et, optionnellement, des petits blocs de données.
L’objectif est simple : garder les éléments aléatoires et sensibles à la latence sur des médias plus rapides.

Qu’est-ce qui atterrit sur un vdev spécial ?

• Métadonnées : blocs indirects, dnodes, structures de répertoires, pointeurs de bloc, spacemaps et autres « tâches de tenue de livres » nécessaires pour trouver et gérer les données.
• Optionnellement, des petits blocs lorsque special_small_blocks est défini sur un dataset ou un zvol.

Ce n’est pas un L2ARC. Ce n’est pas un SLOG. Ce n’est pas un « cache » que l’on peut perdre sans conséquence.
Si vous placez des métadonnées critiques du pool sur un vdev spécial, leur perte peut signifier la perte du pool.

Voici la vérité opérationnelle : les vdevs spéciaux sont fantastiques, mais ils ne pardonnent pas.
La question du dimensionnement n’est pas « quel est le minimum qui marche », mais « quel est le minimum qui fonctionnera encore après deux ans de churn, snapshots et mauvaises idées ».

Blague n°1 : Le vdev spécial, c’est comme un tiroir à bazar — s’il est trop petit, tout y va quand même, il suffit qu’il ne se referme plus.

Les métadonnées sont petites… jusqu’à ce qu’elles ne le soient plus

Les gens sous-estiment les métadonnées parce qu’ils imaginent « noms de fichiers et timestamps ».
Les métadonnées ZFS incluent les structures qui rendent possibles le copy-on-write, les snapshots, les checksums, la compression et les arbres de pointeurs de bloc.
Plus il y a de blocs et de fragmentation, plus il y a de métadonnées. Beaucoup de petits fichiers signifie plus de métadonnées. Beaucoup de snapshots signifie plus de métadonnées.

Si vous redirigez aussi les petits blocs vers le vdev spécial, votre « périphérique de métadonnées » devient un périphérique métadonnées-plus-données-chaudes.
C’est acceptable — souvent excellent — mais vos hypothèses de dimensionnement et d’endurance doivent changer.

Faits et contexte historique (pour comprendre le comportement)

Quelques faits concrets aident à expliquer pourquoi le dimensionnement du vdev spécial paraît contre-intuitif et pourquoi un mauvais choix peut fonctionner discrètement pendant des mois avant d’exploser.

1. Les classes d’allocation spéciales ZFS sont arrivées relativement tard par rapport aux fonctionnalités centrales de ZFS ; les premières versions reposaient davantage sur des dispositions « tous les vdevs sont égaux »,
   plus L2ARC/SLOG pour modeler les performances.
2. L’I/O des métadonnées est souvent plus aléatoire que l’I/O des données. ZFS peut lire de gros flux, mais l’accès aux métadonnées a tendance à bondir dans l’arbre sur disque.
3. Le copy-on-write multiplie le travail des métadonnées. Chaque nouvelle écriture met à jour des pointeurs de bloc vers le haut de l’arbre, et les snapshots préservent les anciens pointeurs.
4. Les dnodes ont grossi avec le temps. Des fonctionnalités comme dnodesize=auto et les « fat dnodes » existent parce que regrouper plus d’attributs dans les dnodes évite des I/O supplémentaires,
   mais cela change aussi l’empreinte et la disposition des métadonnées.
5. La défaillance d’un vdev spécial peut être catastrophique s’il stocke des métadonnées nécessaires pour assembler le pool. Ce n’est pas théorique ; c’est une conséquence de conception.
6. Les écarts de latence entre SSD et HDD se creusent. Les NVMe modernes peuvent servir des lectures aléatoires en dizaines de microsecondes ; les HDD sont en millisecondes.
   Un delta ×100 sur une charge riche en métadonnées n’est pas rare.
7. La compression et les petits enregistrements changent la donne. Quand votre pool écrit de nombreux petits blocs compressés, les métadonnées et la « chaudeté des petits blocs »
   commencent à ressembler, du point de vue I/O.
8. Les snapshots augmentent le churn des métadonnées. Chaque snapshot conserve d’anciens chemins de pointeur de bloc ; les suppressions deviennent de la « gestion de deadlist » plutôt qu’un reclaim immédiat.
9. L’extension du pool est facile ; la remédiation du vdev spécial ne l’est pas. Vous pouvez ajouter des vdevs pour augmenter la capacité, mais vous ne pouvez pas retirer un vdev spécial de la plupart des systèmes de production et en sortir en souriant.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue tout le temps — concevez pour la défaillance, pas pour le meilleur scénario. »
Le dimensionnement du vdev spécial est précisément cela : concevoir pour les modes de défaillance, pas pour les benchmarks du jour 1.

Principes de dimensionnement qui vieillissent bien

Principe 1 : Décidez quel problème vous résolvez

Il y a deux raisons légitimes d’ajouter un vdev spécial :

• Accélération des métadonnées : listings de répertoires plus rapides, ouvertures de fichiers, pics de stat, opérations sur snapshots et comportement « beaucoup de petits fichiers ».
• Accélération des petits blocs : stocker les blocs plus petits qu’un seuil sur SSD pour réduire l’I/O aléatoire sur HDD et améliorer la latence des petites lectures/écritures.

Si vous voulez seulement accélérer les métadonnées, vous pouvez souvent rester modeste (mais pas minuscule).
Si vous voulez l’accélération des petits blocs, vous construisez un système de tiering partiel et devez dimensionner en conséquence.

Principe 2 : « Ce ne sont que des métadonnées » est la voie vers la pagination du stockage

Sous-dimensionner le vdev spécial crée une issue perverse : ZFS essaye d’y placer les métadonnées/petits blocs, il se remplit, les allocations deviennent contraintes,
et soudain ce que vous avez ajouté pour les performances devient un goulot d’étranglement et parfois un facteur de risque.

Principe 3 : Miroirs pour les vdevs spéciaux en production

Si vous tenez au pool, le vdev spécial doit être mirrored (ou mieux).
Des vdevs spéciaux en RAIDZ existent dans certaines implémentations, mais les mirrors gardent les domaines de défaillance propres et le comportement de rebuild prévisible.
Aussi : NVMe peut mourir de façons passionnantes. Pas toujours, mais assez pour que vous deviez l’anticiper.

Principe 4 : Prévoyez la croissance et le churn, pas la capacité brute

Le vdev spécial est sensible au churn : snapshots, suppressions, charges réécriture-intensives et réorganisations de datasets peuvent augmenter la pression sur les métadonnées.
La planification de capacité doit inclure une taxe « le vous du futur est plus occupé et moins soigneux ».

Principe 5 : Évitez le modèle « un petit vdev spécial pour tout »

Le vdev spécial est pool-wide, mais vous pouvez contrôler le placement des petits blocs par dataset.
Cela signifie que vous pouvez être sélectif. Si vous réglez special_small_blocks globalement et oubliez, vous vous engagez à la croissance du vdev spécial.
Être sélectif n’est pas de la lâcheté ; c’est de la gestion du risque.

Blague n°2 : Les ingénieurs stockage ne croient pas à la magie — sauf quand un dataset « temporaire » vit sur le vdev spécial pendant trois ans.

Mathématiques de dimensionnement à défendre en revue de changement

Il n’y a pas de formule parfaite unique parce que la taille des métadonnées dépend de recordsize, compression, distribution du nombre de fichiers, snapshots et fragmentation.
Mais vous pouvez arriver à une réponse conservatrice, explicable et opérationnellement sûre.

Étape 1 : Décidez si les petits blocs sont inclus

Si vous ne définirez special_small_blocks pas, vous dimensionnez principalement pour les métadonnées.
Si vous le ferez (valeurs courantes : 8K, 16K, 32K), vous devez budgéter pour les petits blocs de données aussi.

Étape 2 : Utilisez des règles empiriques (puis validez)

Points de départ pratiques qui ne vous feront pas renvoyer :

• Vdev spécial métadonnées uniquement : commencez à 0,5%–2% de la capacité brute du pool pour des charges de fichiers générales.
  Si vous avez beaucoup de petits fichiers, beaucoup de snapshots ou un churn élevé, visez plus.
• Métadonnées + petits blocs : commencez à 5%–15% selon votre seuil de petits blocs et la charge.
  Les images VM avec 8K–16K peuvent consommer rapidement la capacité spéciale.

La « fourchette » de dimensionnement n’est pas de l’indécision ; elle reflète qu’un pool stockant 10 millions de fichiers 4K se comporte différemment d’un pool stockant 20 To de médias.

Étape 3 : Convertir la règle empirique en un chiffre concret

Exemple : vous avez un pool HDD brut de 200 To.

• Vdev métadonnées uniquement à 1 % : special de 2 To.
• Métadonnées + petits blocs à 10 % : special de 20 To (là vous construisez une couche, pas un accessoire).

Si ces chiffres vous semblent « trop grands », c’est votre esprit ancré à l’idée que les métadonnées sont minuscules.
Votre future panne s’en fiche de ce que vous pensez.

Étape 4 : Appliquez une marge « ne vous collez pas dans un coin »

Le remplissage du vdev spécial est opérationnellement effrayant car il peut contraindre l’allocation des métadonnées.
Traitez-le comme un filesystem de log : vous ne le faites pas fonctionner à 95 % et appelez ça une victoire.

Une politique raisonnable :

• Utilisation cible en régime permanent : 50–70%
• Alerte à : 75%
• Stoppez tout à : 85%

Étape 5 : Tenez compte de la surcharge de redondance du vdev spécial

Un vdev spécial mirror divise la capacité utilisable par deux. Deux NVMe de 3,84 To vous donnent ~3,84 To utilisables (moins slop/overhead).
Si votre calcul dit « besoin de 2 To », n’achetez pas « deux 1,92 To » en espérant. Achetez plus grand. L’endurance SSD et l’amplification d’écriture existent.

Étape 6 : Considérez l’endurance (DWPD) si les petits blocs sont sur le special

Les écritures de métadonnées ne sont pas gratuites, mais elles sont souvent gérables.
Les petits blocs peuvent transformer le vdev spécial en une couche d’écriture intensive, surtout avec les charges VM, bases de données et churn élevé.
Si vous routez des petits blocs, choisissez des SSD avec une endurance appropriée et surveillez les taux d’écriture.

Le dimensionnement du vdev spécial est aussi une décision de risque

Sous-dimensionner signifie :

• cliff de performance quand il se remplit,
• panique opérationnelle lors des pics de croissance,
• et dans les pires cas, instabilité du pool si l’allocation de métadonnées est contrainte.

Sur-dimensionner signifie :

• un peu d’espace SSD inutilisé,
• une ligne d’achat légèrement plus élevée,
• et moins de réunions d’urgence.

Choisissez votre douleur.

Dimensionnement selon la charge (VMs, fichiers, sauvegarde, type objet)

Fileserver général (répertoires personnels, stockage partagé)

C’est là que les vdevs spéciaux brillent. Les parcours de répertoires et les ouvertures de fichiers sont riches en métadonnées.
Pour des partages d’entreprise « normaux » avec un mélange de tailles de fichiers, les vdevs spéciaux métadonnées uniquement offrent souvent le meilleur rapport prix/efficacité.

Conseils de dimensionnement :

• Commencez à 1–2% de la capacité brute pour métadonnées uniquement.
• Si vous attendez des millions de petits fichiers, poussez vers 2–4%.
• Gardez special_small_blocks désactivé sauf si vous le justifiez par des schémas I/O observés.

Stockage VM (zvols, backing store hyperviseur)

Les charges VM sont celles où l’on devient gourmand et active special_small_blocks.
Ça peut très bien marcher car beaucoup d’I/O VM est petit et aléatoire.
Ça peut aussi dévorer votre vdev spécial, car le seuil agit comme un aspirateur : il ne se soucie pas si le bloc est « important », seulement s’il est petit.

Conseils de dimensionnement :

• Métadonnées uniquement : toujours utile, mais moins spectaculaire.
• Métadonnées + petits blocs : dimensionnez 8–15% brut selon volblocksize et profil I/O.
• Envisagez des pools séparés pour les charges VM critiques en latence plutôt que de surcharger un pool polyvalent.

Cibles de sauvegarde (grosses écritures séquentielles, dédup parfois)

Les dépôts de sauvegarde tendent à être des charges à gros blocs et streaming-friendly.
L’accélération des métadonnées aide pour la gestion des snapshots et les opérations sur répertoires, mais ce n’est pas toujours un atout évident.

• Vdev spécial métadonnées uniquement : un dimensionnement modeste (0,5–1,5%) suffit généralement.
• Petits blocs : souvent inutiles ; évitez sauf si vous avez mesuré un vrai problème d’I/O aléatoire.

Mises en page « type object » (beaucoup de petits objets, beaucoup de listings)

Si vous détournez ZFS en stockage objet avec des millions de petits fichiers, les métadonnées deviennent de première importance.
Le vdev spécial peut maintenir le système réactif lors d’énumérations de répertoire et de pics de stat.

• Prévoyez 2–5% métadonnées uniquement, selon la distribution des tailles d’objet.
• Surveillez la stratégie de snapshots ; les stores d’objets plus snapshots peuvent multiplier la rétention des métadonnées.

Choix de conception : mirrors, RAIDZ, ashift, redondance, et pourquoi rester ennuyeux

Miroirez-le, et dormez

Un vdev spécial n’est pas un « cache ». Traitez-le comme un stockage primaire du pool.
Utilisez des SSD en miroir (ou des triple mirrors si votre modèle de risque l’exige).
Le coût d’un disque supplémentaire est moins cher que d’expliquer au CFO pourquoi « le pool ne s’importe pas ».

Choisissez un ashift sensé

Utilisez ashift=12 pour la plupart des SSD et HDD modernes ; il s’aligne sur des secteurs 4K.
Se tromper d’ashift peut gaspiller de l’espace ou nuire aux performances.
En général, vous ne pouvez pas changer ashift après la création du vdev sans reconstruire.

Ne mélangez pas des SSD douteux avec des rôles critiques

Un SSD grand public avec un comportement power-loss douteux et une endurance médiocre n’est pas automatiquement mauvais,
mais le placer sur le vdev spécial est l’endroit où « probablement correct » devient « rapport d’incident ».
Si vous devez utiliser des SSD grand public, sur-provisionnez et miroirisez agressivement, et surveillez SMART comme si c’était vital.

Fixez les attentes : le vdev spécial améliore la latence, pas le débit

Votre débit séquentiel peut ne pas beaucoup changer.
Ce qui change, c’est l’expérience « petits aléatoires » : récupérations de métadonnées, petites lectures de blocs, et la chaîne de parcours de pointeurs pour trouver les données.
C’est du travail sur la latence, ce qui se traduit par « tout paraît plus rapide », pas « nous avons doublé le GB/s ».

Comprenez ce qui se passe quand le vdev spécial se remplit

Quand le vdev spécial manque d’espace, ZFS ne peut pas y placer de nouvelles métadonnées.
Le comportement dépend de l’implémentation et des feature flags, mais supposez :

• les performances se dégradent (les métadonnées vont sur des vdevs plus lents ou l’allocation devient contrainte),
• l’allocation devient fragmentée et étrange,
• et vous vous retrouvez plus proche d’un mode de défaillance au niveau pool que souhaité.

La bonne posture : ne le laissez pas se remplir. Agrandissez tôt.

Tâches pratiques avec commandes (et comment décider)

Ce ne sont pas des « jolis démos ». Ce sont les commandes que vous exécutez un mardi après-midi quand vous essayez d’éviter une panne jeudi.
Chaque tâche inclut ce qu’il faut surveiller et la décision à prendre en fonction du résultat.

Task 1: Identify whether you even have a special vdev (and its layout)

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
            sde                     ONLINE       0     0     0
            sdf                     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 de la sortie : Vous avez une classe special constituée d’une paire NVMe en miroir. Bien.
Si le vdev spécial est un disque unique, c’est une décision de risque à revoir immédiatement.

Décision : Si special n’est pas en mirror, planifiez une remédiation (reconstruction en mirrors via nouveau pool ou plan de migration).

Task 2: Check special vdev capacity pressure fast

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  120T   48T   256K   /tank

Signification de la sortie : L’espace du pool n’est pas la même chose que l’espace du vdev spécial. Cette commande n’affiche pas directement l’usage spécial.
Elle indique si la saturation globale du pool contribue à la fragmentation et au stress des allocations.

Décision : Si le pool lui-même est au-dessus d’environ 80% utilisé, attendez-vous à un comportement d’allocation dégradé partout et traitez le dimensionnement spécial comme plus urgent.

Task 3: Show allocation by vdev, including special

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        200T    152T    48T        -         -    38%    76%  1.00x  ONLINE
  raidz2-0  200T    148T    52T        -         -    39%    74%      -  ONLINE
  special  3.50T   3.10T   410G       -         -    52%    88%      -  ONLINE

Signification de la sortie : Le vdev spécial est à 88% de capacité. C’est la zone dangereuse. La fragmentation est aussi élevée.

Décision : Planifiez l’expansion du vdev spécial maintenant. N’attendez pas 95%. Votre marge est déjà partie.

Task 4: Confirm whether small blocks are being routed to special

cr0x@server:~$ zfs get -r special_small_blocks tank
NAME            PROPERTY              VALUE                  SOURCE
tank            special_small_blocks  0                      default
tank/vmstore    special_small_blocks  16K                    local
tank/home       special_small_blocks  0                      inherited from tank

Signification de la sortie : Seul tank/vmstore route les blocs ≤16K vers special. Ce dataset est probablement le moteur de croissance.

Décision : Si special se remplit, identifiez d’abord quels datasets ont special_small_blocks non nuls et évaluez s’ils en ont encore besoin.

Task 5: Check how many snapshots you’re carrying (metadata pressure indicator)

cr0x@server:~$ zfs list -t snapshot -o name,used -S used | head
NAME                               USED
tank/vmstore@hourly-2025-12-26     2.3T
tank/vmstore@hourly-2025-12-25     2.1T
tank/home@daily-2025-12-25         320G
tank/vmstore@hourly-2025-12-24     1.9T

Signification de la sortie : Beaucoup de snapshots avec un grand « used » suggèrent que la rétention garde des arbres de pointeurs anciens vivants.
Le travail sur les métadonnées et les spacemaps augmente avec le nombre et le churn des snapshots.

Décision : Resserrez la rétention des snapshots si elle n’est pas alignée sur les besoins de récupération, ou planifiez plus de capacité spéciale pour soutenir l’exigence réelle.

Task 6: Spot dataset patterns that create metadata storms (many tiny files)

cr0x@server:~$ zfs get -r recordsize,compression,atime,xattr tank/home
NAME       PROPERTY     VALUE     SOURCE
tank/home  recordsize   128K      default
tank/home  compression  lz4       local
tank/home  atime        off       local
tank/home  xattr        sa        local

Signification de la sortie : Des valeurs par défaut sensées. xattr=sa peut réduire les I/O supplémentaires en stockant les xattrs dans le dnode (quand c’est possible).
Cela peut déplacer les schémas de métadonnées, souvent en mieux, mais cela reste dans le « domaine des métadonnées ».

Décision : Gardez ces paramètres cohérents ; évitez des ajustements aléatoires par dataset sauf si vous pouvez les justifier.

Task 7: Check for dedup (special vdev sizing changes drastically)

cr0x@server:~$ zpool get dedup tank
NAME  PROPERTY  VALUE  SOURCE
tank  dedup     off    default

Signification de la sortie : Dedup est off. Bien ; les tables de dedup peuvent être massives et modifier drastiquement le calcul de dimensionnement/endurance.

Décision : Si dedup est activé, revoyez le dimensionnement spécial avec une précaution extrême ; vous pourriez avoir besoin de beaucoup plus de capacité SSD et de RAM.

Task 8: See whether metadata is actually hitting the special vdev (iostat by vdev)

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         152T    48T  1.20K  3.80K   95M  210M
  raidz2-0   148T    52T    200  1.10K   70M  180M
    sda         -      -     30    180   11M   30M
    sdb         -      -     28    175   10M   30M
    sdc         -      -     32    185   12M   32M
    sdd         -      -     33    190   12M   32M
    sde         -      -     35    185   12M   31M
    sdf         -      -     42    185   13M   31M
  special   3.10T   410G  1.00K  2.70K   25M   30M
    mirror-1     -      -  1.00K  2.70K   25M   30M
      nvme0n1    -      -    520  1.40K   12M   15M
      nvme1n1    -      -    480  1.30K   13M   15M

Signification de la sortie : Le special effectue la plupart des opérations (IOPS), même si la bande passante est modeste. C’est typique : les métadonnées sont IOPS-heavy, pas bandwidth-heavy.

Décision : Si special est saturé en IOPS (await élevé sur NVMe, mise en file), vous pourriez avoir besoin d’élargir la classe special ou d’utiliser des SSD plus rapides — pas seulement plus de capacité.

Task 9: Check TRIM support and whether it’s enabled (affects SSD longevity and performance)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Signification de la sortie : Autotrim est activé. Cela aide les SSD à maintenir les performances et réduit l’amplification d’écriture dans de nombreux cas.

Décision : Si autotrim est désactivé sur des special vdevs SSD, envisagez de l’activer (après validation de la stabilité du trim sur votre plateforme).

Task 10: Confirm special vdev devices are healthy at the disk level (SMART)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep "Critical Warning|Percentage Used|Media and Data Integrity Errors|Data Units Written"
Critical Warning:                   0x00
Percentage Used:                    18%
Media and Data Integrity Errors:    0
Data Units Written:                 62,114,928

Signification de la sortie : Pas d’avertissement critique, 18% d’endurance consommée, pas d’erreurs média. Bien.

Décision : Si Percentage Used est élevé ou que des erreurs média apparaissent, planifiez un remplacement proactif — les vdevs spéciaux ne sont pas un endroit pour « attendre et voir ».

Task 11: Estimate how much space is tied up in metadata-heavy datasets (rough indicator)

cr0x@server:~$ zfs list -o name,used,logicalused,compressratio -S used tank | head
NAME         USED  LOGICALUSED  COMPRESSRATIO
tank/vmstore 78T   110T        1.41x
tank/home    22T   26T         1.18x
tank/backup  18T   19T         1.05x

Signification de la sortie : Le stockage VM domine et est compressé, ce qui corrèle souvent avec des blocs sur disque plus petits et plus d’activité de métadonnées.

Décision : Traitez tank/vmstore comme le principal moteur du dimensionnement et de la planification d’endurance du vdev spécial.

Task 12: See if your special vdev is being used for normal data because of small-block settings

cr0x@server:~$ zdb -bbbbb tank/vmstore | head -n 30
Dataset tank/vmstore [ZPL], ID 54, cr_txg 12345, 4.20T, 10.2M objects
  bpobj: 0x0000000000000000
  flags: 
  dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED
  features: 
    org.openzfs:spacemap_histogram
    org.openzfs:allocation_classes
...

Signification de la sortie : La présence de org.openzfs:allocation_classes indique que les classes d’allocation sont en usage.
Cela ne quantifie pas l’usage, mais confirme que le pool supporte l’ensemble de fonctionnalités.

Décision : Si vous ne voyez pas les features d’allocation et que vous pensiez avoir un vdev spécial, vous êtes soit sur une pile plus ancienne soit sur une implémentation différente.
Ajustez les attentes et confirmez avec zpool status.

Task 13: Detect whether you’re near the “special full” cliff

cr0x@server:~$ zpool list -Ho name,cap,frag tank
tank	76%	38%

Signification de la sortie : Le pool global est à 76% et fragmenté à 38%. La fragmentation augmente le travail des métadonnées et l’overhead d’allocation.

Décision : Si la fragmentation augmente et que le special est aussi en haute capacité, priorisez l’expansion ; vous vous dirigez vers une douleur composée.

Task 14: Add a new mirrored special vdev (capacity expansion done the sane way)

cr0x@server:~$ sudo zpool add tank special mirror /dev/nvme2n1 /dev/nvme3n1

Signification de la sortie : Cela ajoute un nouveau vdev spécial en miroir au pool, augmentant la capacité et les IOPS du special.
Les métadonnées existantes ne migrent pas automatiquement, mais de nouvelles allocations peuvent utiliser l’espace ajouté selon le comportement et la config.

Décision : Si special est au-dessus de 75–80%, l’expansion est un changement de production à réaliser plutôt tôt que tard.
Validez le modèle/firmware des appareils et les implications d’ashift avant de vous engager.

Task 15: Confirm the pool now shows the additional special vdev

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
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
          special
            mirror-1                ONLINE       0     0     0
              nvme0n1               ONLINE       0     0     0
              nvme1n1               ONLINE       0     0     0
            mirror-2                ONLINE       0     0     0
              nvme2n1               ONLINE       0     0     0
              nvme3n1               ONLINE       0     0     0

errors: No known data errors

Signification de la sortie : Deux mirrors special existent. Votre classe special est maintenant plus large et plus grande.

Décision : Mettez à jour la surveillance pour suivre l’usage de la classe special et la santé des appareils sur les deux mirrors.

Task 16: Verify which datasets are candidates for turning off small-block placement (risk control)

cr0x@server:~$ zfs get -r -s local special_small_blocks tank | grep -v "VALUE *0"
tank/vmstore  special_small_blocks  16K  local

Signification de la sortie : Un seul dataset l’a défini localement.

Décision : Si la capacité special est la contrainte, envisagez d’abaisser le seuil (par ex. 16K → 8K) ou de le désactiver sur des datasets moins critiques.
Ne le changez pas aveuglément ; testez d’abord les impacts sur la latence.

Playbook de diagnostic rapide

Vous recevez une page : « Le pool ZFS est lent. » Vous suspectez le vdev spécial parce que le pool allait bien auparavant et maintenant les listings de répertoire ramment.
Voici le chemin le plus rapide vers une hypothèse de cause racine sans en faire un projet d’archéologie d’une semaine.

Premier point : le vdev spécial est-il proche d’être plein ?

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        200T    152T    48T        -         -    38%    76%  1.00x  ONLINE
  raidz2-0  200T    148T    52T        -         -    39%    74%      -  ONLINE
  special  3.50T   3.10T   410G       -         -    52%    88%      -  ONLINE

Si special est au-dessus d’environ 80%, considérez cela comme le suspect principal. La saturation corrèle avec des allocations contraintes et des pics de latence.
Décision : agrandissez la classe special ou réduisez l’usage de special_small_blocks avant de chasser d’autres réglages.

Deuxième point : le vdev spécial est-il saturé en IOPS ou en latence ?

cr0x@server:~$ zpool iostat -v tank 1 10
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         152T    48T  1.60K  5.10K  120M  260M
  raidz2-0   148T    52T    220  1.30K   80M  190M
  special   3.10T   410G  1.38K  3.80K   40M   70M

Si special domine les ops et que le système est lent, c’est cohérent avec une pression sur les métadonnées.
Décision : si NVMe est saturé, pensez à élargir la classe special (un autre mirror) ou à utiliser des périphériques plus rapides.

Troisième point : quelqu’un a-t-il routé des petits blocs vers special et oublié ?

cr0x@server:~$ zfs get -r special_small_blocks tank
NAME            PROPERTY              VALUE                  SOURCE
tank            special_small_blocks  0                      default
tank/vmstore    special_small_blocks  16K                    local
tank/home       special_small_blocks  0                      inherited from tank

Si c’est défini sur un dataset occupé, c’est probablement la vraie raison pour laquelle special a grandi plus vite que prévu.
Décision : conservez-le, réduisez-le ou limitez-le aux datasets qui en tirent réellement bénéfice.

Quatrième point : le problème est-il en fait une fragmentation globale du pool ou une pression de capacité générale ?

cr0x@server:~$ zpool list -Ho cap,frag tank
76%	38%

Si la capacité du pool est élevée et que la fragmentation augmente, les performances peuvent se dégrader même avec un vdev spécial sain.
Décision : libérez de l’espace, ajoutez de la capacité et ajustez la rétention/le churn.

Cinquième point : le périphérique spécial est-il malade (SMART, erreurs, resets) ?

cr0x@server:~$ dmesg | egrep -i "nvme|I/O error|reset|timeout" | tail -n 10
[123456.789] nvme nvme0: I/O 987 QID 6 timeout, aborting
[123456.790] nvme nvme0: Abort status: 0x371
[123456.800] nvme nvme0: reset controller

Si vous voyez des resets/timeouts, ne « tunez pas ZFS ». Réparez le chemin matériel/firmware.
Décision : remplacez le périphérique, mettez à jour le firmware, vérifiez la topologie PCIe, la gestion d’alimentation et le câblage (si U.2/U.3).

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: Directory listings and find are suddenly slow

Cause racine : Le vdev spécial est proche d’être plein ou saturé en IOPS métadonnées ; les métadonnées déversent sur les HDD ou l’allocation est contrainte.

Correction : Vérifiez zpool list -v. Si special cap > 80%, élargissez la classe special (ajoutez une autre paire mirror). Si elle est saturée, élargissez-la ou utilisez des SSD plus rapides.

2) Symptom: Pool “looks healthy” but application latency spikes during snapshot windows

Cause racine : La création/suppression de snapshots augmente les opérations métadata ; le vdev spécial devient le goulot.

Correction : Réduisez la fréquence/retention des snapshots pour les datasets à fort churn ; planifiez l’élagage des snapshots hors pic ; augmentez la capacité et les IOPS du special si les snapshots sont non négociables.

3) Symptom: Special vdev fills unexpectedly fast after enabling special_small_blocks

Cause racine : Seuil trop élevé (ex. 32K) sur une charge avec beaucoup de petites écritures (VMs, bases de données), tiering effectif d’une grande fraction des données sur SSD.

Correction : Abaissez le seuil (ex. 16K → 8K), limitez-le aux datasets qui en bénéficient, et agrandissez le special avant de faire des changements en production.

4) Symptom: After adding a special vdev, performance didn’t improve much

Cause racine : La charge est majoritairement séquentielle et volumineuse ; les métadonnées n’étaient pas le goulot. Ou les misses ARC sont dominées par les données, pas les métadonnées.

Correction : Validez avec zpool iostat -v et les métriques applicatives. N’empilez pas les réglages ; les vdevs spéciaux ne sont pas un accélérateur universel.

5) Symptom: Pool import fails or hangs after losing an NVMe

Cause racine : Le vdev spécial n’était pas redondant ou la redondance n’était pas suffisante ; la perte de métadonnées empêche l’assemblage du pool.

Correction : En production, utilisez des vdevs spéciaux mirror. Si vous l’avez construit incorrectement, la bonne correction est la migration vers un pool conçu correctement.

6) Symptom: NVMe wear skyrockets

Cause racine : Le vdev spécial reçoit des écritures de petits blocs plus le churn des métadonnées ; autotrim est désactivé ; la classe d’endurance du SSD est insuffisante.

Correction : Activez autotrim si stable, choisissez des SSD à endurance supérieure, réduisez le scope du offload de petits blocs et surveillez SMART Percentage Used.

7) Symptom: “Random” performance regressions after upgrades or property changes

Cause racine : Les propriétés des datasets ont changé (recordsize/volblocksize/special_small_blocks), modifiant les schémas d’allocation et déplaçant l’I/O chaud sur special de façon inattendue.

Correction : Auditez les changements de propriétés avec zfs get -r (valeurs locales). Traitez special_small_blocks comme un changement contrôlé avec plan de rollback.

Trois mini-récits d’entreprise (anonymisés, douloureusement plausibles)

Incident causé par une mauvaise hypothèse : « Les métadonnées sont minuscules »

Une entreprise de taille moyenne avait un grand pool HDD supportant un partage de fichiers monolithique et un dépôt d’artifacts de build.
Ils ont ajouté un vdev spécial en miroir constitué de deux petits NVMe rapides. Le ticket de changement disait « les métadonnées sont petites ; 400 Go utilisables suffisent ».
Tout le monde a hoché la tête parce que tout le monde aime une victoire peu chère.

Pendant six mois, tout semblait parfait. Les builds se sont accélérés. Les répertoires personnels des développeurs semblaient réactifs. Quelqu’un a même écrit « ZFS special vdev = perf gratuite »
dans un chat, ce qui aurait dû être traité comme un indicateur pré-incident.

Puis une exigence de conformité est arrivée : fréquence de snapshots augmentée et rétention prolongée « au cas où ».
Les snapshots se sont accumulés. Les builds ont continué de churner. Beaucoup de petits fichiers ont été créés et supprimés. La capacité special a grimpé, mais personne ne surveillait la classe special séparément.
Ils regardaient la capacité du pool, voyaient beaucoup d’espace HDD libre et supposaient que tout allait bien.

Le premier symptôme n’a pas été une alerte. Ce furent des plaintes humaines : « ls est lent », « git status bloque », « les jobs CI time-out pendant le cleanup ».
Quand le SRE a regardé, le special était profondément dans les 90s, et le système passait son temps à effectuer des travaux d’allocation coûteux.
La correction a été simple mais désagréable : ajout d’urgence d’une autre paire mirror special, plus triage de la politique de snapshots.

La vraie cause racine n’était pas « ZFS est bizarre ». C’était croire que les métadonnées sont une note de bas de page à taille constante. Elles ne le sont pas.
Les métadonnées grandissent avec le churn et l’histoire. Et l’historique des snapshots est littéralement l’histoire stockée.

Optimisation qui a mal tourné : activer les petits blocs partout

Un autre service faisait de la virtualisation sur ZFS avec un pool hybride : HDD pour la capacité, vdev spécial pour les métadonnées.
Un sprint d’optimisation des performances a eu lieu parce que quelques VMs sensibles en latence étaient mécontentes aux heures de pointe.
Quelqu’un a lu à propos de special_small_blocks et décidé de « rendre le pool plus rapide » en le réglant sur le dataset parent pour qu’il s’hérite partout.

Le benchmark immédiat a été bon. Les VMs ciblées se sont améliorées. Le sprint s’est terminé par une belle diapo : « Nous utilisons des SSD pour les petits I/O ».
Personne n’a demandé quelle fraction des écritures totales était sous le seuil, ni si le vdev spécial avait le budget d’endurance pour être une couche partielle.

Deux trimestres plus tard, le special était très utilisé et l’usure NVMe alarmante.
Pire : la classe special est devenue un point d’étranglement unique pour les écritures aléatoires sur tout l’environnement de virtualisation.
Le pool n’était pas « plus rapide ». Il était « rapide jusqu’à ce que ce ne soit plus le cas », le pire type de rapidité.

Ils ont annulé le réglage pour la plupart des datasets et l’ont gardé seulement pour un petit sous-ensemble de VMs qui en avaient vraiment besoin.
Ils ont aussi élargi la classe special et standardisé sur des SSD à endurance supérieure.
La leçon a été retenue : special_small_blocks n’est pas un déjeuner gratuit ; c’est un choix de conception qui convertit les périphériques de métadonnées en couche.

Pratique ennuyeuse mais correcte qui a sauvé la mise : alertes sur CAP special et usure

Une équipe de services financiers a traité les vdevs spéciaux comme une infrastructure de première classe dès le départ.
Ils utilisaient des NVMe entreprise en miroir, ont activé autotrim, et — voici le plus fascinant — ont créé des alertes spécifiquement pour la capacité de la classe special,
pas seulement la capacité globale du pool.

Ils suivaient aussi les indicateurs d’usure NVMe et ont défini une politique de remplacement avant que les appareils ne deviennent critiques.
Quand la capacité special a atteint leur seuil d’avertissement, cela a déclenché un workflow normal de changement, pas une salle de crise.
L’équipe avait un playbook permanent : vérifier quels datasets utilisaient les petits blocs, contrôler la croissance des snapshots et prévoir la capacité.

Un an, un nouveau service interne a commencé à générer des millions de petits fichiers dans un dataset partagé.
Les alertes ont prévenu tôt. L’équipe stockage a rencontré l’équipe du service, a changé la mise en page et a étendu special avant que cela ne devienne un incident visible par les utilisateurs.
Personne en dehors de l’infra n’a remarqué, ce qui est le plus grand compliment en exploitation.

La pratique n’était pas intelligente. Elle était juste attentive : surveillance séparée pour le special, seuils conservateurs et revues de capacité routinières.
L’ennui est une fonctionnalité.

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

Étape par étape : dimensionner un nouveau vdev spécial

1. Classifiez la charge : accélération métadonnées uniquement vs métadonnées + petits blocs.
   Si vous ne pouvez pas répondre, arrêtez et mesurez d’abord les schémas I/O.
2. Choisissez un ratio de départ :
   • Métadonnées uniquement : 1–2% pool brut (2–4% si beaucoup de petits fichiers/snapshots).
   • Métadonnées + petits blocs : 5–15% pool brut (plus si VM-heavy et seuil petit).
3. Ajoutez une marge : dimensionnez pour que l’opération normale reste sous 70% d’utilisation de la classe special.
4. Choisissez la redondance : vdevs spéciaux en mirror. Aucune exception en production sauf si vous aimez jouer.
5. Choisissez la classe de SSD : privilégiez PLP (power-loss protection) et une endurance adéquate, surtout si les petits blocs sont routés.
6. Mettez en place la surveillance : suivez special cap, special frag, erreurs/resets NVMe, usure SMART et changements de zpool status.
7. Déployez prudemment : si vous activez le placement des petits blocs, faites-le par dataset et validez avant d’étendre.

Étape par étape : quand le special est déjà trop petit

1. Confirmez la cap du special avec zpool list -v.
2. Identifiez les datasets moteurs de croissance via zfs get -r special_small_blocks et les comptes de snapshots.
3. Élargissez la classe special en ajoutant une autre paire mirror special.
4. Réduisez la pression future : baissez le seuil special_small_blocks ou limitez-le aux datasets critiques seulement.
5. Corrigez la rétention : politiques de snapshots alignées sur RPO/RTO réels, pas l’anxiété.
6. Re-vérifiez l’usure : assurez-vous que le budget d’endurance SSD tient toujours.

Checklist opérationnelle : hebdomadaire (oui, hebdomadaire)

• Vérifier zpool status pour toute erreur de périphérique.
• Vérifier zpool list -v et alerter si special cap > 75%.
• Vérifier l’usure SMART des périphériques special.
• Auditer les datasets avec special_small_blocks activé.
• Revoir les comptes de snapshots et élaguer de façon responsable.

FAQ

1) Can I treat the special vdev like a cache?

Non. L2ARC est un cache. SLOG est un périphérique de log. Les vdevs spéciaux peuvent contenir des métadonnées critiques du pool. Les perdre peut signifier perdre le pool.
Concevez-le comme du stockage primaire.

2) How do I know if I should enable special_small_blocks?

Activez-le uniquement si vous avez mesuré un problème d’I/O aléatoire sur des vdevs HDD et que vous avez le budget capacité/endurance SSD.
Les stores VM sont des candidats courants ; les partages de fichiers généraux s’en sortent souvent bien avec un special métadonnées uniquement.

3) What value should I use for special_small_blocks?

Valeurs conservatrices : 8K ou 16K pour des datasets ciblés. Des seuils plus élevés capturent plus d’I/O mais consomment la capacité spéciale plus vite.
Commencez petit, mesurez, puis élargissez si nécessaire.

4) What happens when the special vdev fills up?

Meilleur cas : les performances se dégradent à mesure que les allocations deviennent contraintes et le placement des métadonnées moins optimal.
Pire cas : instabilité ou échecs liés aux allocations. Traitez « special proche du plein » comme un problème de capacité urgent.

5) Can I remove a special vdev later?

Planifiez comme si la réponse était « non ». Dans de nombreuses déploiements de production, retirer des vdevs spéciaux n’est pas supporté ou pas pratique.
Considérez cela comme une porte sans retour et dimensionnez en conséquence.

6) Should special vdevs be NVMe, SATA SSD, or something else?

NVMe est idéal pour les IOPS et la latence des métadonnées. Un SSD SATA peut quand même beaucoup aider par rapport aux HDD.
Plus votre charge est riche en métadonnées, plus la faible latence du NVMe est importante.

7) Does adding more special vdev mirrors improve performance?

Souvent, oui. Plus de mirrors augmentent la capacité IOPS et réduisent la mise en file. Cela augmente aussi la capacité.
Mais cela ne résoudra pas un pool fondamentalement surchargé ou un churn dataset pathologique.

8) Is it safe to use RAIDZ for special vdevs?

Les mirrors sont la recommandation par défaut pour une raison : comportement de rebuild prévisible et domaines de défaillance plus simples.
Si vous envisagez RAIDZ pour le special, vous devriez être capable d’expliquer le temps de rebuild, la tolérance aux défaillances et l’impact opérationnel en détail.

9) How does special vdev sizing relate to ARC/RAM?

L’ARC aide à cacher métadonnées et données en RAM. Un vdev spécial réduit la pénalité quand les métadonnées ne sont pas dans l’ARC.
Si l’ARC est sous-dimensionné, les vdevs spéciaux aident toujours, mais vous pourriez masquer un problème de mémoire.

10) If I add special vdevs, will existing metadata move onto them?

N’assumez pas qu’il y aura une « rééquilibrage magique » qui réparera le passé. Certaines nouvelles allocations utiliseront la nouvelle capacité special,
mais le comportement de migration dépend des détails d’implémentation et du churn de la charge. Planifiez les expansions avant d’être en feu.

Prochaines étapes à réaliser cette semaine

Si vous avez déjà des vdevs spéciaux : vérifiez leur capacité et leur santé aujourd’hui. Le remplissage special est un de ces problèmes qui restent silencieux jusqu’à devenir bruyants.

1. Exécutez zpool list -v et enregistrez la CAP du special. Si elle est au-dessus de 75%, ouvrez un ticket de changement capacité.
2. Exécutez zfs get -r special_small_blocks et faites la liste des datasets qui l’utilisent. Validez que chacun est intentionnel.
3. Passez en revue les comptes de snapshots et la rétention. Si vous gardez l’historique « juste au cas où », vous le payez en métadonnées.
4. Ajoutez de la surveillance pour l’utilisation de la classe special et l’usure NVMe. Si vous ne surveillez que la capacité globale du pool, vous regardez le mauvais tableau de bord.
5. Si vous concevez un nouveau pool, dimensionnez le special pour que le régime permanent reste sous 70%, miroirisez-le et achetez des SSD avec une endurance adaptée à votre charge.

Le meilleur dimensionnement du vdev spécial est celui que vous n’aurez jamais à expliquer pendant un incident.
Préférez l’ennui, la redondance et une taille légèrement supérieure à ce que votre ego pense nécessaire.