ZFS : Utiliser NVMe comme SLOG — Quand c’est parfait et quand c’est excessif

SLOG en une phrase (et pourquoi cette phrase compte)

Un SLOG est un dispositif dédié pour les enregistrements ZIL de ZFS qui accélère les écritures synchrones en engageant l’intention rapidement et en sécurité, sans attendre le pool principal.

Relisez ça et soulignez « synchrones ». Si votre charge est principalement composée d’écritures asynchrones, de lectures ou liée au CPU, un SLOG NVMe n’est qu’un placebo coûteux. Si votre charge est dominée par la latence des écritures synchrones (NFS avec sync, datastores ESXi, certaines bases de données, certaines charges VM), un bon SLOG est une astuce puissante.

Aussi : ZFS a déjà un ZIL même sans SLOG. Par défaut, le ZIL réside sur les disques du pool. Ajouter un SLOG n’« active » pas le logging ; cela déplace la partie chaude du chemin d’écriture synchrone vers quelque chose de plus rapide (et idéalement plus sûr).

Ce que le SLOG accélère réellement (et ce qu’il n’accélérera jamais)

Le chemin d’écriture synchrone en clair

Lorsqu’une application effectue une écriture synchrone, elle demande à la pile de stockage une promesse : « Si vous dites ‘terminé’, ces données survivront à un crash. »
ZFS tient cette promesse en écrivant un petit enregistrement décrivant l’écriture (l’« intention ») dans le ZIL, puis en accusant réception auprès de l’application.
Plus tard, lors du prochain transaction group (TXG) sync, ZFS écrit les blocs réels dans le pool principal et libère les entrées ZIL.

Sans SLOG, ces écritures ZIL frappent les mêmes vdevs qui contiennent vos données. Avec un SLOG, ces écritures ZIL frappent l’appareil de log à la place, qui peut offrir une latence dramatiquement plus faible qu’un RAIDZ de HDD ou même des SSD SATA.

Ce qu’un SLOG aide

• Latence des écritures synchrones : ce que les clients ressentent comme « ma VM est lente » ou « le NFS est collant ».
• IOPS d’écritures synchrones : en particulier les nombreuses petites opérations fsync-intensives.
• Contention sur les vdevs du pool : déplacer le trafic ZIL peut réduire la pression d’écritures aléatoires sur le pool principal pendant les pics synchrones.

Ce qu’un SLOG n’aide pas

• Les lectures (c’est l’ARC, le L2ARC et la topologie des vdevs).
• Les écritures asynchrones (ZFS les met en tampon en RAM et les vide selon les frontières TXG ; le SLOG n’est pas sur ce chemin critique).
• Le débit séquentiel (c’est principalement la bande passante des vdevs).
• Les charges liées au CPU (checksum, compression, chiffrement, ou un hôte saturé).

Une vérité sèche : un SLOG ne peut pas rendre une mauvaise topologie de pool bonne. Il peut rendre les écritures synchrones moins pénibles pendant que vous planifiez une meilleure topologie.

Blague n°1 : Acheter un SLOG pour une charge asynchrone, c’est comme installer un turbo sur une voiture garée. C’est du matériel impressionnant, et ça ne va toujours nulle part.

Quand NVMe comme SLOG est parfait

1) Exports NFS où les clients exigent des garanties sync

Beaucoup de clients NFS (et d’administrateurs) insistent sur des écritures sûres, et NFS est souvent utilisé pour des usages incompatibles avec la perte de données : datastores VM, dépôts d’artefacts de build, répertoires personnels avec « mon éditeur appelle fsync », etc.
Si votre export est configuré en sync (ou si le comportement client force effectivement le sync), la latence de l’engagement de ces enregistrements ZIL détermine l’expérience utilisateur.

C’est la victoire canonique du SLOG : un pool de HDD (ou un RAIDZ de SSD) servant du NFS avec un trafic fsync constant. Placez un NVMe à faible latence avec protection contre la perte de puissance (PLP) devant cela, et vous sentirez la différence.

2) Stockage de virtualisation avec beaucoup de petites écritures synchrones

Les plateformes VM et les systèmes de fichiers invités génèrent des écritures synchrones plus souvent qu’on ne le croit. Journalisation, mises à jour de métadonnées, vidanges de bases de données dans les VM, comportement du système invité et paramètres de durabilité applicative s’additionnent.
Un bon SLOG peut transformer une « latence d’écriture synchrone aléatoire 8K de 10–20ms » en « sous-millisecondes à quelques millisecondes », ce qui fait la différence entre « acceptable » et « pourquoi l’interface se fige ».

3) Bases de données qui reposent réellement sur fsync()

Certaines charges de base de données sont dominées par la latence de commit durable. Si la base est correctement configurée pour exiger la durabilité (et que vous la souhaitez), vous êtes en territoire sync.
Un SLOG rapide et sûr peut réduire la variance des commits—c’est la variance qui provoque des pics de latence en queue et des blocages visibles par l’utilisateur.

