Lectures uniquement de métadonnées ZFS : comment le vdev spécial change la donne

Que signifient réellement les « lectures uniquement de métadonnées » dans ZFS

« Lectures uniquement de métadonnées » décrit une situation où la charge applicative ressemble à de la lecture de fichiers, mais ZFS lit principalement
les structures qui décrivent les fichiers. Pensez à la traversée d’annuaires, aux vérifications de permissions, à la gestion de type inode, aux arbres de snapshots,
et aux pointeurs de blocs qui mènent aux vrais blocs de données.

En termes ZFS, cela est dominé par des blocs tels que :

• Blocs indirects (pointeurs de blocs décrivant où se trouvent les données).
• Dnodes (métadonnées des objets : type, taille, pointeurs de blocs, bonus buffer).
• Objets ZAP (magasins nom/valeur utilisés massivement pour les répertoires et les propriétés).
• Space maps / metaslabs (comptabilité d’allocation ; peuvent apparaître dans des schémas pathologiques).
• DDT si dedup est activé (plus d’informations : s’il vous plaît ne le faites pas, sauf si vous le voulez vraiment).

Une charge lourde en métadonnées peut afficher de piètre « MB/s » tout en saturant les IOPS et les budgets de latence. Le pool semble inactif aux personnes qui
surveillent uniquement le débit. Pendant ce temps, votre application voit un « stockage lent » parce que chaque recherche de métadonnée est une lecture aléatoire et que les lectures aléatoires sur
HDD sont essentiellement une négociation avec la physique.

Le secret gênant : beaucoup de charges « lecture » sont en réalité des charges de recherche. Une ferme de compilation réalisant des millions de petits stat de fichiers.
Un serveur mail parcourant des répertoires. Une plateforme de conteneurs énumérant des couches. Un logiciel de sauvegarde qui fait un scan préliminaire de tout avant de lire un octet.
Ce sont des tâches de métadonnées qui lisent occasionnellement des données.

Une citation à garder collée sur l’écran, en paraphrasant l’idée :
paraphrased idea: Everything fails; what matters is building systems that fail predictably and recover quickly.
— John Allspaw

Les vdevs spéciaux sont un moyen de rendre les modes de défaillance des métadonnées moins dramatiques : latence plus faible, moins de timeouts, moins de retries, moins d’incidents en cascade.
Mais seulement si vous respectez ce qu’ils sont.

Vdev spécial : ce que c’est, et ce que ce n’est pas

Un vdev spécial est une classe d’allocation dans OpenZFS. C’est un endroit où ZFS peut stocker certaines catégories de blocs,
typiquement les métadonnées et (optionnellement) les blocs de « petits » fichiers, sur une classe de vdev plus rapide que le pool principal.

La vérité opérationnelle la plus importante : un vdev spécial n’est pas un cache. Ce n’est pas un L2ARC. Ce n’est pas un « on mettra peut-être quelque chose là-bas et si ça meurt on haussera les épaules ».
Si un vdev spécial est perdu, le pool est typiquement perdu, parce que ces blocs font partie de la structure disque faisant foi du pool.

Vous déplacez des organes critiques du système de fichiers vers un autre média. Traitez cela comme déplacer le WAL d’une base de données vers un autre disque : ça peut être brillant, et ça peut être fatal.

Ce qui va par défaut sur special

Avec un vdev spécial présent, ZFS allouera par défaut la métadonnée là-bas (sous réserve des détails d’implémentation et de l’espace disponible). Cela inclut les dnodes, les blocs indirects,
les structures de répertoire (ZAP) et d’autres objets de métadonnées.

Ce qui peut aller sur special si vous le demandez

La propriété de dataset special_small_blocks vous permet de pousser également les blocs de données de petits fichiers vers special.
C’est le réglage qui transforme un « accélérateur de métadonnées » en « accélérateur de petites I/O ».

C’est ici que les gens s’enthousiasment puis se font virer. Nous verrons comment le faire sans la deuxième partie.

Blague n°1 : Les vdevs spéciaux sont comme l’espresso — transforment la vie à la bonne dose, et une terrible idée si vous continuez à « optimiser » jusqu’à 3h du matin.

Comment le vdev spécial modifie le chemin de lecture

Sans vdev spécial, les lectures de métadonnées se comportent comme n’importe quelles autres lectures : ZFS parcourt les pointeurs, récupère les blocs depuis les mêmes vdevs qui hébergent les données,
et compte beaucoup sur l’ARC pour éviter des hits répétés sur disque. ARC aide, mais un cache froid, un ensemble de travail surdimensionné, ou un scan agressif peut évincer les métadonnées et forcer un vrai I/O.

Avec un vdev spécial, les blocs qui décrivent le système de fichiers sont placés sur une classe de vdev typiquement SSD ou NVMe. Le résultat :

