VDEVs spéciaux ZFS sur SSD SAS : le choix pro pour les métadonnées

Ce que font réellement les vdevs spéciaux (et ce qu’ils ne font pas)

Un « vdev spécial » ZFS est une classe d’allocation qui peut stocker les métadonnées et (optionnellement) les petits blocs de fichiers sur une classe
de périphérique plus rapide que vos vdevs de données principaux. Le déploiement courant : gros vdevs HDD bon marché et résilients pour les données en masse ; SSD en miroir dans la classe spéciale
pour les métadonnées et les E/S petites. L’impact est immédiat sur les charges qui effectuent beaucoup d’activité sur l’espace de noms : parcours de répertoires, snapshots,
scans rsync/sauvegarde, accès aux images VM, couches d’images conteneur, dépôts git, maildirs, et tout ce qui « touche beaucoup de petites choses ».

Que place-t-on sur le vdev spécial ?

• Métadonnées par défaut : entrées de répertoires, métadonnées d’objets, blocs indirects, métadonnées d’allocation.
• Éventuellement petits blocs de données lorsque special_small_blocks est défini sur un dataset.
• Ce n’est pas un cache : ce n’est pas L2ARC. Les données y sont placées de façon permanente (jusqu’à réécriture/déplacement selon le comportement de ZFS).

Ce que ce n’est pas

• Ce n’est pas SLOG (dispositif de log séparé) : SLOG accélère les écritures synchrones. Le vdev spécial accélère les métadonnées et les petits blocs.
• Ce n’est pas L2ARC : L2ARC est un cache de lecture qui peut être supprimé sans perdre le pool. Le vdev spécial fait partie du pool.
• Ce n’est pas optionnel une fois utilisé : le perdre peut entraîner la perte du pool (sauf si c’est redondant et qu’un seul appareil échoue, et même là : considérez-le comme un incendie).

Ce dernier point transforme une fonctionnalité astucieuse en un choix risqué quand elle est mise en œuvre sans précautions.
Si vous ne retenez qu’une chose de cet article : les vdevs spéciaux doivent être redondants, et leur santé doit être surveillée comme une alimentation électrique.

Pourquoi les SSD SAS sont un bon choix pour les vdevs spéciaux

Vous pouvez construire des vdevs spéciaux avec des SSD SATA, NVMe, voire Optane à l’époque où c’était facile à acheter. Mais les SSD SAS trouvent un bon compromis pour
des parcs de serveurs : dual-porting, écosystèmes de firmware cohérents, baies/backplanes appropriés, et moins de comportements « surprise consommateur ».
Ils ne sont pas les plus rapides sur le papier. Ils sont suffisamment rapides là où ça compte : latence faible et constante à queue depth 1–4, sous une charge constante de métadonnées.

Traits importants pour les métadonnées

• Latence prévisible : les charges de métadonnées punissent la latence en queue. Les SSD SAS dans de bons HBA/backplanes sont généralement ennuyeux. L’ennui l’emporte.
• Ergonomie opérationnelle : châssis standardisés, gestion d’enclosure, et moins de moments « quel M.2 est en train de mourir ? ».
• Dual-port (courant sur les SSD SAS entreprise) : chemins plus résilients dans les configurations HA.
• Protection contre coupure de courant (typique) : moins de drames lors d’un « quelqu’un a éteint le mauvais PDU ».
• Réserve d’endurance : les métadonnées peuvent être intensives en écritures de façon inattendue : snapshots, suppressions, datasets avec churn.

En résumé : si votre pool principal est sur HDD, les vdevs spéciaux sont souvent la meilleure amélioration « sensation de rapidité » que vous pouvez faire sans racheter tout un système de stockage.
Et les SSD SAS représentent un compromis judicieux entre « conforme à l’entreprise » et « la finance ne s’évanouit pas ».

Faits intéressants et contexte historique

L’ingénierie du stockage consiste essentiellement à réapprendre d’anciennes leçons dans de nouveaux emballages. Voici quelques points de contexte qui vous aident à raisonner sur les vdevs spéciaux,
et pourquoi ils existent.

1. ZFS a été conçu avec l’intégrité de bout en bout : des checksums pour tout signifie que les métadonnées ne sont pas « légères » ; elles font partie de la justesse.
2. Les anciens systèmes de fichiers traitaient souvent les métadonnées comme de seconde zone ; les métadonnées ZFS sont plus riches, et leurs schémas d’accès se traduisent par de la latence réelle.
3. Les « classes d’allocation » sont arrivées plus tard dans OpenZFS pour résoudre les pools à médias mixtes sans perdre un espace de noms cohérent.
4. Avant les vdevs spéciaux, on utilisait parfois L2ARC comme pansement pour les lectures riches en métadonnées ; ça aidait parfois, mais le placement n’était pas déterministe.
5. Les arrays hybrides existent depuis des décennies : tiering des données chaudes vers la flash n’est pas nouveau ; les vdevs spéciaux sont ZFS qui le fait à la manière ZFS.
6. Le coût du parcours de répertoire a explosé avec les gros jeux de fichiers bien avant que le « big data » soit à la mode ; les spools mail et caches web ont enseigné cette leçon.
7. Le SAS entreprise a traversé plusieurs ères : des disques rotatifs aux SSD, l’outillage opérationnel (enclosures, SES, HBA) est resté mature.
8. L’amplification des métadonnées est réelle : supprimer un million de petits fichiers demande bien plus de travail de métadonnées qu’écrire un gros fichier de taille équivalente.