4) Vous avez un pool lent que vous ne pouvez pas reconstruire tout de suite

Parfois vous héritez d’un pool « RAIDZ2 sur HDD nearline » parce que quelqu’un a optimisé le coût par téra et oublié que la latence est aussi un coût.
Un SLOG NVMe peut être un pansement tactique : il réduit la douleur pour les consommateurs synchrones pendant que vous planifiez la vraie correction (plus de vdevs, des mirrors, special vdevs, ou une architecture différente).

5) Vous avez besoin d’une durabilité prévisible sous charge

Les meilleurs dispositifs SLOG ne sont pas seulement rapides ; ils sont cohérents. La performance des écritures synchrones concerne autant la latence en queue que la latence moyenne.
Les SSD grand public peuvent sembler excellents jusqu’à ce qu’ils déclenchent un garbage collection interne ou un effondrement d’écriture, et alors votre « écriture durable » prend soudainement 50ms. Les utilisateurs le remarquent.

Quand le SLOG est excessif

1) Votre charge est principalement d’écritures asynchrones

Copies de fichiers, ingestion média, sauvegardes en streaming séquentiel, écritures d’object storage par lots, pipelines d’analytics qui tamponnent—ces charges ne bloquent généralement pas sur les commits sync.
ZFS absorbera beaucoup de cela dans l’ARC et flushera aux frontières TXG. Un SLOG n’entrera pas en jeu.

2) Vous êtes en fait lié aux lectures ou aux métadonnées

La mauvaise interprétation classique : « le stockage est lent » quand le goulot est des misses de cache, trop peu de vdevs, ou des métadonnées dispersées sur des HDD.
Vous pourriez avoir besoin de plus de mirrors, d’un special vdev pour métadonnées/petits blocs, plus de RAM pour l’ARC, ou d’un meilleur réglage de recordsize. Rien de tout cela n’est un SLOG.

3) Vous pouvez (et devez) supprimer la contrainte de sync à la place

Parfois la bonne démarche est une politique, pas du matériel : avez-vous vraiment besoin du sync sur ce dataset ? Exportez-vous NFS en sync parce que « on a toujours fait comme ça », alors que les données ne sont pas critiques et sont déjà répliquées ?
Si vous pouvez tolérer une petite fenêtre de perte sur crash, définir sync=disabled sur le dataset approprié vous donne un gain plus important que n’importe quel SLOG. Cela augmente aussi le risque. Ne le faites pas à la légère.

4) Vous n’avez pas de protection contre la perte de puissance, donc vous êtes « rapide mais menteur »

Le rôle entier du SLOG est de rendre les écritures synchrones sûres. Si votre appareil ment sur les flushs, ou perd des données lors d’une coupure de courant, vous pouvez finir par ack des écritures durables qui n’ont jamais été persistées. Ce n’est pas un bug de performance. C’est de la corruption avec un bon budget marketing.

5) Votre pool est déjà assez rapide pour le sync

Si vous êtes sur des mirrors SSDs en entier avec une latence solide et que votre goulot d’écriture synchrone est déjà minime, les gains marginaux d’un SLOG peuvent être difficiles à justifier.
Mesurez d’abord. Si p99 sync lat est déjà dans les faibles millisecondes et que la charge ne se plaint pas, vous avez de meilleures priorités pour votre budget de complexité.

Faits et histoire intéressants qui changent les décisions

1. ZFS est né chez Sun au milieu des années 2000 avec un focus explicite sur l’intégrité de bout en bout : checksums, copy-on-write et sémantiques transactionnelles n’étaient pas des après-pensées.
2. Le ZIL existe sur chaque pool que vous ajoutiez un SLOG ou non. Le « séparé » est optionnel ; le journal d’intention ne l’est pas.
3. Les écritures SLOG sont généralement de courte durée : les entrées ZIL servent à la reprise après crash, ce n’est pas un journal longue durée comme ext4. Elles sont supprimées après le commit du TXG.
4. Les premières recommandations « SSD comme log » venaient d’une époque où les pools HDD étaient courants et les SSD chers ; le delta de performance pour les écritures sync était massif et évident.
5. La protection contre la perte de puissance (PLP) est devenue la ligne de démarcation entre « un SSD grand public semble correct » et « un SSD entreprise est ennuyamment correct. » La correction du ZIL dépend du comportement honnête des flushs.
6. Le SLOG n’a pas besoin d’une grande capacité parce qu’il ne doit contenir qu’une petite fenêtre d’écritures synchrones en attente—typiquement quelques secondes—jusqu’au commit TXG.
7. Mirroring du SLOG concerne la disponibilité, pas la vitesse : si le SLOG meurt, le pool peut continuer, mais vous perdez le chemin rapide pour les écritures sync (et vous pouvez avoir une fenêtre de risque lors du remplacement).
8. NVMe a changé la conversation en rendant la basse latence accessible, mais il a aussi facilité l’achat du mauvais appareil : le NVMe grand public est rapide, mais PLP et latence cohérente sont les éléments difficiles.
9. Le « sync=disabled » de ZFS est fameux parce qu’il peut rendre les benchmarks héroïques tout en changeant silencieusement les garanties de durabilité. Ce n’est pas un repas gratuit ; c’est un contrat différent.