• Les I/O aléatoires de métadonnées passent des seeks HDD aux lectures SSD.
• Effondrement de la latence : pas seulement une latence moyenne plus faible, mais beaucoup moins de latences extrêmes.
• Plus grande concurrence effective : des opérations qui étaient sérialisées par le déplacement de la tête du disque deviennent parallélisées.
• ARC devient plus efficace : les métadonnées récupérées rapidement réduisent les temps d’attente et améliorent le comportement de réchauffement du cache.

La nuance importante : le vdev spécial n’élimine pas magiquement les I/O de métadonnées. Il les rend suffisamment bon marché pour qu’elles ne dominent plus.
Votre goulot d’étranglement peut alors se déplacer ailleurs : CPU (compression), réseau, verrous applicatifs, ou les vdevs de données principaux.
C’est un bon problème. Du moins c’est honnête.

Lectures uniquement de métadonnées en pratique

Quelques schémas qui produisent des « lectures majoritairement de métadonnées » :

• Grandes traversées de répertoires : appels répétés de readdir(), stat(), vérifications de permissions.
• Datasets fortement axés sur les snapshots : listes de snapshots, clones et envois avec coût élevé de traversée.
• Vérification de sauvegarde : opérations « comparer la liste de fichiers » qui touchent tout.
• Dépaquetage d’images de conteneurs : nombreux petits fichiers, nombreuses mises à jour et recherches de métadonnées.
• Systèmes de build : fichiers minuscules, beaucoup de vérifications d’existence, forte activité de métadonnées.

Faits et historique importants en production

Quelques points de contexte qui vous aident à raisonner sur les vdevs spéciaux et le comportement des métadonnées, sans transformer votre revue d’incident en séminaire de troisième cycle :

1. ZFS a été conçu pour l’intégrité de bout en bout : les métadonnées ne sont pas optionnelles ; les perdre empêche d’interpréter les blocs de données en toute sécurité.
2. ARC précède le « vdev spécial » en tant que fonctionnalité courante : l’optimisation des performances ZFS reposait d’abord sur la RAM et la disposition, pas sur les classes d’allocation.
3. L2ARC est arrivé avant le vdev spécial : L2ARC est un cache et peut être perdu ; le vdev spécial est du stockage et ne peut pas l’être.
4. L’idée « métadonnées sur SSD » existait bien avant ZFS : systèmes de fichiers et baies ont utilisé des NVRAM/SSD en miroir pour des maps et journaux pendant des décennies.
5. Les classes d’allocation d’OpenZFS ont mûri avec le temps : les jeux de fonctionnalités initiaux étaient conservateurs ; les déploiements modernes utilisent régulièrement les vdevs spéciaux pour des charges mixtes.
6. Les tables de dédup (DDT) sont des métadonnées dopées : quand dedup est activé, le DDT peut dominer les lectures aléatoires et l’usage mémoire.
7. Les blocs indirects peuvent représenter une grande fraction des I/O : surtout avec de gros fichiers et des lectures aléatoires, vous pouvez être limité par la chasse aux pointeurs.
8. Les vdevs spéciaux ont changé le « problème des petits fichiers » : pousser les blocs de petits fichiers vers SSD fait souvent la différence entre « ça va » et « pourquoi ls prend des secondes ? »

Le résumé : le vdev spécial n’est pas une fonctionnalité gadget. C’est ZFS reconnaissant que la latence des métadonnées est souvent le véritable ennemi, et que rajouter des HDD est une forme triste d’exercice.

Quand le vdev spécial est un grand bénéfice (et quand il est inutile)

Scénarios avec gros bénéfices

• Millions de petits fichiers où la traversée de répertoires et les stat dominent.
• Hôtes de virtualisation ou conteneurs avec beaucoup de petits fichiers de configuration et de fréquentes recherches.
• Cibles de sauvegarde où les phases de scan/vérification sont le goulot.
• Datasets fortement orientés snapshots où le coût des parcours de métadonnées se manifeste lors des opérations send/list.
• Pools avec dedup activé (encore : uniquement si vous le voulez vraiment) où les lectures DDT dominent ; special peut aider, mais la RAM compte encore plus.

Scénarios inutiles ou marginaux

• Charges de streaming lisant de gros fichiers contigus (média, archives). Votre goulot est la bande passante séquentielle, pas les métadonnées.
• ARC contient déjà l’ensemble de travail. Si toutes les métadonnées sont résidentes, le vdev spécial n’apportera pas de gain spectaculaire.
• Charges dominées par des écritures synchrones. Là c’est le domaine du SLOG, pas du vdev spécial.

Où les gens se trompent sur le bénéfice

L’hypothèse classique erronée est « notre pool est lent parce que les HDD sont lents, donc les SSD vont réparer ça. » Parfois vrai. Souvent faux.
Si votre douleur est la latence sur des lectures aléatoires de métadonnées, le vdev spécial est une correction chirurgicale.
Si votre douleur est « on est CPU-bound sur la compression » ou « l’application fait une opération à la fois », alors le vdev spécial embellira surtout vos graphiques.