Comment les métadonnées vous pénalisent vraiment : un modèle mental pratique

Sur des pools HDD, vous pouvez avoir beaucoup de MB/s et pourtant ressentir de la lenteur parce que les métadonnées sont des I/O aléatoires. Un listing de répertoire sur un grand arbre est une tempête de petites lectures :
dnodes, blocs indirects, blocs de répertoire, ACLs, xattrs, et le travail de « où est stocké ce bloc ? » que ZFS doit faire pour rester correct.
Les HDD sont bons en streaming. Ils sont médiocres pour des lectures aléatoires 4–16K avec seek.

Placer les métadonnées sur SSD produit deux effets : (1) votre plafond d’IOPS aléatoires augmente de plusieurs ordres de grandeur ; (2) votre latence en queue diminue, ce qui fait que tout
au-dessus du stockage — applications, VMs, bases de données, outils de sauvegarde — arrêtent d’attendre en file.

Métadonnées vs petits données : décider quoi placer

Le comportement par défaut (« métadonnées seulement ») change déjà l’expérience utilisateur. Mais de nombreuses charges réelles sont dominées par de petits fichiers :
dépôts de config, couches d’images conteneur, fragments de logs, e‑mails, artefacts CI, registries de paquets.
C’est là que special_small_blocks fait ses preuves : il pousse les petits blocs de fichiers vers le vdev spécial aussi.

Il n’y a pas de déjeuner gratuit. Si vous envoyez des petits blocs vers les vdevs spéciaux, vous envoyez aussi plus d’écritures vers ces SSD. C’est acceptable si vous les avez dimensionnés,
mis en miroir, et que vous surveillez l’endurance. C’est une catastrophe si vous les avez dimensionnés comme des disques cache et que vous les chargez de millions d’écritures 32K/s.

Une vérité opérationnelle : les utilisateurs n’ouvrent pas de ticket en disant « latence des métadonnées élevée ». Ils disent « l’application est lente ». Votre travail est de savoir quand « l’application est lente »
signifie « vos disques rouillés cherchent des dnodes à nouveau ».

Décisions d’architecture importantes en production

1) La redondance est obligatoire

Traitez les vdevs spéciaux comme l’épine dorsale du pool. Si le vdev spécial est perdu et qu’il contient des métadonnées, le pool n’est pas « dégradé ». Il est perdu.
Le choix sensé par défaut est un miroir (ou plusieurs vdevs spéciaux en miroir). RAIDZ pour le spécial est possible mais souvent maladroit ; les miroirs gardent le comportement de rebuild
et la latence prévisible.

2) Dimensionnez-le pour le long terme, pas pour la démo

Les métadonnées croissent avec le nombre de fichiers, le nombre de snapshots, et les schémas de fragmentation. Si vous définissez special_small_blocks, la croissance est plus rapide.
Sous-dimensionner mène à une falaise désagréable : une fois le vdev spécial plein, ZFS doit placer les nouvelles métadonnées (et petits blocs, si configuré) sur les vdevs principaux plus lents.
C’est là que votre « pool rapide » devient « pool mystérieusement incohérent ». Les utilisateurs adorent l’incohérence presque autant que les fenêtres de maintenance surprises.

3) Pensez domaines de défaillance : HBA, expander, enclosure

Mettre en miroir deux SSD dans le même backplane sur le même expander sur le même HBA n’est pas de la redondance ; c’est de l’optimisme avec des étapes supplémentaires.
Placez les pattes du miroir sur des HBA/enclosures différents quand c’est possible. Si vous ne pouvez pas, au moins utilisez des baies différentes et validez le chemin d’accès à l’enclosure.

4) Utilisez des SSD SAS que vous pouvez réellement remplacer

« On a trouvé deux SSD entreprise au hasard dans un tiroir » n’est pas un plan de cycle de vie. Vous voulez des modèles cohérents, un firmware cohérent, et la capacité d’acheter des remplaçants sans
jouer à la roulette d’eBay.

5) Décidez délibérément du déchargement de petits blocs

Si votre charge est principalement composée de gros fichiers (médias, sauvegardes, disques VM avec gros blocs), le vdev spécial pour métadonnées seulement suffit souvent.
Si vous avez beaucoup de petits fichiers ou des lectures aléatoires sur petits blocs, activez special_small_blocks—mais définissez-le au niveau dataset,
et mesurez.

6) La compression change le seuil effectif de « petit bloc »

Si vous utilisez la compression (ce que vous devriez généralement), un record logique de 128K peut devenir un bloc physique de 32K. Les décisions de ZFS peuvent être basées sur la taille physique.
Cela peut augmenter la quantité envoyée sur les vdevs spéciaux lorsque special_small_blocks est actif. C’est merveilleux jusqu’à ce que votre vdev spécial manque d’espace
et que vous découvriez la falaise.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : tout échoue ; concevez et opérez en supposant que ça arrivera. Les vdevs spéciaux sont exactement cela : un choix de conception qui demande une maturité opérationnelle.

Implémentation : création et réglages des vdevs spéciaux