Exigences matérielles : latence, PLP, endurance, et pourquoi « rapide » ne suffit pas

La latence prime sur le débit

La performance SLOG concerne la rapidité avec laquelle l’appareil peut engager de petites écritures et les flushs de façon sûre. Vous vous souciez de :
faible latence d’écriture, faible latence de flush et latence en queue stable. Un appareil qui fait 7GB/s en écriture séquentielle mais qui cale au flush est un mauvais SLOG.

La protection contre la perte de puissance (PLP) est non négociable pour les workloads sync sérieux

Avec les écritures synchrones, l’application parie ses données sur la parole de votre pile de stockage. Le PLP aide à garantir que les données accusées comme durables pourront survivre à une coupure soudaine d’alimentation.
Dans les SSD entreprise, c’est typiquement soutenu par des condensateurs et un firmware conçu pour vider les buffers volatils vers la NAND.

Peut-on utiliser un NVMe grand public comme SLOG ? Oui. Devriez-vous pour des workloads sync critiques pour l’entreprise ? Pas à moins d’être prêt à expliquer à l’équipe d’incident pourquoi un « commit durable » a disparu. Utilisez le bon outil.

L’endurance compte, mais moins que ce que l’on craint

Les écritures SLOG peuvent être intensives en écriture, mais le volume total dépend de la quantité réelle de trafic d’écritures synchrones que vous générez. Le killer n’est pas les bytes totaux ; c’est le débit d’écriture soutenu plus les flushs, plus le comportement pire-cas sous charge continue.
Malgré tout : choisissez un appareil avec une endurance réelle, pas un disque à prix cassé qui est à un bug de firmware d’une mauvaise semaine.

Le format et la connectivité importent opérationnellement

U.2/U.3 ou M.2 entreprise avec refroidissement et monitoring appropriés est plus facile à exploiter en production qu’une clé grand public planquée sous un GPU.
Pensez aussi au hot-swap et comment vous le remplacerez à 2 h du matin sans transformer « remplacement du log device » en « fenêtre de maintenance de l’hôte ».

Citation (idée paraphrasée), Werner Vogels : Vous concevez des systèmes en supposant que des choses échouent ; la fiabilité vient d’attendre la panne et de récupérer rapidement.

Dimensionnement, mirroring et choix de topologie

Quelle taille pour un SLOG ?

Plus petit que vous ne le pensez. Le SLOG n’a besoin d’absorber que la quantité maximale d’écritures synchrones en attente entre les syncs TXG.
Le timeout TXG par défaut est généralement autour de 5 secondes. Même si vous avez des centaines de MB/s d’écritures synchrones, l’espace de log requis n’est pas énorme.
En pratique, 8–32GB d’espace de log effectif suffisent souvent ; les gens déploient 100–400GB parce que c’est la taille du SSD, pas parce que ZFS en a besoin.

Mais ne coupez pas trop court. Laissez de la marge pour les rafales, et souvenez-vous que la performance peut se dégrader si l’appareil est presque plein ou fortement fragmenté en interne.

Mirrorez le SLOG quand le downtime ou le risque coûte cher

Un seul dispositif SLOG est un point unique de défaillance de performance. S’il meurt, votre pool continue, mais les écritures sync basculent vers les vdevs principaux et la latence peut grimper fortement.
Mirrorez le SLOG pour maintenir le chemin rapide lors d’une panne d’appareil et réduire le drame « nous l’avons remplacé et tout est lent jusqu’au resilver ».

Ne confondez pas « log vdev » et « special vdev »

Le SLOG sert le ZIL (enregistrements d’intention sync). Un special vdev sert les métadonnées et petits blocs (et peut changer la donne pour des pools HDD avec beaucoup d’I/O de métadonnées).
Ils résolvent des problèmes différents. Acheter un SLOG quand vous aviez besoin d’un special vdev est une erreur coûteuse classique.

Partitionner un appareil pour le SLOG est possible—souvent une mauvaise habitude

Oui, vous pouvez partitionner un NVMe et utiliser une petite tranche comme SLOG. Non, vous ne devriez pas le faire à la légère en production.
Mélanger des charges sur le même appareil augmente la variance et complique les domaines de défaillance. Si vous devez le faire, isolez via des appareils séparés et gardez le comportement du SLOG prévisible.

Blague n°2 : Partitionner un NVMe grand public en « SLOG + L2ARC + swap » est l’équivalent stockage d’utiliser un parachute pour deux personnes—créatif, mais l’atterrissage devient étrange.

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