Concevoir des agencements sensés pour le vdev spécial

Voici la ligne directrice qui vous garde employable : mettez le vdev spécial en miroir. Si vous ne pouvez pas vous permettre la redondance pour lui,
vous ne pouvez pas vous permettre la fonctionnalité.

Règles de redondance qui ne se plient pas

• Utilisez des mirrors pour les vdevs spéciaux dans la plupart des environnements. Les RAIDZ pour special existent, mais les mirrors gardent la latence basse et les domaines de défaillance clairs.
• Égalez ou dépassez la posture de fiabilité du pool. Si vos vdevs de données sont en RAIDZ2, votre special ne devrait pas être un seul SSD « parce que c’est enterprise ».
• Prévoyez l’usure. Les métadonnées peuvent être intensives en écritures en cas de churn. Choisissez des SSD avec une endurance réelle, pas « celui qui était en promo ».

Dimensionnement : la partie que tout le monde devine mal

Sous-dimensionnez le special et vous atteindrez 80–90 % d’utilisation, l’allocation devient contrainte et les performances deviennent étranges de façons non évidentes.
Sur-dimensionnez et vous gaspillerez de l’argent, mais vous achèterez aussi la paix opérationnelle : marge de croissance, espace pour le rééquilibrage, moins de points de rupture.

Conseils pratiques de dimensionnement :

• Vdev spécial dédié aux métadonnées : dimensionnez-le suffisamment généreusement pour qu’il reste confortablement sous ~70 % d’utilisation en régime permanent.
• Métadonnées + petits blocs : supposez qu’il devienne une couche chaude. Dimensionnez-le comme vous dimensionneriez un vrai dataset, car il en tient lieu.
• Environnements à fort usage de snapshots : les métadonnées grossissent avec l’historique. Budgétez pour cela. « On supprimera les snapshots plus tard » n’est pas une stratégie ; c’est une histoire pour dormir.

special_small_blocks : un couteau tranchant

Définir special_small_blocks sur une valeur non nulle signifie que tous les blocs de taille inférieure ou égale à cette valeur sont alloués sur special.
Si vous le mettez à 128K sur un dataset avec recordsize=128K, félicitations : vous venez de dire à ZFS de mettre pratiquement toutes les données sur special. Les gens font ça accidentellement. Ensuite ils apprennent de nouveaux sentiments.

Une approche conservatrice :

• Commencez par 0 (métadonnées seulement), mesurez, puis envisagez 16K ou 32K pour les charges de petits fichiers.
• Appliquez-le par dataset, pas comme une « optimisation » globale du pool. Vos images VM n’en ont pas besoin ; votre arbre source peut en bénéficier.
• Documentez-le. Le vous du futur est un inconnu qui blâmera le vous du présent.

Blague n°2 : Mettre special_small_blocks=128K sur un dataset occupé, c’est comme mettre tout votre bureau sur le Wi‑Fi invité parce que « ça a testé plus vite ».

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

Ce sont les vérifications quotidiennes qui séparent « j’ai lu sur les vdevs spéciaux » de « je peux les exploiter à 2h du matin sans improviser ».
Chaque tâche inclut une commande, une sortie d’exemple, ce que cela signifie, et la décision que vous prenez.

Task 1: Confirm pool layout and special class presence

cr0x@server:~$ sudo 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
            nvme0n1p1               ONLINE       0     0     0
            nvme1n1p1               ONLINE       0     0     0

errors: No known data errors

Signification : Une section special existe et est en mirror. Bien. Si vous ne voyez pas special, vous n’en avez pas.

Décision : Si special est absent et que les métadonnées sont un goulot, planifiez un ajout. S’il est présent mais sur un seul disque, traitez cela comme un bug de fiabilité.

Task 2: Verify allocation class stats (are bytes actually landing there?)

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        109T  72.4T  36.6T        -         -    18%    66%  1.00x  ONLINE  -
  raidz2-0  109T  70.9T  38.1T        -         -    18%    65%      -  ONLINE
  special   3.64T  1.52T  2.12T        -         -     9%    41%      -  ONLINE

Signification : Special a de l’allocation. Si c’est proche de zéro alors que vous vous attendez à y trouver des métadonnées, quelque chose cloche (pas de special au moment de la création, ou blocs préexistent).

Décision : Si special est sous-utilisé alors qu’il devrait être utilisé, vérifiez les propriétés des datasets et considérez si les données existantes doivent être réécrites/migrées pour en bénéficier.

Task 3: Check dataset settings that drive block placement

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received special_small_blocks,recordsize,atime,compression tank/projects
NAME           PROPERTY              VALUE
tank/projects  special_small_blocks  32K
tank/projects  recordsize            128K
tank/projects  atime                 off
tank/projects  compression           zstd

Signification : Ce dataset poussera les blocs ≤32K vers special. Avec recordsize=128K, seuls les vrais petits fichiers/blocs y seront.