Choisir la topologie

Le mouvement standard : ajouter un vdev spécial en miroir à un pool existant, en utilisant deux SSD SAS. Si vous créez un nouveau pool, vous pouvez
l’inclure dès la création, mais l’ajout ultérieur est courant et sûr si vous le faites correctement.

Décider de la politique special_small_blocks

Le définir sur l’ensemble du pool est un instrument grossier. Préférez des réglages au niveau dataset. Placez les datasets riches en petits fichiers dessus, gardez les gros séquentiels en dehors.
C’est ainsi que vous évitez de transformer vos SSD de métadonnées en « stockage principal accidentel ».

Blague #1 : Si vous définissez special_small_blocks=128K partout, félicitations — vous avez construit un pool SSD avec la latence HDD et la facture SSD.

Planifiez la surveillance avant de basculer

Surveillez : capacité du vdev spécial, latence lecture/écriture, compte d’erreurs, et endurance SMART. Surveillez aussi les symptômes au niveau du pool : pics de latence dans zpool iostat,
et la latence 99e percentile côté application. Vous devez savoir que vous approchez d’une falaise des semaines avant d’en tomber.

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

Les commandes ci‑dessous supposent un hôte Linux avec OpenZFS et un pool nommé tank. Ajustez les noms à votre environnement.
Chaque tâche inclut : ce que vous lancez, ce que la sortie suggère, et quelle décision prendre ensuite.

Task 1: Confirm your pool layout and whether a special vdev already exists

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
            scsi-35000c500a1b2c3d4  ONLINE       0     0     0
            scsi-35000c500a1b2c3e5  ONLINE       0     0     0
            scsi-35000c500a1b2c3f6  ONLINE       0     0     0
            scsi-35000c500a1b2c4a7  ONLINE       0     0     0
            scsi-35000c500a1b2c4b8  ONLINE       0     0     0
            scsi-35000c500a1b2c4c9  ONLINE       0     0     0

errors: No known data errors

Signification : Aucun type special listé. Ce pool est composé uniquement de vdevs principaux (RAIDZ2 sur HDD SAS).

Décision : Si votre charge est gourmande en métadonnées et sensible à la latence, vous êtes un bon candidat pour un vdev spécial en miroir.

Task 2: Check dataset properties that affect metadata/small block placement

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

Signification : Aucun petit bloc n’est déchargé vers les vdevs spéciaux (même si vous les ajoutez) car special_small_blocks=0.

Décision : Planifiez de définir special_small_blocks par dataset plus tard si vous voulez accélérer les petits fichiers.

Task 3: Identify candidate SAS SSDs by stable IDs

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'sas|scsi-3' | head
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500d0e1a2b3 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500d0e1a2b4 -> ../../sdd
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500a1b2c3d4 -> ../../sde
lrwxrwxrwx 1 root root  9 Dec 26 10:02 scsi-35000c500a1b2c3e5 -> ../../sdf

Signification : Vous avez des identifiants stables. Utilisez-les, pas /dev/sdX, lors de l’ajout de vdevs.

Décision : Choisissez deux ID de SSD pour un miroir ; vérifiez qu’ils ne sont pas déjà utilisés et qu’ils ont la bonne capacité/modèle.

Task 4: Confirm the SSDs are actually SSDs and check key SMART health signals

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i 'Device Model|Serial|User Capacity|Rotation|Percentage|Wear|Media_Wearout|Power_On_Hours|Reallocated'
Device Model:     SEAGATE XS800LE10003
Serial Number:    ABCD1234
User Capacity:    800,166,076,416 bytes [800 GB]
Rotation Rate:    Solid State Device
Power_On_Hours:   18432
Percentage Used:  6%
Reallocated_Sector_Ct: 0

Signification : Faible usure (Percentage Used: 6%), aucune réallocation. Convient pour un rôle de vdev spécial.

Décision : Continuez si les deux SSD affichent une santé propre. Si l’usure est élevée, n’utilisez pas ce qu’il reste—achetez des disques appropriés.

Task 5: Verify ashift and general pool properties before extending

cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|name:'
    name: 'tank'
        ashift: 12

Signification : ashift=12 (secteurs 4K) est le choix sensé pour les disques/SSD modernes.

Décision : Pas d’action nécessaire ; continuez. Si vous voyez ashift=9 en 2025, vous avez des problèmes plus graves.

Task 6: Add a mirrored special vdev (the actual pro move)

cr0x@server:~$ sudo zpool add tank special mirror scsi-35000c500d0e1a2b3 scsi-35000c500d0e1a2b4

Signification : Vous avez ajouté une classe d’allocation spéciale en miroir au pool.

Décision : Confirmez immédiatement la configuration et commencez à surveiller l’usage du vdev spécial. Documentez aussi le changement comme un adulte.

Task 7: Confirm the special vdev shows up and is ONLINE

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

        NAME                          STATE     READ WRITE CKSUM
        tank                          ONLINE       0     0     0
          raidz2-0                    ONLINE       0     0     0
            scsi-35000c500a1b2c3d4    ONLINE       0     0     0
            scsi-35000c500a1b2c3e5    ONLINE       0     0     0
            scsi-35000c500a1b2c3f6    ONLINE       0     0     0
            scsi-35000c500a1b2c4a7    ONLINE       0     0     0
            scsi-35000c500a1b2c4b8    ONLINE       0     0     0
            scsi-35000c500a1b2c4c9    ONLINE       0     0     0
        special
          mirror-1                    ONLINE       0     0     0
            scsi-35000c500d0e1a2b3    ONLINE       0     0     0
            scsi-35000c500d0e1a2b4    ONLINE       0     0     0