Voici les vérifications que j’exécute quand quelqu’un dit « nous avons ajouté un SLOG et rien n’a changé », ou « les écritures synchrones nous tuent », ou « ce NVMe est-il sûr comme log device ».
Chaque tâche inclut une commande, une sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Confirm whether you even have a SLOG (and what it is)

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
        logs
          nvme0n1p1                 ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Vous avez un log vdev (logs) sur nvme0n1p1.

Décision : Si le périphérique de log n’est pas listé, vous n’avez pas de SLOG. S’il est listé mais non miroir, décidez si une panne affectant la performance est acceptable.

Task 2: Check dataset sync settings (the workload contract)

cr0x@server:~$ zfs get -r sync tank/vmstore
NAME          PROPERTY  VALUE  SOURCE
tank/vmstore  sync      standard  local

Ce que cela signifie : Le comportement sync est par défaut (« honore les requêtes sync de l’application »).

Décision : Si ceci indique disabled, votre SLOG ne fera probablement pas grand-chose parce que vous avez dit à ZFS d’ignorer les sémantiques sync. Si c’est always, vous venez d’envoyer plus d’écritures sur le chemin SLOG—peut-être volontairement, peut-être pas.

Task 3: Check how the NFS export is configured (sync vs async)

cr0x@server:~$ cat /etc/exports
/tank/vmstore 10.10.0.0/24(rw,sync,no_subtree_check)
/tank/media   10.10.0.0/24(rw,async,no_subtree_check)

Ce que cela signifie : vmstore est en sync (SLOG pertinent). media est en async (SLOG majoritairement non pertinent).

Décision : Concentrez l’effort SLOG là où le sync est requis. N’« optimisez » pas des exports async avec un SLOG et ne vous étonnez pas ensuite que rien n’ait bougé.

Task 4: See if the workload is generating sync writes at all

cr0x@server:~$ arcstat.py 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01   222    12      5     2    1    10    4     0    0   42G   64G
12:10:02   240    14      5     3    1    11    4     0    0   42G   64G
12:10:03   230    11      4     2    1     9    4     0    0   42G   64G

Ce que cela signifie : Cela montre le comportement de l’ARC, pas directement les écritures sync—mais cela vous indique si vous êtes lié aux lectures et aux misses de cache.

Décision : Si la plainte est « lectures lentes », arrêtez de parler de SLOG et commencez à parler de topologie vdev, de dimensionnement ARC et peut-être de special vdevs.

Task 5: Observe ZFS latency and see if writes are the pain

cr0x@server:~$ zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        20.1T  10.4T    120    980  1.2M  38.4M
  raidz2-0  20.1T  10.4T    120    840  1.2M  32.1M
    sda         -      -     30    210   310K  8.1M
    sdb         -      -     28    205   295K  8.0M
    sdc         -      -     31    212   305K  8.0M
    sdd         -      -     31    213   310K  8.0M
logs            -      -      0    140      0  6.3M
  nvme0n1p1     -      -      0    140      0  6.3M

Ce que cela signifie : Vous voyez des écritures sur le dispositif de log. Cela suggère fortement qu’une activité sync est en cours.

Décision : Si les écritures de log sont nulles alors que les utilisateurs se plaignent de « latence sync », il se peut que vous ne fassiez pas d’écritures sync, ou que le sync soit désactivé quelque part. Allez vérifier le comportement client/app.

Task 6: Check ZIL/SLOG statistics via kstats (Linux OpenZFS)

cr0x@server:~$ sudo kstat -p | egrep 'zfs:0:zil|zfs:0:vdev_log' | head
zfs:0:zil:zil_commit_count                           184229
zfs:0:zil:zil_commit_writer_count                     182910
zfs:0:zil:zil_commit_wait_count                        1319
zfs:0:zil:zil_itx_count                              920114
zfs:0:vdev_log:vdev_log_write_bytes               12899323904

Ce que cela signifie : Des commits ont lieu ; certains ont dû attendre. Les bytes de log ne sont pas négligeables.

Décision : Si les compteurs d’attente de commit montent sous charge, vous touchez la latence ou la contention du dispositif de log. Envisagez un meilleur SLOG ou du mirroring, et vérifiez le throttling ou la surchauffe du périphérique.

Task 7: Verify the NVMe device has PLP hints and identify model

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | egrep 'mn|vid|oacs|oncs|vwc'
mn      : INTEL SSDPE2KX040T8
vid     : 0x8086
oacs    : 0x17
oncs    : 0x5f
vwc     : 0x01

Ce que cela signifie : Vous avez identifié le modèle exact ; vwc indique que les infos sur le cache d’écriture volatile sont exposées (indice, pas garantie de PLP).

Décision : Si vous ne pouvez pas identifier le modèle ou si c’est un disque grand public avec un comportement PLP flou, ne l’utilisez pas comme SLOG pour des workloads sync critiques. Préférez un disque entreprise avec comportement de flush connu.

Task 8: Check NVMe health and error counters

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 43 C
available_spare                     : 100%
percentage_used                     : 2%
data_units_written                  : 184,992
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : Santé OK, faible usure, pas d’erreurs média.