Décision : Si special se remplit trop vite, baissez ou remettez à zéro special_small_blocks. Si la latence des métadonnées reste mauvaise, envisagez de l’augmenter prudemment.

Task 4: Find out whether your “slow read” is metadata (ARC stats view)

cr0x@server:~$ sudo arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   560    90     16    40   44    22   24    28   31   64G   96G
12:01:02   610   110     18    55   50    24   22    31   28   64G   96G
12:01:03   590   105     17    52   50    25   24    28   27   64G   96G
12:01:04   605   120     20    62   52    28   23    30   25   64G   96G
12:01:05   575   115     20    60   52    27   23    28   24   64G   96G

Signification : Des misses de métadonnées élevés (dmis/mmis) indiquent que les métadonnées ne restent pas dans l’ARC et sont récupérées depuis le disque/special.

Décision : Si le taux de misses des métadonnées est élevé et que la latence gêne, le vdev spécial aide. Si special existe, vérifiez qu’il n’est pas saturé ou mal dimensionné.

Task 5: Measure vdev-level latency during a “metadata storm”

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                 capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        72.4T  36.6T    820    190  18.2M  4.5M
  raidz2-0  70.9T  38.1T    260    160   6.1M  4.0M
    sda         -      -     45     26   1.1M   700K
    sdb         -      -     43     25   1.0M   680K
    sdc         -      -     44     27   1.1M   710K
    sdd         -      -     42     26   1.0M   690K
    sde         -      -     44     28   1.1M   720K
    sdf         -      -     42     28   1.0M   720K
  special   1.52T  2.12T    560     30  12.1M   520K
    mirror-1     -      -    560     30  12.1M   520K
      nvme0n1p1  -      -    280     15   6.0M   260K
      nvme1n1p1  -      -    280     15   6.1M   260K

Signification : Les lectures frappent fortement special. C’est attendu si les métadonnées/petits blocs y sont.

Décision : Si special fait le travail et que la latence est bonne, vous gagnez. Si special est saturé et lent, vous avez déplacé le goulot sur les SSD.

Task 6: Check special vdev health and error counters

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 07:21:10 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
        ...
        special
          mirror-1    ONLINE       0     0     0
            nvme0n1p1 ONLINE       0     0     0
            nvme1n1p1 ONLINE       0     0     0

errors: No known data errors

Signification : Propre. Si vous voyez des erreurs sur special, traitez cela comme un incident de fiabilité urgent, pas comme un « problème de performance ».

Décision : Remplacez immédiatement les périphériques special défaillants. Un mirror special dégradé est un compte à rebours pour une indisponibilité du pool.

Task 7: Identify whether metadata is overwhelming the main vdevs anyway (queueing)

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

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              35.0  22.0  1100.0  680.0  28.5   3.2   98.0
sdb              34.0  23.0  1050.0  690.0  27.8   3.1   97.5
nvme0n1          290.0  18.0  6200.0  260.0   1.1   0.3   22.0
nvme1n1          295.0  17.0  6300.0  260.0   1.0   0.3   21.0

Signification : Les HDD sont proches de 100 % d’utilisation avec un await élevé, tandis que les NVMe ont de la marge. Soit les métadonnées touchent encore les HDD,
soit votre charge est orientée données.

Décision : Si special existe, vérifiez special_small_blocks et confirmez le placement des métadonnées. Sinon, planifiez un special ou réduisez le churn des métadonnées.

Task 8: Verify ashift and sector alignment on special devices

cr0x@server:~$ sudo zdb -C tank | sed -n '1,80p'
MOS Configuration:
        version: 5000
        name: 'tank'
        vdev_children: 2
        vdev_tree:
            type: 'root'
            id: 0
            guid: 1234567890
            children[0]:
                type: 'raidz'
                ashift: 12
                ...
            children[1]:
                type: 'mirror'
                ashift: 12
                is_special: 1
                ...

Signification : ashift: 12 (secteurs 4K) sur special. Bien. Un ashift incorrect peut gaspiller de l’espace et nuire aux performances.

Décision : Si ashift est incorrect, vous ne pouvez pas « régler » le problème facilement. Planifiez une migration ou une reconstruction pour corriger cela.

Task 9: Check how full the special vdev is (and act before it hurts)

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag tank
NAME  SIZE   ALLOC  FREE   CAP  FRAG
tank  109T   72.4T  36.6T  66%  18%

Signification : Ceci est au niveau du pool. Cela n’affiche pas la saturation du special par lui-même ; utilisez zpool list -v comme dans la Tâche 2.

Décision : Si la classe special approche ~70–80 % d’utilisation, planifiez une expansion tôt. N’attendez pas d’atteindre « plein » car c’est là que vos options deviennent mauvaises.

Task 10: See what datasets are heavy on metadata (snapshot count as a clue)