errors: No known data errors

Signification : Le pool possède maintenant une classe special avec un miroir. C’est à quoi ressemble une configuration « correcte ».

Décision : Passez au réglage des datasets et à la validation. Si ce n’est pas ONLINE, arrêtez et corrigez d’abord le matériel/le chemin.

Task 8: Measure I/O and latency by vdev class under real workload

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  45.8T    240    310  12.5M  18.2M
  raidz2-0  12.3T  45.8T    120    180  10.1M  16.9M
  special    4.2G   743G    120    130   2.4M   1.3M
    mirror-1 4.2G   743G    120    130   2.4M   1.3M

Signification : Le vdev spécial sert activement des opérations. Même quelques MB/s peuvent représenter une accélération massive des métadonnées.

Décision : Si les opérations frappent encore les vdevs HDD pendant les tâches riches en métadonnées, envisagez d’activer le déchargement des petits blocs sur des datasets ciblés.

Task 9: Check special vdev space usage and keep it away from the cliff

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  12.3T  45.8T   128K  /tank

cr0x@server:~$ sudo zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       58.1T  12.3T  45.8T        -         -    12%    21%  1.00x  ONLINE  -
  raidz2-0  58.1T  12.3T  45.8T        -         -    12%    21%
  special    745G  4.20G   741G        -         -     1%     0%

Signification : Le vdev spécial a encore beaucoup de marge. Le chiffre clé est le CAP de la classe special ; ne le laissez pas approcher du plein.

Décision : Établissez des seuils d’alerte (par exemple : avertir à 60 %, pager à 75 %). Projetez la croissance en fonction du nombre de fichiers et des snapshots.

Task 10: Enable small block offload for a specific dataset (surgical, not global)

cr0x@server:~$ sudo zfs create tank/containers
cr0x@server:~$ sudo zfs set compression=zstd tank/containers
cr0x@server:~$ sudo zfs set special_small_blocks=32K tank/containers
cr0x@server:~$ sudo zfs get -o name,property,value special_small_blocks tank/containers
NAME            PROPERTY             VALUE
tank/containers special_small_blocks 32K

Signification : Les blocs de taille ≤32K (souvent taille physique) peuvent être alloués sur le vdev spécial pour ce dataset.

Décision : Commencez prudemment (16K–32K) sauf si vous avez modélisé la capacité/l’endurance. Puis mesurez. Étendez le périmètre seulement si le bénéfice est réel.

Task 11: Validate that metadata is actually being served fast (look at latency)

cr0x@server:~$ sudo zpool iostat -vl tank 1 2
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
tank                        12.3T  45.8T    260    340  13.1M  19.4M   8ms   11ms    3ms    5ms
  raidz2-0                  12.3T  45.8T    120    210  10.2M  18.0M  14ms   22ms    9ms   14ms
  special                    4.5G   741G    140    130   2.9M   1.4M   1ms    2ms    1ms    1ms
    mirror-1                 4.5G   741G    140    130   2.9M   1.4M   1ms    2ms    1ms    1ms

Signification : disk_wait du vdev spécial est ~1ms tandis que le vdev HDD est dans les dizaines de ms. C’est tout l’intérêt.

Décision : Si l’attente du spécial est élevée, vous pouvez saturer les SSD, la queue du HBA, ou rencontrer un problème de firmware/chemin. Enquêtez avant de toucher aux paramètres ZFS à l’aveugle.

Task 12: Observe ARC behavior (because metadata loves memory too)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
10:20:01   520    60     11    20   33    18   30    22   37   42G   64G
10:20:02   610    80     13    25   31    25   31    30   38   42G   64G
10:20:03   590    70     11    20   29    22   31    28   40   42G   64G

Signification : ARC fait son travail. Un taux de miss modeste est normal ; le vdev spécial réduit la pénalité des misses sur les métadonnées.

Décision : Si le miss% de l’ARC est élevé en état stable, envisagez d’augmenter la mémoire ou regardez le working set. N’attendez pas des SSD qu’ils règlent un manque de RAM.

Task 13: Watch special vdev errors like it’s a payroll system

cr0x@server:~$ sudo zpool status -xv
pool 'tank' is healthy

Signification : Pas de problèmes connus pour l’instant.

Décision : Si vous voyez des erreurs de lecture/écriture/checksum sur le spécial, escaladez plus vite que pour un HDD unique en RAIDZ. Les erreurs de métadonnées ne sont pas « à traiter lors du prochain sprint ».

Task 14: Replace a failed special vdev device correctly (simulate the workflow)