Décision : Si critical_warning est non nul, les températures sont élevées ou les logs d’erreur augmentent, considérez le SLOG suspect. Remplacez tôt ; c’est moins cher que de chasser une latence fantôme.

Task 9: Check if the NVMe is thermal throttling (silent latency killer)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|critical_warning'
critical_warning                    : 0x00
temperature                         : 72 C

Ce que cela signifie : 72°C flirte avec la zone de throttling pour beaucoup de modèles, selon le refroidissement.

Décision : Si vous constatez de hautes températures pendant les incidents, corrigez le refroidissement avant d’acheter un « disque plus rapide ». Un NVMe en throttling est un NVMe lent avec plus de marketing.

Task 10: Validate that the log device is actually being used for sync I/O

cr0x@server:~$ sudo zdb -C tank | egrep -A2 'log'
        log
            type: 'disk'
            id: 2
            guid: 12759911906639365414

Ce que cela signifie : La configuration du pool inclut un log vdev.

Décision : Si vous attendiez un log vdev mais ne le voyez pas, vous l’avez peut-être ajouté au mauvais pool, ou il a échoué et a été retiré. Corrigez la configuration avant d’ajuster autre chose.

Task 11: Measure sync write latency directly with a controlled test (use carefully)

cr0x@server:~$ fio --name=syncwrite --filename=/tank/vmstore/fio.test --rw=write --bs=8k --iodepth=1 --numjobs=1 --direct=1 --fsync=1 --size=512m --runtime=20 --time_based --group_reporting
syncwrite: (groupid=0, jobs=1): err= 0: pid=1337: Sat Dec 16 12:10:55 2025
  write: IOPS=1450, BW=11.3MiB/s (11.8MB/s)(226MiB/20002msec)
    clat (usec): min=190, max=14200, avg=640.12, stdev=410.50

Ce que cela signifie : C’est un pattern sync-intensif (fsync=1). Latence moyenne de commit ~0.64ms avec quelques spikes en queue.

Décision : Si la latence est de plusieurs millisecondes sur un SLOG NVMe, investiguez l’appareil et le chemin (liaison PCIe, throttling, contention). Si c’est des dizaines de millisecondes, vous retombez peut‑être sur le pool ou l’appareil se comporte mal.

Task 12: Confirm TXG behavior and dirty data pressure (why sync may be stalling)

cr0x@server:~$ cat /proc/spl/kstat/zfs/txgs
217 5 0x01 184 4608 2401924197 836746120 0 0

Ce que cela signifie : Les stats TXG sont présentes ; sur certains systèmes vous parsez les champs pour timing et backlog avec des outils. L’essentiel : le sync TXG ne doit pas être en retard en permanence.

Décision : Si le sync TXG est constamment surchargé, votre pool est limité en écriture ou sous-dimensionné. Un SLOG aide l’accusé de réception sync, mais n’augmente pas magiquement la capacité du pool à finalement commiter.

Task 13: Check if your pool is constrained by too few vdevs (IOPS math)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       30.5T  20.1T  10.4T        -         -    22%    65%  1.00x  ONLINE  -
  raidz2-0 30.5T  20.1T  10.4T        -         -    22%    65%      -  ONLINE  -

Ce que cela signifie : Un seul vdev RAIDZ. Souvent excellent pour la capacité, pas pour les IOPS.

Décision : Si votre charge est riche en I/O aléatoire, en particulier pour le stockage VM, la correction appropriée pourrait être plus de vdevs (mirrors en stripe) plutôt qu’un SLOG.

Task 14: Confirm ashift and alignment (prevent self-inflicted latency)

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

Ce que cela signifie : Alignement secteur 4K (ashift=12) généralement correct pour les disques modernes et les SSD.

Décision : Si vous voyez ashift: 9 sur des disques 4K, vous pouvez subir une amplification d’écriture pathologique et de la latence. C’est une correction au niveau rebuild, pas un correctif SLOG.

Feuille de diagnostic rapide

Quand quelqu’un crie « le stockage est lent » et que vous avez 20 minutes avant la prochaine escalade, voici la manière la plus rapide de déterminer si le SLOG est pertinent.

Première étape : déterminer si la douleur est la latence des écritures synchrones

• Vérifiez sync du dataset et les réglages de protocole (NFS/SMB/iSCSI). Si le sync n’est pas en jeu, le SLOG n’est pas le héros.
• Recherchez des preuves d’activité du dispositif de log (zpool iostat -v montrant des écritures sous logs).
• Si possible, lancez un petit test contrôlé fio sur le dataset (ne le faites pas sur un système fragile en pleine charge).

Deuxième étape : valider que le dispositif SLOG n’est pas le goulot

• État NVMe (nvme smart-log) et température. Le throttling provoque une latence en queue « mystérieuse ».
• kstats pour les attentes de commit ZIL : montent-ils quand la latence explose ?
• Confirmez que le log vdev est ONLINE et non silencieusement fautif/retiré.

Troisième étape : si le sync est correct, trouvez le véritable goulot