cr0x@server:~$ sudo zfs list -t snapshot -o name -S creation tank/projects | head
NAME
tank/projects@auto-2025-12-26-0000
tank/projects@auto-2025-12-25-0000
tank/projects@auto-2025-12-24-0000
tank/projects@auto-2025-12-23-0000
tank/projects@auto-2025-12-22-0000
tank/projects@auto-2025-12-21-0000
tank/projects@auto-2025-12-20-0000
tank/projects@auto-2025-12-19-0000
tank/projects@auto-2025-12-18-0000

Signification : Le volume de snapshots est un multiplicateur de métadonnées. Plus de snapshots signifie souvent plus de coût de traversée des métadonnées.

Décision : Si les tempêtes de métadonnées coïncident avec le churn de snapshots, ajustez la rétention, la planification, ou déplacez la pression métadonnée de ce dataset sur special.

Task 11: Check scrub/resilver impact on special vdev

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:44 2025
        9.21T scanned at 1.05G/s, 1.90T issued at 222M/s, 72.4T total
        0B repaired, 2.62% done, 3 days 17:12:00 to go

Signification : Le scrub parcourt intensivement les métadonnées. Si votre special est la maison des métadonnées, le comportement et la latence du scrub peuvent changer (souvent en mieux).

Décision : Si le scrub écrase la latence de production, planifiez-le en heures creuses, bridez-le (selon la plateforme), et assurez-vous que les mirrors special ne sont pas sous-dimensionnés.

Task 12: Confirm that your “fast tier” isn’t being used as a write-amplifier

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units|media|error'
Percentage Used:                    7%
Data Units Written:                 18,442,119
Data Units Read:                    21,104,553
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Signification : L’usure est mesurable. Le churn de métadonnées plus les petits blocs de données peuvent user des SSD grandement.

Décision : Si « Percentage Used » augmente rapidement, changez la classe de SSD, réduisez le churn des métadonnées, ou arrêtez de pousser des petits blocs vers special.

Task 13: Validate what’s actually on special (high-level inference via allocation)

cr0x@server:~$ sudo zfs get -r -o name,property,value special_small_blocks tank | head -n 12
NAME                 PROPERTY              VALUE
tank                 special_small_blocks  0
tank/projects        special_small_blocks  32K
tank/vm              special_small_blocks  0
tank/backups         special_small_blocks  0
tank/containers      special_small_blocks  16K

Signification : Seuls certains datasets poussent les petits blocs vers special. C’est sain : usage ciblé plutôt que pari global du pool.

Décision : Gardez-le ciblé. Si tout est réglé sur 128K « pour la performance », vous êtes sur le point de construire un vdev spécial très coûteux.

Task 14: Spot metadata-driven application behavior (syscall-level hint)

cr0x@server:~$ sudo strace -f -tt -p $(pgrep -n rsync) -e trace=newfstatat,getdents64,openat -c
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.41    0.723601          12     59041       112 newfstatat
 31.22    0.386926          14     26874           getdents64
 10.37    0.128504          10     12245        45 openat
------ ----------- ----------- --------- --------- ----------------
100.00    1.238?                   98160       157 total

Signification : L’application passe la plupart du temps sur des appels stat et énumérations de répertoires. Ce sont des métadonnées. Votre goulot est probablement l’I/O de métadonnées et la latence.

Décision : Priorisez le vdev spécial et le tuning des métadonnées plutôt que « plus de disques » ou « recordsize plus grand ». La charge ne demande pas de bande passante.

Cahier de diagnostic rapide

Quand quelqu’un dit « le stockage est lent », vous n’avez pas le temps pour des danses interprétatives. Vous avez besoin d’un chemin de triage rapide qui restreint le goulot à : ARC, vdev special, vdevs principaux, CPU, ou l’application qui fait quelque chose d’inopportun.

Première étape : déterminer si c’est dominé par les métadonnées

• Vérifiez les motifs d’appels système (échantillonnage strace) et la description de la charge : beaucoup de stat(), readdir(), listes de snapshots, scans.
• Vérifiez les misses ARC (Tâche 4). Les taux de misses de métadonnées sont le signal.
• Vérifiez débit vs latence : faible MB/s avec des IOPS élevés est généralement métadonnées ou petites lectures aléatoires.

Deuxième étape : identifier quelle classe de vdev sert les lectures

• Utilisez zpool iostat -v (Tâche 5) pendant la lenteur.
• Si les lectures frappent special, confirmez la latence et la santé des SSD.
• Si les lectures frappent les HDD, soit les métadonnées ne sont pas sur special (ou les blocs préexistent), soit la charge est orientée données.

Troisième étape : décider si vous êtes limité par la pression de capacité, le queueing, ou la configuration

• Vérifiez l’allocation et la capacité de special (Tâche 2). Un special trop plein est un précipice de performance.
• Vérifiez le queueing des périphériques (iostat -x, Tâche 7). Un await élevé sur SSD suggère saturation ou contention.
• Vérifiez les réglages des datasets (special_small_blocks, recordsize, compression) (Tâche 3).
• Vérifiez si un scrub/resilver est en cours (Tâche 11).