cr0x@server:~$ sudo zpool offline tank scsi-35000c500d0e1a2b3
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                          STATE     READ WRITE CKSUM
        tank                          DEGRADED     0     0     0
          raidz2-0                    ONLINE       0     0     0
            scsi-35000c500a1b2c3d4    ONLINE       0     0     0
            scsi-35000c500a1b2c3e5    ONLINE       0     0     0
            scsi-35000c500a1b2c3f6    ONLINE       0     0     0
            scsi-35000c500a1b2c4a7    ONLINE       0     0     0
            scsi-35000c500a1b2c4b8    ONLINE       0     0     0
            scsi-35000c500a1b2c4c9    ONLINE       0     0     0
        special
          mirror-1                    DEGRADED     0     0     0
            scsi-35000c500d0e1a2b3    OFFLINE      0     0     0
            scsi-35000c500d0e1a2b4    ONLINE       0     0     0

errors: No known data errors

Signification : Le pool est dégradé car le miroir spécial a perdu une patte. Vous avez encore le pool, mais vous êtes sans filet de sécurité.

Décision : Remplacez immédiatement. N’attendez pas le jour de maintenance. La prochaine défaillance pourrait être catastrophique.

cr0x@server:~$ sudo zpool replace tank scsi-35000c500d0e1a2b3 scsi-35000c500deadbeef
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
scan: resilver in progress since Fri Dec 26 10:22:14 2025
        2.10G scanned at 420M/s, 1.05G issued at 210M/s, 4.20G total
        1.05G resilvered, 25.0% done, 0:00:15 to go

Signification : Le resilver est en cours. Note : les resilvers des vdevs spéciaux sont généralement rapides car l’empreinte est plus petite que les données en masse.

Décision : Maintenez une charge raisonnable, surveillez les erreurs, et confirmez le retour en ONLINE. Si le resilver bloque, suspectez un problème de chemin/disque.

Task 15: Confirm TRIM behavior (helps SSD steady-state)

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

Signification : Autotrim est activé. Bon pour la longévité et la performance des SSD dans de nombreux environnements.

Décision : Si c’est désactivé, envisagez de l’activer. Si vous êtes sur de vieux kernels/SSDs où trim provoque des pics de latence, testez avant de l’activer globalement.

Task 16: Measure “user pain” directly: directory traversal timing before/after

cr0x@server:~$ time find /tank/containers -maxdepth 4 -type f -printf '.' > /dev/null

real    0m7.912s
user    0m0.332s
sys     0m1.821s

Signification : C’est un test brut mais efficace pour savoir si ça « se sent » plus rapide sur des arbres riches en métadonnées.

Décision : Si c’est encore lent, vérifiez si le dataset utilise special_small_blocks, si les métadonnées sont en cache dans ARC, et si la charge est réellement limitée par autre chose (CPU, application mono‑thread, réseau).

Playbook de diagnostic rapide

Quand quelqu’un dit « le stockage est lent », vous avez environ cinq minutes avant que la conversation ne devienne improductive. Utilisez cette séquence pour trouver rapidement le goulot d’étranglement.
Elle est optimisée pour les pools ZFS avec (ou sans) vdevs spéciaux.

Première étape : y a‑t‑il un problème de santé évident ?

• Exécutez zpool status -xv. Si ce n’est pas healthy, arrêtez les travaux de performance et corrigez la fiabilité d’abord.
• Vérifiez si le vdev spécial est dégradé. Si oui, traitez‑le en urgence : vous êtes à une défaillance d’un mauvais jour.

Deuxième étape : la latence vient‑elle du rust, du SSD, ou d’ailleurs ?

• Exécutez zpool iostat -vl pool 1 5 et comparez le disk_wait entre les vdevs principaux et le spécial.
• Si l’attente HDD est élevée et que le spécial est bas : votre charge frappe encore les HDD. Peut‑être blocs larges, ou le spécial est trop petit/plein, ou les petits blocs ne sont pas activés.
• Si l’attente du spécial est élevée : vous avez peut‑être saturé le miroir SSD, ou vous avez un problème de queue HBA/firmware, ou le SSD est presque plein et subit une amplification d’écriture.

Troisième étape : la charge est‑elle dominée par les métadonnées ?

• Indices : listings de répertoire lents, énumération slow de snapshot send/receive, IOPS élevés avec faible MB/s, plaintes d’utilisateurs sur « l’ouverture de dossiers ».
• Exécutez arcstat. Si les misses de l’ARC sont élevés et que vous voyez beaucoup de petites lectures aléatoires, les vdevs spéciaux aident — si vous en avez et qu’ils sont bien dimensionnés.

Quatrième étape : écrivez‑vous accidentellement trop sur le spécial ?

• Vérifiez les réglages special_small_blocks des datasets. Un seuil trop élevé peut pousser beaucoup de données sur le vdev spécial.
• Vérifiez la capacité du vdev spécial. Approcher le plein signifie chaos : falaises de performance et placement imprévisible.

Cinquième étape : validez le « banal »

• Erreurs HBA, resets de lien, problèmes d’enclosure, flaps multipath.
• Saturation CPU (la compression peut être gourmande ; zstd est généralement correct, mais ne devinez pas).
• Goulots réseau (si les clients sont distants, le stockage peut être innocent).

Blague #2 : Si vous sautez l’étape un et que vous réglez la performance sur un vdev spécial dégradé, l’univers programmera votre outage pour le vendredi après‑midi.

Trois micro‑histoires d’entreprise (anonymisées, plausibles et évitables)