• Taux de misses de lecture : thrash ARC vs lectures disque réelles.
• Topologie du pool : trop peu de vdevs ou RAIDZ pour des workloads VM est un récidiviste.
• Surcharge CPU : chiffrement/compression/checksum avec cœurs saturés peut masquer des « disques lents ».
• Réseau : la latence NFS se situe souvent côté NIC/MTU/interrupts, pas côté pool.

Erreurs courantes : symptômes → cause racine → correctif

1) « Nous avons ajouté un NVMe SLOG et rien n’a amélioré. »

Symptômes : Les benchmarks changent peu ; les utilisateurs se plaignent toujours ; zpool iostat montre peu d’écritures de log.

Cause racine : La charge n’est pas dominée par des écritures synchrones (ou le sync est désactivé, ou les clients n’émettent pas de sync).

Correctif : Vérifiez avec zfs get sync, les options d’exports NFS et un test fio sync-intensif. Si c’est lié aux lectures/métadonnées, considérez ARC/special vdev/changements de topologie vdev.

2) « La latence s’est améliorée en moyenne, mais le p99 est toujours terrible. »

Symptômes : La latence moyenne baisse ; des stalls occasionnels de plusieurs dizaines de ms persistent.

Cause racine : Throttling NVMe, garbage collection interne, bizarreries de firmware, ou contention due au partage du périphérique.

Correctif : Vérifiez la température, les logs du contrôleur, et évitez de co-localiser L2ARC/swap/autres charges sur le même appareil. Utilisez un SSD entreprise à latence cohérente.

3) « Après la mort du SLOG, tout est devenu inutilisable. »

Symptômes : Le pool reste ONLINE mais les clients sync deviennent très lents ; la récupération exige un remplacement matériel d’urgence.

Cause racine : La défaillance d’un seul log device a supprimé le chemin rapide sync ; le pool principal ne peut pas gérer les IOPS d’écritures sync.

Correctif : Mirror le SLOG. Traitez aussi la capacité d’écriture aléatoire du pool si elle est fondamentalement inadaptée à la charge.

4) « Nous avons utilisé un NVMe grand public, et après un incident électrique nous avons eu une corruption étrange. »

Symptômes : Incohérences applicatives, anomalies de récupération de base de données, parfois sans erreurs ZFS évidentes.

Cause racine : L’appareil a ack des flushs sans persistance réelle (pas de PLP, cache volatile, comportement firmware).

Correctif : Utilisez un appareil entreprise avec PLP pour le SLOG. Assurez une alimentation stable (UPS) et préférez le mirroring SLOG si la charge est critique.

5) « Nous avons forcé sync=always partout et maintenant c’est plus lent. »

Symptômes : Le débit d’écriture chute ; la latence augmente ; le SLOG montre une activité élevée.

Cause racine : Vous avez transformé du trafic async en sync et surchargé le chemin de commit.

Correctif : N’utilisez sync=always que là où c’est explicitement requis. Gardez standard par défaut pour les datasets généraux.

6) « Nous avons miroré le SLOG et attendu un doublement de performance. »

Symptômes : Aucun gain ; parfois légèrement pire.

Cause racine : Les mirrors servent la redondance ; chaque écriture ZIL doit être engagée sur les deux appareils.

Correctif : Mirror pour la disponibilité et la sécurité du chemin rapide. Si vous avez besoin de plus de performance, il vous faut un profil de latence unitaire meilleur ou une architecture différente.

Trois mini-histoires d’entreprise réelles

Incident causé par une fausse hypothèse : « SLOG rend tout plus rapide »

Une société SaaS de taille moyenne exploitait un cluster NFS sur ZFS pour des artefacts CI et des couches d’images conteneur. L’équipe stockage a entendu « NVMe rend ZFS rapide » et a installé un joli log device sur chaque filer.
L’incident qu’ils tentaient de résoudre était des jobs de build qui time-outaient aux heures de pointe.

Après le changement, rien ne s’est amélioré. Les graphiques étaient têtus. L’équipe de build voyait toujours des timeouts, et maintenant l’équipe stockage devait défendre un achat qui n’avait rien changé.
Un ingénieur senior a finalement posé la question un peu brute : « Sommes-nous même limités par les écritures synchrones ? »

Ils ont vérifié les exports. Le chemin des artefacts était monté avec des réglages favorisant le débit et acceptant un certain risque ; le vrai goulot était les lectures de métadonnées et les parcours de répertoires sur un pool construit avec de grands vdevs RAIDZ de HDD.
La charge était des milliers de petits stats et opens de fichiers—pas des commits fsync-intensifs.

La correction n’était pas plus de dispositifs de log. C’était une combinaison d’ajout d’un special vdev pour métadonnées/petits blocs et de repenser le recordsize des datasets pour les chemins chauds.
Le SLOG n’était pas mauvais. Il était juste hors sujet. La mauvaise hypothèse était de traiter « dispositif rapide » comme une incantation universelle de performance.