Le résultat de ce playbook devrait être une seule phrase que vous pouvez coller sur Slack sans vous faire écharper :
« Nous sommes limités par des misses de métadonnées et les lectures frappent les HDD ; special ne porte pas les métadonnées pour ce dataset »
ou
« Special est saturé et à 85% d’utilisation ; il faut l’agrandir et arrêter d’y pousser des blocs 32K pour ce job de sauvegarde. »

Erreurs courantes (symptômes → cause racine → correction)

1) « Nous avons ajouté special et rien n’a accéléré. »

Symptômes : La traversée des répertoires est toujours lente ; les HDD montrent encore une pression de lecture aléatoire ; special montre peu d’activité de lecture.

Cause racine : Les blocs de métadonnées/données existants n’ont pas été déplacés. Special affecte de nouvelles allocations ; les anciens blocs restent là où ils ont été écrits.

Correction : Pour les datasets où cela compte, réécrivez les données (par ex. send/receive vers un nouveau dataset, ou copy-then-swap) pour que les métadonnées/petits blocs soient réalloués sur special.

2) « Special est plein et maintenant tout semble hanté. »

Symptômes : Pics de latence, bizarreries d’allocation, performance imprévisible ; alertes de capacité.

Cause racine : Vdev special sous-dimensionné, souvent combiné à des réglages agressifs de special_small_blocks.

Correction : Ajoutez des mirrors au special (étendez la classe d’allocation) ou migrez les données vers un pool plus grand. Réduisez special_small_blocks sur les datasets qui n’en ont pas besoin.

3) « Nous avons utilisé un unique SSD ‘enterprise’ pour special. Il a échoué. Maintenant on apprend les procédures de restauration. »

Symptômes : Pool faulté ou n’importe pas l’import ; device special manquant ; panique.

Cause racine : Aucune redondance pour une classe de vdev qui stocke des blocs requis.

Correction : Mirrorisez toujours special. Si c’est déjà cassé, restaurez depuis les backups ou tentez une récupération professionnelle — n’attendez pas de miracles.

4) « Nous avons réglé special_small_blocks trop haut et construit accidentellement un pool tout SSD coûteux. »

Symptômes : L’allocation special grimpe rapidement ; l’usure SSD augmente ; les HDD sont étrangement inactifs ; les réunions budgétaires deviennent tendues.

Cause racine : Seuil proche du recordsize (ou la charge écrit beaucoup de petits blocs), si bien que la plupart des données atterrissent sur special.

Correction : Réduisez le seuil par dataset, et migrez/réécrivez si vous devez déplacer les données existantes hors de special. Surveillez la saturation special et l’endurance SSD.

5) « La performance s’est améliorée, puis s’est effondrée pendant un scrub. »

Symptômes : Pics de latence et d’attente I/O pendant le scrub ; timeouts applicatifs ; special montre une forte activité de lecture.

Cause racine : Le scrub est intensif en métadonnées ; special est maintenant le chemin chaud et peut être sous-dimensionné, ou le scrub chevauche une période de pic.

Correction : Planifiez les scrubs hors-pic, bridez le scrub quand possible, et assurez-vous que les mirrors special ont assez d’IOPS et d’endurance.

6) « Nous pensions que special remplace SLOG. »

Symptômes : Performance d’écriture synchrone NFS/VM toujours mauvaise ; charges fsync-intensives inchangées.

Cause racine : Le vdev special cible les métadonnées/petits blocs. Le SLOG (journal séparé) accélère les écritures synchrones en hébergeant le ZIL.

Correction : Ajoutez un SLOG approprié (mirrored pour les charges sérieuses) et vérifiez le comportement sync. Gardez les rôles séparés.

Trois mini-histoires d’entreprise issues du terrain

Incident causé par une mauvaise hypothèse : « C’est un cache, non ? »

Une entreprise de taille moyenne exploitait un pool ZFS pour des home directories et des artefacts CI. Ils avaient entendu dire que « le vdev spécial accélère les métadonnées »
et ont acheté un unique NVMe haut de gamme. Il a été ajouté comme special. La performance s’est améliorée immédiatement : les listes de répertoires ne timeout plus,
les scans CI étaient plus rapides, tout le monde s’est félicité.

Des mois plus tard, le NVMe a commencé à renvoyer des erreurs média. Le système a continué de fonctionner parce que le périphérique ne mourait pas d’un coup ; il est devenu
simplement instable. Des erreurs de checksum occasionnelles sont apparues, puis ont augmenté. Quelqu’un a traité cela comme une « corruption de cache » et a planifié un remplacement
« à la prochaine fenêtre de maintenance ».

La fenêtre de remplacement est arrivée après que le périphérique soit complètement tombé. Le pool ne s’importait plus proprement. Le « accélérateur de métadonnées » hébergeait des métadonnées requises.
Leurs vdevs de données allaient bien ; ils ne pouvaient juste pas traverser les structures du système de fichiers sans les blocs manquants.