1) L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne avait un pool ZFS servant des artefacts CI et des images conteneur. Les builds étaient lents, alors ils ont fait la chose sensée : ajouté deux SSD « pour le cache ».
Quelqu’un avait lu sur les vdevs spéciaux et a ajouté un seul SSD en spécial, en prévoyant « d’ajouter la redondance plus tard ».

Ça a fonctionné pendant des semaines. Puis le SSD a commencé à renvoyer des erreurs moyennes. Le pool est passé de « ONLINE » à « unavailable » rapidement — parce qu’un vdev spécial n’est pas un cache.
Il contenait de vraies métadonnées. La récupération n’a pas été un simple « retirez le cache et redémarrez ». Ce fut une restauration depuis sauvegarde, plus un long post‑mortem.

Le pire n’était pas l’interruption. C’était la confusion. La moitié de l’équipe supposait que ça fonctionnait comme L2ARC ; l’autre moitié supposait que ZFS « garderait une copie ailleurs ».
ZFS a fait exactement ce qu’il promettait : il a utilisé le vdev spécial pour le placement des métadonnées. Ils avaient construit un point de défaillance unique dans le pool.

La correction fut ennuyeuse et correcte : uniquement des vdevs spéciaux en miroir, plus une politique interdisant l’ajout d’appareils de classes d’allocation sans demande de changement
qui décrit explicitement le comportement en cas de perte. Le coût de la reconstruction valait plus que deux SSD.

2) L’optimisation qui a mal tourné

Une grande plateforme d’analytique interne avait un pool RAIDZ2 HDD et un vdev spécial miroir SSD SAS. La performance était bonne.
Puis un ingénieur a remarqué que certains datasets avaient beaucoup de petits fichiers et a décidé de « supercharger » en mettant special_small_blocks=128K
sur un dataset de haut niveau.

Le résultat fut immédiat : la latence de lecture aléatoire s’améliora, mais en quelques semaines la capacité du spécial grimpa plus vite que prévu.
La compression rendit plus de blocs « assez petits », et le placement effectif se déplaça.
Le churn de snapshots amplifia les écritures de métadonnées, et le miroir SSD commença à vivre plus intensément que prévu.

Finalement le vdev spécial approcha d’une forte utilisation. La performance devint étrange : pas toujours lente, mais en pics.
Les utilisateurs rapportèrent des lenteurs intermittentes : certaines requêtes étaient instantanées, d’autres bloquaient.
Les graphes de latence ressemblaient à un sismographe pendant un tremblement de terre mineur.

Ils recularent en restreignant le réglage à des datasets spécifiques et en baissant le seuil à 16K–32K où cela importait réellement.
Ils ajoutèrent aussi un second vdev spécial en miroir pour répartir la charge. La leçon n’était pas « ne pas optimiser ».
La leçon était « optimiser avec un modèle de capacité, pas avec des impressions ».

3) La pratique ennuyeuse mais correcte qui sauva la mise

Un environnement lié à la finance (audits et contrôle de changement strict) utilisait ZFS pour le stockage de documents et les sauvegardes de VM.
Ils ajoutèrent tôt des vdevs spéciaux SSD SAS, en miroir sur deux HBA.
Pas spectaculaire. Mais ils documentèrent la topologie, étiquetèrent les baies, et mirent en place une surveillance de l’utilisation du spécial et de l’usure SMART.

Un matin, un job massif de modification des permissions sur des millions de fichiers démarra. Les écritures de métadonnées explosèrent.
Le vdev spécial absorba le churn avec une faible latence. Les HDD restèrent principalement occupés par les lectures et écritures en masse.
Les utilisateurs ne remarquèrent rien ; le job termina ; tout le monde continua de prétendre que le stockage était simple.

Une semaine plus tard, un SSD commença à signaler des erreurs corrigées croissantes. La surveillance alerta tôt parce qu’ils suivaient les bons compteurs.
Ils remplacèrent le disque pendant les heures ouvrables, resilverèrent rapidement, et rédigèrent une note de changement de deux paragraphes qui contenta les auditeurs.

Pas d’héroïsme. Pas d’appels d’urgence. Juste un système conçu autour de la défaillance et exploité comme si elle allait réellement arriver.
C’est ce que signifie « senior » en stockage.

Erreurs courantes : symptômes → cause racine → correction

1) « Le pool est mort quand un SSD est mort »

Symptôme : Le pool ne s’importe plus après la perte d’un appareil du vdev spécial.

Cause racine : Le vdev spécial n’était pas redondant (disque unique), ou les deux pattes du miroir ont été perdues à cause d’un domaine de défaillance partagé (HBA/enclosure).

Correction : Mirror toujours les vdevs spéciaux. Séparez les pattes du miroir à travers des domaines de défaillance. Traitez le matériel du vdev spécial comme de l’infrastructure tier‑0.

2) « Les listings restent lents après l’ajout du spécial »

Symptôme : find/ls sur de grands arbres reste lent ; le vdev HDD montre des lectures aléatoires élevées.

Cause racine : La charge est dominée par de petits blocs de données, pas seulement par les métadonnées ; ou les métadonnées chaudes sont déjà dans l’ARC et le goulot est ailleurs.

Correction : Activez special_small_blocks sur le dataset pertinent (commencez à 16K ou 32K), puis retestez. Confirmez aussi que vous n’êtes pas limité par CPU/réseau.