Optimisation qui a mal tourné : « Utilisons un NVMe grand public comme SLOG »

Une rénovation infrastructurelle dirigée par la finance a abouti chez une entreprise hébergeant des workloads multi-tenant sur ZFS via iSCSI. L’équipe voulait réduire la latence des commits pour quelques bases de données bavardes.
Quelqu’un a proposé un NVMe grand public comme SLOG : « Il est rapide et ce n’est que pour les logs. Ça ira. »

Ça allait—jusqu’au premier incident réel d’alimentation. Pas une panne dramatique, juste un petit blip : un reboot de PDU pendant des travaux de routine. Les systèmes sont revenus. ZFS a importé les pools proprement. Pas de hurlements.
Une semaine plus tard, un tenant a ouvert un ticket : état applicatif incohérent. Puis un autre.

L’investigation a été pénible car rien n’était clairement cassé. Le pool était sain. Les scrubs étaient propres. Le problème sentait « commits durables qui n’étaient pas durables », ce qui est le pire genre de mystère.
Ils ont finalement corrélé les premiers reports avec le blip d’alimentation et le modèle NVMe grand public utilisé pour le SLOG.

Le changement final fut ennuyeux : remplacer les SLOG par des disques entreprise avec PLP, les miroirs, et arrêter de traiter les sémantiques de flush comme optionnelles.
La performance est restée bonne, et surtout, les promesses du système ont correspondu à la réalité. L’optimisation a mal tourné parce qu’elle a optimisé le mauvais indicateur : coût initial sur exactitude.

Pratique ennuyeuse mais correcte qui a sauvé la mise : SLOG miroré et remplacement répété

Une entreprise régulée exploitait un appliance ZFS servant NFS à de la virtualisation et à quelques bases internes. Ils avaient un SLOG miroir sur des SSD PLP entreprise.
Personne ne le célébrait. Il était juste là, tranquillement, absorbant les écritures synchrones.

Un après-midi, un des dispositifs SLOG a commencé à loguer des erreurs média. Le monitoring l’a signalé, et le SRE d’astreinte a fait la chose la moins héroïque imaginable : suivre le runbook.
Ils ont confirmé que le pool utilisait encore un log miroir, vérifié que le dispositif restant était sain, et planifié un remplacement la même journée.

Pendant le remplacement, rien de notable n’est arrivé chez les clients. La latence n’a pas bondi. Il n’y a pas eu de fenêtre de changement d’urgence.
L’équipe a remplacé le dispositif, l’a ré-ajouté au log miroir, et surveillé le resilver qui s’est achevé rapidement parce que le log vdev est petit et le processus bien connu.

La morale n’est pas « mirrorez toujours le SLOG ». C’est que les systèmes de production vous rémunèrent pour la discipline ennuyeuse : redondance là où ça compte, monitoring spécifique, et une procédure répétée pour ne pas apprendre les commandes ZFS pendant un incident.

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

Étape par étape : décider si vous avez besoin d’un SLOG

1. Identifier les charges : NFS pour VMs ? bases de données ? répertoires personnels ? sauvegardes séquentielles ?
2. Confirmer le comportement sync : dataset sync, options d’export NFS, réglages de durabilité applicative.
3. Mesurer : test fio sync-intensif sur un dataset de staging ; comparer p95/p99 avec et sans SLOG si possible.
4. Vérifier la conception du pool : si c’est un seul vdev RAIDZ servant des I/O VM, corrigez cela quoi qu’il arrive.
5. Décider de la tolérance au risque : si les données doivent être sûres, ne planifiez pas autour de sync=disabled.

Étape par étape : déployer un SLOG NVMe de manière sensée

1. Choisir du matériel avec PLP et latence stable. Traitez « entreprise » comme une exigence, pas une impression.
2. Préférer le mirroring si la stabilité de performance importe pendant une panne d’appareil.
3. Installer avec refroidissement : le throttling NVMe est une panne de performance déguisée.
4. Ajouter le log vdev durant une fenêtre contrôlée et vérifier l’utilisation sous charge réelle.
5. Surveiller : températures, logs d’erreur et comportement des attentes de commit ZIL.

Étape par étape : habitudes opérationnelles sûres

1. Garder les dispositifs SLOG mono-usage.
2. Enregistrer le modèle/version firmware des appareils dans l’inventaire.
3. Tester la panne : simuler le retrait en fenêtre de maintenance et confirmer que la dégradation de performance est acceptable.
4. Avoir un runbook de remplacement qui inclut comment ré-ajouter des logs miroir et vérifier l’état du pool.

Actions ZFS courantes pour la gestion du SLOG

Ce sont des opérations courantes en exploitation, mais faites-les prudemment : retirer des logs peut changer la performance instantanément sous charge.

Add a mirrored SLOG

cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1p1 /dev/nvme1n1p1

Ce que cela signifie : Ajoute un log vdev miroir ; les écritures ZIL sont engagées sur les deux appareils.