La récupération a été aussi agréable que vous l’imaginez : restauration depuis les backups, réhydratation des artefacts CI, reconstruction des machines développeurs, réponses embarrassées
sur pourquoi un unique SSD était un point unique de défaillance. L’action post-mortem n’a pas été « faites attention », mais « mirrorisez special ou ne l’utilisez pas ».

Optimisation qui s’est retournée contre eux : le réglage « turbo » special_small_blocks

Une autre organisation gérait une charge mixte : dépôts sources, registres de conteneurs, et images VM. Ils ont déployé un vdev spécial en miroir et ont obtenu une solide amélioration pour les tâches riches en métadonnées.
Puis quelqu’un a voulu « finir le travail » et a poussé special_small_blocks=128K sur quelques datasets parce que « la plupart des I/O sont petites de toute façon ».

Au début ça a semblé génial. Les graphiques de latence se sont améliorés. L’équipe a déclaré victoire et est passée à autre chose.
Le problème est arrivé lentement : l’allocation special a monté plus vite que prévu, et les indicateurs d’usure des SSD ont grimpé d’une façon qui ne correspondait pas à leur modèle mental.

Le retour de bâton a été subtil : les datasets avaient recordsize=128K et une charge qui réécrivait fréquemment les fichiers.
Ils avaient effectivement créé une couche SSD qui hébergeait non seulement les métadonnées, mais une grande fraction des blocs de données aussi. Le vdev special est devenu la nouvelle contrainte de capacité.
Puis il est devenu le nouveau goulot de performance, car il gérait à la fois les métadonnées et une pile d’I/O de données.

La correction a été douloureuse mais propre : ils ont abaissé special_small_blocks à 16K pour les datasets qui en bénéficiaient, l’ont remis à 0 pour les autres,
et ont migré les datasets affectés via send/receive pour réallouer les blocs correctement. Ça a pris du temps, mais cela a remplacé une catastrophe rampante par un système stable.

Pratique ennuyeuse mais correcte qui a sauvé la mise : budgets de capacité et d’usure

Une société de services financiers utilisait ZFS pour des logs analytiques et des archives de conformité. Ils ont été conservateurs : vdev special en miroir, special_small_blocks conservateur seulement
sur quelques datasets de « petits fichiers », scrubs hebdomadaires, et une règle de monitoring stricte : alerter à 60 % et 70 % d’utilisation sur special, plus seuils d’usure SSD.

Un trimestre, une nouvelle release applicative a augmenté dramatiquement le nombre de fichiers. Rien d’évident : pas d’augmentation massive d’octets totaux, juste une inondation de petits objets et de snapshots.
Le pool principal avait encore beaucoup d’espace libre. Mais l’allocation special a augmenté semaine après semaine.

Parce qu’ils surveillaient special séparément, ils l’ont détecté tôt. Ils ont ajouté une autre paire mirror special pendant une fenêtre de changement normale et ont ajusté la rétention d’un calendrier de snapshot.
Pas de panne, pas de drame, pas de « pourquoi le pool est offline ».

La partie la plus impressionnante est que personne n’a écrit un fil Slack héroïque à ce sujet. C’est le but. Les opérations doivent être ennuyeuses.
Voilà comment on achète de l’ennui : budgets, seuils, et la volonté de ne pas traiter le stockage critique comme une expérimentation.

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

Étape par étape : décider si vous avez besoin d’un vdev spécial

1. Caractérisez la charge : est-elle dominée par l’énumération de fichiers, les stat, les snapshots, les très petits fichiers, ou les recherches dedup ?
2. Mesurez le comportement de l’ARC : les misses de métadonnées sont-ils significatifs pendant la lenteur ?
3. Mesurez le queueing des périphériques : les HDD sont-ils saturés avec une latence de lecture aléatoire pendant que le débit est faible ?
4. Confirmez que vous ne chassez pas le mauvais goulot : CPU-bound sur la compression, écritures sync, ou comportement applicatif mono-thread.
5. Décidez de la portée : accélération des métadonnées au niveau du pool vs accélération ciblée des petits blocs par dataset.

Étape par étape : implémenter le vdev spécial en sécurité

1. Choisissez les périphériques : SSD/NVMe en miroir avec une endurance adaptée au churn des métadonnées.
2. Planifiez la redondance : mirror minimum ; considérez une politique de hot spare selon votre contexte opérationnel.
3. Ajoutez le vdev special : validez avec zpool status et zpool list -v.
4. Gardez special_small_blocks à 0 initialement : obtenez d’abord le gain « métadonnées seulement ».
5. Mesurez à nouveau : vérifiez que les lectures se déplacent et que la latence s’améliore.
6. Activez special_small_blocks sélectivement : commencez petit (16K/32K), uniquement sur les datasets avec douleur due aux petits fichiers.
7. Documentez : propriétés des datasets et justification dans votre journal de changements.