3) « Le vdev spécial se remplit plus vite que prévu »

Symptôme : L’utilisation de la classe special croît rapidement ; les alertes se déclenchent ; la performance devient saccadée à forte utilisation.

Cause racine : Seuil trop élevé ; la compression réduit des blocs sous le cutoff ; la charge a beaucoup de churn/snapshots ; le modèle de dimensionnement a ignoré la croissance du nombre de fichiers.

Correction : Réduisez special_small_blocks sur les datasets larges ; limitez‑le aux datasets ciblés. Ajoutez de la capacité supplémentaire en vdevs spéciaux en miroir si nécessaire.

4) « Latence du vdev spécial élevée malgré des SSD »

Symptôme : zpool iostat -vl montre un disk_wait élevé sur le spécial.

Cause racine : SSD saturé (IOPS), comportement near‑full, bizarreries de firmware, queueing HBA, problèmes d’expander, ou instabilité des chemins SAS/SATA mélangés.

Correction : Vérifiez la santé et les erreurs du périphérique, assurez un firmware/driver HBA correct, vérifiez les profondeurs de queue, assurez de la marge sur le spécial, et envisagez d’ajouter un autre vdev spécial en miroir pour répartir la charge.

5) « Après activation des petits blocs, l’usure des SSD augmente »

Symptôme : Les indicateurs SMART d’usure augmentent plus vite que prévu ; l’amplification d’écriture est visible dans les outils du fournisseur.

Cause racine : Le déchargement des petits blocs a transféré beaucoup de trafic d’écriture aux SSD ; la charge inclut des suppressions/réécritures fréquentes ; sur‑provisionnement/endurance insuffisants.

Correction : Abaissez le cutoff, réduisez le périmètre aux datasets essentiels, passez à des SSD SAS plus endurants, et surveillez l’usure avec des alertes liées au planning de remplacement.

6) « On a ajouté des vdevs spéciaux et maintenant scrub prend plus de temps »

Symptôme : Scrubs/reslivers se comportent différemment ; certaines parties finissent vite, d’autres traînent.

Cause racine : L’ajout de classes de vdev change les schémas I/O ; les resilvers du spécial sont rapides mais le scrub du vdev principal reste lié au HDD ; contention par la charge de production.

Correction : Planifiez les scrubs en conséquence, limitez l’impact du scrub si nécessaire, et n’attribuez pas à tort le temps de scrub HDD à la fonctionnalité du vdev spécial.

Listes de contrôle / plan pas à pas

Checklist de planification (avant de toucher au pool)

1. Classification de la charge : La douleur vient‑elle des métadonnées (opérations d’espace de noms) ou du streaming volumineux ? Obtenez des preuves avec zpool iostat -vl et des tests visibles par les utilisateurs.
2. Décidez du périmètre : Spécial pour les métadonnées uniquement, ou métadonnées + petits blocs via special_small_blocks sur des datasets sélectionnés.
3. Modèle de capacité : Estimez la croissance des métadonnées à partir du compte de fichiers et du comportement des snapshots. Laissez de la marge ; un vdev spécial presque plein est un piège de performance et de placement.
4. Redondance : Mirror les vdevs spéciaux. Confirmez que les domaines de défaillance sont suffisamment indépendants pour votre environnement.
5. Vetting matériel : Modèles SSD SAS, cohérence du firmware, baseline SMART, classe d’endurance.
6. Surveillance : Alertes sur l’utilisation de la classe special, erreurs des appareils, usure SMART, et santé du pool.
7. Gestion de changement : Documentez ce que font les vdevs spéciaux et la propriété « perte signifie perte du pool » en langage clair.

Étapes de déploiement (sûres et ennuyeuses)

1. Confirmez la santé du pool : zpool status -xv doit être healthy.
2. Identifiez les SSD via /dev/disk/by-id ; vérifiez SMART et la capacité.
3. Ajoutez un vdev spécial en miroir : zpool add pool special mirror ...
4. Confirmez la configuration et l’état ONLINE avec zpool status.
5. Mesurez la performance de base : zpool iostat -vl sous une charge représentative.
6. Activez special_small_blocks uniquement sur les datasets qui en bénéficient ; commencez petit (16K–32K).
7. Définissez des seuils d’alerte et vérifiez qu’ils préviennent les bonnes personnes, pas toute l’entreprise.

Checklist d’exploitation (continu)

1. Hebdomadaire : vérifiez l’utilisation du vdev spécial et suivez la tendance.
2. Hebdomadaire : vérifiez l’usure SMART des SSD du vdev spécial.
3. Mensuel : passez en revue les compteurs d’erreurs zpool status ; enquêtez sur toute croissance non nulle.
4. Trimestriel : validez les procédures de restauration ; les vdevs spéciaux ne sont pas l’endroit pour découvrir vos lacunes de sauvegarde.
5. À chaque incident : capturez zpool iostat -vl et arcstat pendant l’événement, pas après qu’il se « soit mystérieusement résolu ».

FAQ

1) Ai‑je vraiment besoin d’un vdev spécial si j’ai beaucoup de RAM ?