Décision : Utilisez-le quand vous avez besoin que le chemin sync rapide survive à une panne d’appareil.

Remove an existing log vdev

cr0x@server:~$ sudo zpool remove tank nvme0n1p1

Ce que cela signifie : Supprime le dispositif de log (si amovible dans votre version/config ZFS). Les écritures sync retombent sur le ZIL en-pool.

Décision : Faites-le seulement quand vous êtes sûr que le pool peut gérer la charge sync ou lors d’une fenêtre de maintenance contrôlée.

FAQ

1) Le SLOG est-il la même chose que le ZIL ?

Non. Le ZIL est le mécanisme de journal d’intention sur disque utilisé pour les écritures synchrones. Un SLOG est un dispositif séparé qui peut contenir les enregistrements ZIL pour qu’ils soient engagés plus rapidement.

2) Ajouter un SLOG accélérera-t-il mes partages SMB ?

Parfois, mais seulement si la charge est heavy en écritures synchrones et que SMB est configuré/utilisé de manière à forcer les sémantiques de durabilité.
Mesurez. N’assumez pas. Les problèmes de performance SMB sont souvent métadonnées, oplocks, ou réseau/CPU.

3) Puis-je utiliser n’importe quel NVMe comme SLOG ?

Vous pouvez, mais vous ne devriez pas pour des données critiques à moins qu’il n’ait une protection contre la perte de puissance et un comportement de flush cohérent.
« Rapide » n’est pas l’exigence ; « rapide et honnête sous perte d’alimentation » l’est.

4) Dois-je mirrorer le SLOG ?

Si la perte du SLOG provoquerait un incident de performance visible (et c’est souvent le cas pour NFS+VM), mirror-le.
Si c’est une machine de labo et que vous pouvez tolérer une chute de performance soudaine lors d’une panne, un seul dispositif peut être acceptable.

5) Comment savoir si mes clients émettent des écritures synchrones ?

Vous l’inférez depuis le comportement : activité d’écriture sur le dispositif de log, stats de commit ZIL, réglages applicatifs, et tests contrôlés (fio avec fsync).
L’approche honnête : mesurer sous charge similaire à la production et vérifier si la latence corrèle avec les commits ZIL.

6) Le SLOG aide-t-il pour les scrubs ou les resilvers du pool ?

Non. Les scrubs et resilvers concernent la lecture et la reconstruction des données. Le SLOG sert à accuser rapidement réception des écritures synchrones.

7) Quelle est la relation entre SLOG et L2ARC ?

Complètement différente : L2ARC est une extension du cache de lecture ; le SLOG est un accélérateur d’écriture synchrone.
Les gens achètent les deux quand ils sont désespérés. Parfois l’un seul est pertinent. Parfois aucun des deux.

8) sync=disabled est-il sûr si j’ai un UPS ?

Un UPS réduit la probabilité d’une coupure soudaine d’alimentation, mais n’élimine pas les kernel panics, resets de contrôleur ou bugs de firmware.
sync=disabled change les sémantiques de durabilité. Utilisez-le seulement quand les données sont jetables ou protégées ailleurs, et que vous avez accepté le risque par écrit.

9) La capacité du SLOG a-t-elle de l’importance ?

Habituellement peu. Ce qui compte est la latence, le comportement de flush et la cohérence. La capacité doit juste couvrir la fenêtre d’écritures synchrones en attente plus une marge.

10) Si j’ai un pool miroir tout-SSD, ai-je encore besoin d’un SLOG ?

Souvent non, parce que la latence sync du pool peut déjà être bonne. Mais si vous servez du NFS/iSCSI sensible à la latence et que vous voyez des goulots de commit sync, un SLOG peut encore aider.
Mesurez d’abord ; n’achetez pas du matériel par habitude.

Conclusion : étapes pratiques suivantes

NVMe comme SLOG est parfait quand vous avez une réelle pression d’écritures synchrones et que vous avez besoin d’accusés de réception durables avec une latence faible et prévisible.
C’est excessif quand votre charge est asynchrone, liée aux lectures, dépendante des métadonnées, ou simplement victime d’une topologie de pool incapable de faire des IOPS aléatoires.

Étapes suivantes qui font vraiment avancer les choses :

1. Prouvez que le sync est le goulot : vérifiez les réglages dataset/export, observez les écritures de log, lancez un test fio sync-intensif.
2. Validez votre dispositif SLOG : PLP-capable, sain, frais et cohérent. Si c’est grand public, considérez cela comme une décision de risque, pas un détail technique.
3. Concevez pour la panne : mirror le SLOG si la stabilité de performance importe, et entraînez-vous au remplacement.
4. Corrigez le pool si c’est le vrai problème : plus de vdevs, mirrors pour les IOPS, special vdev pour métadonnées, et assez de RAM pour l’ARC bat souvent « un gadget de plus ».

Si vous faites cela dans l’ordre, vous aurez soit la victoire SLOG attendue—soit vous vous serez évité d’acheter une solution très rapide pour le mauvais problème.