Étape par étape : éviter les précipices de capacité

1. Surveillez l’allocation special en utilisant zpool list -v.
2. Alertez tôt : traitez 70 % comme « planifier l’expansion », pas « paniquer ».
3. Surveillez l’usure SSD : métriques SMART d’usure et journaux d’erreur.
4. Soyez honnête sur les snapshots : la croissance des snapshots est une croissance des métadonnées ; définissez une rétention que vous pouvez vous permettre.
5. Ayez un plan de migration : si vous devez changer le placement de façon significative, planifiez send/receive ou une réécriture contrôlée.

FAQ

1) Un vdev spécial est-il la même chose que L2ARC ?

Non. L2ARC est un cache de lecture et peut être perdu sans perte du pool. Le vdev spécial stocke de vrais blocs (métadonnées et éventuellement petites données).
Le perdre peut entraîner la perte du pool.

2) Ajouter un vdev spécial déplace-t-il automatiquement les métadonnées existantes ?

Généralement non. Il affecte les nouvelles allocations. Les blocs existants restent là à moins que vous ne réécriviez/migrez les données pour que ZFS alloue à nouveau.

3) Puis-je utiliser un seul SSD pour special s’il est « enterprise grade » ?

Vous pouvez. Vous pouvez aussi exploiter en production sans backups. Dans les deux cas, vous choisissez le drame. Mirrorisez le vdev spécial.

4) Quelle est une valeur de départ sûre pour special_small_blocks ?

Commencez à 0 (métadonnées seulement). Si vous avez une charge éprouvée de petits fichiers, essayez 16K ou 32K sur ce dataset, puis surveillez l’allocation special et l’usure des SSD.

5) En quoi SLOG est-il différent du vdev spécial ?

SLOG accélère les écritures synchrones en hébergeant le journal ZIL. Le vdev spécial accélère les lectures/écritures de métadonnées et éventuellement les petits blocs.
Ils résolvent des problèmes différents et sont souvent utilisés ensemble dans des environnements sérieux.

6) Le vdev spécial rendra-t-il les scrubs plus rapides ?

Souvent, il améliore le comportement des scrubs car ceux-ci lisent beaucoup de métadonnées. Mais si votre special est sous-dimensionné ou saturé, le scrub peut
entrer en compétition avec les lectures de production sur les mêmes SSD.

7) Le vdev spécial peut-il aider avec la dedup ?

Il peut aider car les recherches DDT sont de nature métadonnée et sensibles à la latence. Mais dedup est toujours dominé par les besoins en mémoire et le comportement des recherches.
Le vdev spécial ne remplace pas suffisamment de RAM ni une conception dedup correcte.

8) Que se passe-t-il si le vdev spécial se remplit ?

Meilleur cas : la performance se dégrade et les allocations se comportent différemment pendant que ZFS tente de faire face. Pire cas : vous atteignez des échecs d’allocation et un chaos opérationnel.
Traitez la capacité special comme une ressource de première classe avec alertes précoces et plan d’expansion.

9) Ai-je besoin d’un vdev spécial sur un pool tout NVMe ?

Parfois encore utile, mais le gain est plus petit car métadonnées et données ont déjà une faible latence. Il peut aider à isoler les métadonnées des lectures en masse, mais mesurez d’abord — ne faites pas de cargo-cult.

10) Comment savoir si ma lenteur est « métadonnées » ou « données » ?

Cherchez un faible débit avec un nombre élevé d’opérations, des misses ARC de métadonnées élevés, et des profils d’appels système dominés par stat() et les lectures de répertoires.
Puis confirmez quelle classe de vdev sert les lectures via zpool iostat -v.

Conclusion : étapes pratiques suivantes

Le vdev spécial est l’une des rares fonctionnalités ZFS qui peut sembler de la triche : soudainement le système de fichiers cesse de discuter avec la physique pendant les tempêtes de métadonnées.
Mais ce n’est de la triche que si vous ne payez pas le prix d’avance : redondance, dimensionnement, et discipline avec special_small_blocks.

Étapes suivantes qui améliorent fiablement de vrais systèmes :

• Prouvez que c’est des métadonnées avec les données de misses ARC et l’iostat au niveau vdev pendant la fenêtre d’incident.
• Si vous déployez special, mirrorisez-le et surveillez-le comme s’il pouvait mettre votre pool hors service — parce que c’est le cas.
• Commencez métadonnées seulement, puis activez sélectivement le placement des petits blocs là où la charge le justifie.
• Budgétez la croissance : snapshots, nombre de fichiers et churn vont augmenter les métadonnées avec le temps.
• Rendez tout ennuyeux : alertes à des seuils sensés, scrubs planifiés, usure suivie, et changements documentés.

Si vous faites cela correctement, vous passerez moins de temps à expliquer pourquoi « ls » est lent et plus de temps à faire le travail qui vous fait promouvoir :
systèmes prévisibles, incidents prévisibles, récupération prévisible.