La RAM (ARC) aide beaucoup, mais ce n’est pas un substitut. Les misses d’ARC arrivent encore, et le churn des métadonnées peut dépasser la mémoire. Les vdevs spéciaux réduisent la pénalité des misses
et stabilisent la latence en queue quand le working set ne tient pas en RAM.

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

Non. L2ARC est un cache et peut être retiré (avec des conséquences sur la performance, pas sur les données). Le vdev spécial fait partie de l’allocation du pool et peut contenir des métadonnées critiques.
Le perdre peut entraîner la perte du pool.

3) Un vdev spécial est‑il la même chose que SLOG ?

Non. SLOG accélère les écritures synchrones (pensez NFS sync, bases de données avec des patterns fsync). Le vdev spécial accélère les métadonnées et, éventuellement, les petits blocs. Vous pouvez avoir les deux, et beaucoup de systèmes les utilisent ensemble.

4) Pourquoi spécifiquement SAS SSD ? Pourquoi pas NVMe ?

NVMe peut être fantastique, surtout pour des objectifs de latence extrême. Les SSD SAS l’emportent sur l’intégration : baies hot‑swap, dual‑porting, gestion serveur cohérente, et approvisionnement prévisible.
Si vous avez une architecture NVMe propre et un outillage opérationnel solide, NVMe est aussi un bon choix. Ne choisissez pas sur la base du marketing ; choisissez selon la logistique de remplacement et les domaines de défaillance.

5) Que devrais‑je définir pour special_small_blocks ?

Commencez à 16K ou 32K sur les datasets avec beaucoup de petits fichiers ou de lectures aléatoires. Mesurez. Si vous le fixez trop haut, vous consommerez vite la capacité et l’endurance du spécial.
Évitez le « 128K partout » à moins de vouloir intentionnellement mettre la plupart des données sur SSD et d’avoir dimensionné en conséquence.

6) Puis‑je retirer un vdev spécial plus tard ?

En pratique, considérez les vdevs spéciaux comme permanents. Certaines capacités de retrait d’appareil existent dans certains contextes OpenZFS, mais compter sur la suppression d’un vdev spécial est un pari risqué.
Planifiez comme si vous ne pouviez pas le retirer et que vous deviez remplacer/étendre à la place.

7) Quelle taille devrait avoir le vdev spécial ?

Assez grand pour ne pas atteindre une forte utilisation avec la croissance et les snapshots. Le spécial uniquement métadonnées peut être modeste pour certains pools, mais « modeste » dépend de la charge.
Si vous déchargez aussi les petits blocs, dimensionnez beaucoup plus. En entreprise, acheter trop petit est l’option coûteuse car elle force des révisions perturbatrices.

8) L’activation de la compression aide‑t‑elle ou nuit à l’utilisation du spécial ?

Les deux. La compression aide généralement la performance et économise de l’espace, mais elle peut faire rentrer plus de blocs sous le seuil « petit » si vous utilisez special_small_blocks.
Cela augmente l’utilisation du vdev spécial. Prenez cela en compte dans le dimensionnement et surveillez les tendances d’utilisation.

9) Et si mon vdev spécial est en miroir mais que les deux SSD sont dans la même enclosure ?

C’est mieux qu’un disque unique, mais toujours exposé aux défaillances d’enclosure/backplane/expander. Si l’environnement est critique, répartissez les pattes du miroir sur des enclosures ou des HBA.
Si vous ne pouvez pas, ayez au moins des pièces de rechange et pratiquez le remplacement.

10) Les vdevs spéciaux accéléreront‑ils ma base de données ?

Parfois. Si la charge de la base est dominée par les métadonnées côté système de fichiers (beaucoup de petits fichiers, nombreuses tables, mises à jour fsync fréquentes),
vous pouvez constater des bénéfices. Mais les bases de données ont souvent leurs propres patterns I/O et caches. Testez avec une charge représentative, et ne confondez pas « opérations de schéma plus rapides » avec « requêtes plus rapides ».

Conclusion : prochaines étapes que vous pouvez exécuter cette semaine

Les vdevs spéciaux sont l’une des rares fonctionnalités ZFS qui peuvent faire paraître un pool HDD rouillant moderne — sans réécrire votre stratégie de stockage.
L’astuce est de les traiter comme des membres de pool de première classe, et non comme « un truc SSD de cache ».

1. Mesurez d’abord : capturez zpool iostat -vl et faites un vrai test riche en métadonnées (find, scan de sauvegarde, énumération de snapshot) pendant la douleur.
2. Ajoutez un vdev spécial miroir SSD SAS en utilisant les chemins stables /dev/disk/by-id, puis confirmez avec zpool status.
3. Commencez par métadonnées uniquement, puis activez sélectivement special_small_blocks sur les datasets réellement riches en petits fichiers.
4. Configurez des alertes sur l’utilisation de la classe special et la santé des SSD. Ne laissez pas « presque plein » être une surprise.
5. Documentez clairement le comportement en cas de défaillance : la perte d’un vdev spécial peut signifier la perte du pool. Cela évite des changements « utiles » futurs qui détruisent tout.

Si vous voulez la version pro de cette démarche : mettez le vdev spécial en miroir à travers des domaines de défaillance indépendants, dimensionnez‑le avec la croissance en tête,
et gardez‑le ennuyeux. Le stockage ne récompense pas la bravoure. Il récompense la paperasse et la paranoïa.