ZFS SLOG : quand un périphérique de journal aide, quand il est inutile, quand il est dangereux

octobre 18, 2025 • février 3, 2026 • Lecture : 37 min • Views: 11

Cet article vous a aidé ?

Il existe deux sortes de problèmes de performance ZFS : ceux que vous pouvez corriger par l’architecture, et ceux que vous essayez de résoudre par des achats de matériel à 2 h du matin. Un périphérique de journal séparé (SLOG) se situe précisément sur cette ligne. Pour la bonne charge de travail, il transforme « pourquoi chaque fsync prend une éternité ? » en « ah, maintenant c’est bon. ». Pour la mauvaise charge, c’est un presse-papier élégant qui ajoute de nouveaux modes de défaillance.

Ce guide de terrain est écrit du point de vue de personnes qui reçoivent vraiment des pages : ce qu’est un SLOG, ce qu’il n’est pas, les « pièges » qui brûlent les équipes, et les commandes que vous lancerez lorsque le graphe devient vertical. Nous parlerons des sémantiques sync, de la latence, de la protection contre les pertes d’alimentation, et comment déterminer si vous êtes sur le point d’améliorer les choses — ou de les rendre excitantes dans le mauvais sens.

Ce qu’est réellement un SLOG (et pourquoi il existe)

Clarifions le vocabulaire, car « SLOG » est un de ces termes qui est utilisé comme s’il s’agissait d’un bouton turbo.

ZIL est le ZFS Intent Log. Il existe dans chaque pool ZFS. Par défaut, ce n’est pas un périphérique séparé. C’est un mécanisme : lorsqu’une application demande une écriture synchrone, ZFS doit confirmer que cette écriture est durable (ou survivra à une perte de courant) avant d’en accuser réception. ZFS accomplit cela en écrivant un enregistrement de l’opération dans le ZIL, puis en incorporant plus tard ce changement dans les structures sur disque principales lors des commits normaux des groupes de transactions (TXG).

SLOG est un périphérique LOG séparé : un vdev dédié où ZFS stocke les enregistrements du ZIL au lieu d’utiliser les disques principaux du pool. L’objectif est la latence. Les disques rotatifs (et même de nombreux SSD) sont mauvais pour les petites écritures sync à faible latence lorsqu’ils sont occupés à d’autres tâches. Un bon périphérique SLOG peut accuser rapidement réception des écritures sync, puis laisser les vdevs principaux absorber le travail en masse de manière asynchrone.

Voici le piège : le SLOG n’aide que les écritures synchrones. Si votre charge est principalement composée d’écritures asynchrones — mise en mémoire tampon de bases de données, ingestion en flux, copies séquentielles volumineuses, tâches de sauvegarde — le SLOG ne peut rien faire, car ZFS n’attendait pas le ZIL pour avancer.

Une chose de plus : un périphérique SLOG n’est pas un cache d’écriture au sens où beaucoup l’entendent. Le SLOG ne « retient pas toutes les écritures ». Il contient une fenêtre glissante d’opérations sync récemment acquittées, typiquement des secondes d’activité, jusqu’à ce qu’elles soient engagées dans le pool principal. Si le système plante, ZFS rejoue ces enregistrements du ZIL lors de l’import. Si le SLOG ment sur la durabilité, vous découvrirez l’archéologie des données.

Blague n°1 (obligatoire, et méritée) : Acheter un SLOG pour une charge asynchrone, c’est comme installer une sortie de secours dans une piscine — techniquement impressionnant, opérationnellement sans rapport.

Faits intéressants et brève histoire

Points de contexte courts et concrets qui vous aident à raisonner sur ce que vous touchez :

ZFS est né à une époque d’« ordres d’écriture trompeurs ». Les piles de stockage reconnaissaient historiquement les écritures avant qu’elles ne soient vraiment durables ; le ZIL existe pour fournir des sémantiques correctes aux applications qui l’exigent.
Le ZIL n’est pas un journal de système de fichiers journalisé. Il est plus proche d’un journal d’intention pour des opérations synchrones récentes, pas d’un journal complet de métadonnées rejouant tout l’état du système de fichiers.
Le SLOG est devenu un sujet courant lorsque les exportations NFS se sont répandues. Les clients NFS (en particulier pour les VM) émettent souvent beaucoup d’écritures sync ou les forcent via des options de montage/export, transformant la latence en un événement coûteux.
Les premiers SSD étaient rapides mais malhonnêtes. De nombreux SSD grand public accusaient les flushs rapidement mais ne persistaient pas réellement les données en cas de perte d’alimentation ; c’est pourquoi la protection contre les pertes d’alimentation (PLP) est devenue le test décisif pour un SLOG.
Le timing des TXG façonne tout. ZFS regroupe les changements en groupes de transactions ; l’intervalle de commit par défaut (souvent autour de 5 secondes) explique pourquoi le SLOG n’a pas besoin d’être volumineux.
Des types de vdev spéciaux ont évolué. ZFS a introduit des rôles de vdev dédiés (log, cache, special, dedup). Le SLOG est l’un des rôles de vdev « séparés » les plus anciens et aussi l’un des plus mal compris.
Certaines marques ont livré un « SLOG dans une boîte ». Des appliances de stockage ont commercialisé des dispositifs NVRAM ou des journaux miroir dédiés parce que l’accusé de réception à faible latence se vend bien auprès des acheteurs de VM et de bases de données.
« sync=disabled » est la lettre écarlate des post-mortems. Les équipes redécouvrent sans cesse que la performance que vous « gagnez » en mentant aux applications peut devenir une perte de données que vous ne pouvez pas expliquer aux auditeurs.

Quand un SLOG aide, quand il est inutile, quand il est dangereux

Quand un SLOG aide

Un SLOG aide lorsque votre goulot d’étranglement est la latence d’écriture synchrone. Pas le débit. Pas les IOPS de lecture. Pas la mathématique RAIDZ. La latence pour les opérations qui doivent être engagées avant que l’appelant ne continue.

Cas classiques :

NFS pour virtualisation (disques VM via NFS). Les systèmes invités appellent fsync. Les hyperviseurs peuvent être friands de sync. Le résultat est une pluie continue de petites écritures sync.
Bases de données configurées pour une forte durabilité (ou effectuant explicitement fsync au commit). Si la base de données est sur ZFS et que le dataset est chargé en sync, un bon SLOG peut réduire les pics de latence des commits.
Applications utilisant O_DSYNC / O_SYNC ou des appels fsync fréquents (journaleurs soucieux, files d’attente de messages, certains systèmes CI effectuant des opérations de fichiers paranoïaques).
Charges dominées par de petites écritures aléatoires synchrones où vos vdevs principaux sont des HDD ou des SSD occupés et ne peuvent pas fournir une latence basse et constante.

Ce que vous remarquerez quand le SLOG est la bonne solution : le système n’est pas « lent partout ». Il est lent spécifiquement aux points de sync. Le CPU va bien. L’ARC va bien. Les lectures vont bien. Mais les transactions bouchonnent. Les percentiles de latence sont moches. Les utilisateurs décrivent des « accrocs » plutôt qu’une lenteur continue.

Quand un SLOG est inutile

Le SLOG est inutile lorsque votre charge est majoritairement asynchrone, ou lorsque le vrai goulot est ailleurs.

Écritures séquentielles massives (sauvegardes, ingestion média, copies de gros fichiers). ZFS mettra en mémoire et vidangera lors des TXG ; le SLOG n’est pas sur le chemin critique.
Charges orientées lecture. Le SLOG n’a rien à voir avec les lectures. C’est l’ARC/L2ARC et la disposition des vdevs.
Compression, checksum ou chiffrement limitées par CPU. Si vous surchargez les cœurs avec zstd ou AES, un SLOG ne les débloquera pas.
NFS/SMB lié au réseau. Si vos NIC sont saturées, un SLOG est une manière coûteuse de rester saturé.
Pools déjà à faible latence (miroirs tout-NVMe avec beaucoup de marge). Parfois le pool est déjà plus rapide que la cadence de sync de votre appli ; ajouter un journal ajoute de la complexité sans bénéfice.

Un mode d’échec courant : quelqu’un voit « latence d’écriture » et suppose SLOG. Mais les écritures sont asynchrones, ou la latence vient d’une pression TXG due à des contraintes mémoire, ou d’un disque lent dans un vdev RAIDZ. Le SLOG ne corrige pas la physique ; il change seulement l’endroit où les enregistrements sync sont écrits.

Quand un SLOG est dangereux

Le SLOG devient dangereux lorsqu’il devient un point unique de défaillance pour les écritures synchrones acquittées ou lorsqu’il vous tente de mentir sur la durabilité.

Situations à risque :

Utiliser un SSD grand public sans PLP comme SLOG. Il peut accuser réception d’un flush, puis perdre les dernières secondes d’écritures en cas de perte d’alimentation. ZFS rejouera fidèlement ce qu’il a ; la partie manquante devient votre problème.
Utiliser un SLOG mono-disque dans un système où la perte du journal est inacceptable. Si le SLOG meurt d’une manière qui perd des enregistrements ZIL en vol, vous pouvez perdre des écritures synchrones déjà reconnues aux clients.
Mal utiliser les réglages sync (par ex., sync=disabled) pour « récupérer de la performance ». Ce n’est pas tant « dangereux » que « réducteur de carrière à terme ».
Trop de confiance dans un SLOG mirrroré. Le miroir protège contre la défaillance d’un périphérique, mais il n’ajoute pas magiquement la protection contre la perte d’alimentation ni ne corrige un comportement de flush défectueux.
Ajouter un SLOG pour masquer un pool sous-dimensionné. Si vos vdevs principaux ne peuvent pas suivre les commits TXG éventuels, le SLOG peut réduire la latence apparente tout en poussant le pool dans un arriéré. Cet arriéré finit par une falaise.

Blague n°2 : Un SLOG sans protection contre la perte d’alimentation, c’est comme un parachute en dentelle — élégant, léger, et la dernière chose que vous voulez découvrir est « principalement décoratif ».

Comment fonctionnent vraiment ZIL, SLOG, TXGs et les écritures sync

Pour utiliser un SLOG en toute confiance, vous avez besoin du modèle mental. Voici celui qui survit aux incidents.

Écritures asynchrones : le chemin heureux

La plupart des écritures sont asynchrones. L’appli écrit ; l’OS transmet les données à ZFS ; ZFS place les changements en mémoire (ARC et autres structures en mémoire) et les écrit plus tard sur disque lors d’un commit de groupe de transactions. ZFS regroupe le travail pour être efficace : moins de seeks, plus d’écritures en flux, meilleure compression, meilleur checksum, meilleur débit global.

Pour les écritures asynchrones, l’accusé de réception ne nécessite pas de stockage durable. C’est pourquoi le SLOG est hors sujet : ZFS n’attendait pas une écriture ZIL pour que l’application continue.

Écritures synchrones : « Je veux que ça survive à un crash »

Les écritures synchrones (ou les opérations nécessitant un commit synchrone) sont différentes. L’appli dit « ne me dis pas que c’est écrit tant que c’est sûr ». ZFS doit fournir un point de persistance. Il ne peut pas attendre un commit TXG complet pour chaque fsync — les performances seraient catastrophiques — donc il écrit un enregistrement de log décrivant les changements dans le ZIL. Une fois que l’enregistrement ZIL est en sécurité sur un stockage stable, ZFS peut accuser réception de l’opération sync.

Plus tard, quand le TXG commit, les blocs réels sont écrits à leurs emplacements finaux dans le pool, et les enregistrements ZIL correspondants deviennent obsolètes. Le ZIL n’est pas un journal permanent ; c’est un livre de promesses à court terme.

Où vit le ZIL sans SLOG

Sans périphérique de log séparé, le ZIL vit sur les vdevs principaux du pool. Cela signifie que les écritures sync concourent avec tout le reste : écritures normales, lectures, scrubs, resilvers, travail métadata. Sur disques rotatifs, c’est souvent catastrophique pour la latence : la tête recherche pour écrire un petit enregistrement, puis revient pour continuer un travail séquentiel, et vous venez d’inventer de l’I/O aléatoire au milieu d’un pipeline séquentiel.

Ce que change un SLOG

Ajouter un SLOG déplace les écritures ZIL vers un périphérique dédié, typiquement à faible latence. Désormais les écritures sync frappent le SLOG, sont acquittées rapidement, et le pool principal continue son batching TXG en grande partie sans être dérangé. Le pool doit toujours écrire les données réelles lors des commits TXG. Le SLOG ne supprime pas la charge d’écriture sous-jacente ; il découple la latence d’accusé de réception du débit d’engagement en masse.

Pourquoi la taille du SLOG est généralement petite

Les enregistrements ZIL n’ont à couvrir que la fenêtre entre un acquittement sync et le prochain commit TXG réussi qui inclut les données correspondantes. En état stable, ce sont des secondes, pas des heures. C’est pourquoi la plupart des périphériques SLOG peuvent être petits en capacité mais doivent être excellents en latence et sécurité électrique.

Que se passe-t-il en cas de crash ou perte d’alimentation

Si le système plante, ZFS importe le pool et rejoue les enregistrements ZIL pour ramener le système de fichiers à un état cohérent par rapport aux opérations sync acquittées. Si le périphérique SLOG détenait ces enregistrements et qu’il est présent et cohérent, vous obtenez la correction et un délai d’import modeste selon la quantité à rejouer.

Si le périphérique SLOG est manquant ou mort, le comportement dépend de ce qui s’est précisément passé et de la manière dont le vdev de log a échoué. Au mieux : ZFS peut revenir sur le pool et vous ne perdez pas d’écritures sync acquittées car elles avaient déjà été commit (ou le périphérique de log est tombé proprement). Au pire : vos clients se sont vu dire « vos données sont sûres » et ce n’est pas le cas. C’est pourquoi les périphériques SLOG doivent être traités comme des composants de durabilité, pas des gadgets de performance.

Deux réglages que vous verrez : `sync` et `logbias`

sync est une propriété de dataset qui influence la manière dont ZFS traite les requêtes demandant un comportement synchrone. Elle a des valeurs comme standard (par défaut), always et disabled. Elles ne changent pas ce que l’appli demande ; elles changent la manière dont ZFS y répond. Si vous mettez sync=disabled, vous choisissez de mentir aux applications qui ont demandé de la durabilité.

logbias est une propriété de dataset qui peut être latency (par défaut) ou throughput. Elle influence la manière dont ZFS utilise le journal pour certaines charges. La mal régler peut annuler un SLOG ou déplacer le travail de façons inattendues. Ce n’est pas un bouton magique « rendre le SLOG plus rapide » ; c’est un indice sur ce qui compte pour vous.

Ce qui fait un bon périphérique SLOG (et ce qui en fait un mauvais)

Les vraies exigences : cohérence de la latence et durabilité honnête

Un bon périphérique SLOG a :

Faible latence pour les petites écritures sync (surtout avec une variabilité de profondeur de file élevée).
Protection contre la perte d’alimentation (PLP) pour que les écritures acquittées survivent à une panne de courant subite.
Comportement correct de flush/FUA. ZFS compte sur le périphérique pour respecter correctement les barrières/flushes.
Endurance suffisante pour des charges sync soutenues.
Performance prévisible sous stress (collecte des ordures et throttling thermique sont les tueurs silencieux de « ça a benchmarké correctement »).

Un mauvais périphérique SLOG est généralement « rapide sur le papier » mais sans PLP ou avec un firmware qui traite le flush comme une suggestion. Le NVMe grand public peut être extrêmement rapide pour les écritures asynchrones et rester risqué pour la durabilité sync s’il utilise des caches d’écriture volatils sans protection. Le chemin SLOG est allergique aux mensonges.

Mirroring du SLOG : quand cela importe

Si vous ne pouvez pas tolérer de perdre des écritures sync acquittées à cause d’une défaillance d’un seul périphérique, miroitez le SLOG. C’est courant en milieu professionnel où les exportations NFS supportent des datastores VM et où un seul enregistrement de log perdu devient une histoire de corruption du système de fichiers VM.

Le mirroring n’est pas une option « ceinture et bretelles » si l’attente métier est « les écritures sync sont sûres ». C’est une partie de rendre le périphérique journal aussi fiable que le reste de votre architecture de stockage.

Mais ne confondez pas miroir et sécurité

Deux périphériques non sûrs en miroir créent une manière redondante d’avoir tort. Si les deux périphériques accusent réception du flush sans persistance, vous pouvez perdre des données deux fois plus sûrement. La propriété non négociable est la protection contre la perte d’alimentation et l’ordre d’écriture correct.

N’en dépensez pas trop en capacité

La capacité du SLOG est rarement le facteur limitant. Ce qui compte, c’est la performance et la sécurité. Si vous achetez un NVMe « gaming » de 2 To comme périphérique de journal, vous avez acheté la mauvaise chose de façon coûteuse. Un SSD d’entreprise plus petit avec PLP est généralement la bonne réponse.

Placement et topologie comptent

Placer le SLOG derrière un HBA défaillant, un expander déjà saturé, ou un contrôleur avec des astuces de cache d’écriture peut effacer ses bénéfices. Le SLOG est sur le chemin sync ; le chemin sync doit être ennuyeux et déterministe.

Tâches pratiques : commandes, sorties et interprétation

Voici les commandes que vous lancez vraiment quand quelqu’un dit « ZFS est lent » et que vous devez prouver quelle partie est lente. Chaque tâche inclut une commande et quoi chercher. Ajustez les noms de pool/dataset à votre environnement.

Task 1: Confirm whether a SLOG exists and how it’s configured

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:32:10 with 0 errors on Wed Dec 18 03:12:20 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

errors: No known data errors

Interprétation : Cherchez une section logs. Si elle manque, vous n’avez pas de vdev de log séparé. Si elle existe, notez si elle est miroir. Notez aussi si le vdev de log montre des erreurs ; un SLOG malade est un risque de correction.

Task 2: Verify dataset sync behavior (the single most important property here)

cr0x@server:~$ sudo zfs get -o name,property,value,source sync tank/vmstore
NAME          PROPERTY  VALUE     SOURCE
tank/vmstore  sync      standard  default

Interprétation : standard signifie que ZFS respecte les demandes de sync de l’application. always force les sémantiques sync (plus durable, souvent plus lent). disabled est le mode « rapide et fragile ».

Task 3: Check `logbias` because it changes the log behavior

cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/vmstore
NAME          PROPERTY  VALUE    SOURCE
tank/vmstore  logbias   latency  default

Interprétation : latency est typiquement correct pour les charges VM et bases de données. throughput peut réduire le logging dans certains cas mais peut augmenter la latence sync ou changer les motifs. Traitez les changements ici comme des changements de production, car ils en sont.

Task 4: Identify whether clients are forcing sync (common with NFS)

cr0x@server:~$ sudo zfs get -o name,property,value,source sync tank/nfs
NAME      PROPERTY  VALUE     SOURCE
tank/nfs  sync      standard  local

Interprétation : Si vous voyez sync=always sur un dataset NFS, attendez-vous à une forte dépendance au SLOG. Si vous voyez sync=disabled, attendez-vous à retrouver le mot « corruption » dans le postmortem.

Task 5: Watch ZFS I/O in real time and see if the log device is active

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        1.20T  2.40T     50    900  3.2M  85.0M
  mirror-0                  1.20T  2.40T     50    520  3.2M  42.0M
    ata-HDD_A               -      -         25    260  1.6M  21.0M
    ata-HDD_B               -      -         25    260  1.6M  21.0M
logs                          -      -        0    380    0  14.0M
  mirror-1                    -      -        0    380    0  14.0M
    nvme-INTEL_SLOG_A         -      -        0    190    0   7.0M
    nvme-INTEL_SLOG_B         -      -        0    190    0   7.0M
--------------------------  -----  -----  -----  -----  -----  -----

Interprétation : Si votre charge est sync-heavy, vous devriez voir des opérations d’écriture sur le vdev logs. Si les logs montrent zéro pendant que les applis se plaignent de latence fsync, vous n’avez peut-être pas affaire à des écritures sync du tout — ou le dataset n’utilise pas le SLOG comme vous le pensez.

Task 6: Check overall pool latency and per-vdev behavior (spot the slow disk)

cr0x@server:~$ sudo zpool iostat -v -l tank 5
                              capacity     operations     bandwidth    total_wait  disk_wait
pool                        alloc   free   read  write   read  write    ---------  ---------
tank                        1.20T  2.40T     80   1100  5.1M  95.0M      18ms       12ms
  mirror-0                  1.20T  2.40T     80    650  5.1M  48.0M      22ms       16ms
    ata-HDD_A               -      -         40    325  2.6M  24.0M      18ms       12ms
    ata-HDD_B               -      -         40    325  2.6M  24.0M      27ms       20ms
logs                          -      -        0    450    0  18.0M       1ms        1ms
  mirror-1                    -      -        0    450    0  18.0M       1ms        1ms
    nvme-INTEL_SLOG_A         -      -        0    225    0   9.0M       1ms        1ms
    nvme-INTEL_SLOG_B         -      -        0    225    0   9.0M       1ms        1ms

Interprétation : Ceci montre le temps d’attente. Si un disque a un disk_wait significativement plus élevé, il peut ralentir le vdev et le pool. Un SLOG ne guérira pas un vdev malade qui ne peut pas engager les TXG assez vite.

Task 7: Confirm whether sync writes are being generated at all (use a quick fsync micro-test)

cr0x@server:~$ cd /tank/vmstore
cr0x@server:/tank/vmstore$ sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:/tank/vmstore$ /usr/bin/time -f "elapsed=%e sec" bash -c 'dd if=/dev/zero of=./fsync.test bs=4k count=4096 conv=fdatasync'
4096+0 records in
4096+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.42 s, 40.0 MB/s
elapsed=0.42 sec

Interprétation : conv=fdatasync force un sync à la fin. Exécutez ceci avec et sans SLOG (ou sur un hôte comparable). Si vous ne voyez pas d’amélioration, soit le pool est déjà rapide en sync, soit vous êtes limité ailleurs (CPU, réseau, pression TXG).

Task 8: Observe TXG behavior and look for commit pressure (Linux OpenZFS)

cr0x@server:~$ grep -E "txg|zil" /proc/spl/kstat/zfs/arcstats | head
txg_sync                       4    0
txg_quiesce                    4    0
txg_wait_synced                4    0
zil_commit                     4    0

Interprétation : Les compteurs varient selon la version, mais si vous voyez beaucoup de temps d’attente pour que les TXG se synchronisent (ou pour les commits ZIL), votre problème peut être « le pool ne peut pas vidanger assez vite », pas « le SLOG manque ». En production, utilisez votre pipeline de télémétrie habituel ; ceci est la vue « je suis sur la machine maintenant ».

Task 9: Check if the log device is actually fast at flushes (basic device health)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPED1D280GA
Serial Number:                      BTKA1234567F280G
Firmware Version:                   EDF1470C
NVMe Version:                       1.3
...
Critical Warning:                   0x00
Temperature:                        36 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Written:                 134,221 [68.7 GB]

Interprétation : Vous cherchez un périphérique sain avec une faible usure média. Le SLOG peut subir une pression d’écriture soutenue ; les périphériques grand public peuvent s’user rapidement dans des environnements sync-heavy.

Task 10: Add a mirrored SLOG safely (example)

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SLOG_A /dev/disk/by-id/nvme-INTEL_SLOG_B
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme-INTEL_SLOG_A       ONLINE       0     0     0
            nvme-INTEL_SLOG_B       ONLINE       0     0     0

Interprétation : Utilisez des chemins de périphériques stables (/dev/disk/by-id) afin qu’un redémarrage ne réordonne pas les noms. Après l’ajout, surveillez zpool iostat pour confirmer que la charge l’utilise.

Task 11: Remove a SLOG (and what “safe” looks like)

cr0x@server:~$ sudo zpool remove tank mirror-1
cr0x@server:~$ sudo zpool status tank | sed -n '1,35p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-HDD_A               ONLINE       0     0     0
            ata-HDD_B               ONLINE       0     0     0

errors: No known data errors

Interprétation : La suppression du vdev de log est supportée sur OpenZFS moderne. Faites-le pendant une fenêtre calme ; surveillez la latence client. Si la performance s’effondre, vous avez confirmé que la charge est sensible au sync.

Task 12: Identify “sync storms” from NFS or VM workloads

cr0x@server:~$ sudo nfsstat -s | sed -n '1,25p'
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
214748     0          0          0          0

Server nfs v4:
null       compound
0          198322

Server nfs v3:
null       getattr    setattr    lookup     access     readlink
0          4123       1882       22091      7851       0
read       write      create     mkdir      symlink    mknod
70221      88011      312        12         0          0
commit     remove     rename     link       readdir    readdirplus
65002      401        33         0          112        909

Interprétation : Beaucoup d’appels NFS commit peuvent se corréler avec une pression sync. Associez ceci à zpool iostat pour voir si le SLOG absorbe les écritures de log ou si les vdevs principaux prennent le coup.

Task 13: Validate whether the dataset is accidentally forcing sync

cr0x@server:~$ sudo zfs get -r -o name,property,value,source sync tank | sed -n '1,30p'
NAME            PROPERTY  VALUE     SOURCE
tank            sync      standard  default
tank/nfs        sync      always    local
tank/vmstore    sync      standard  default
tank/backups    sync      standard  default

Interprétation : Un seul dataset avec sync=always peut dominer la performance perçue du pool. Parfois c’est correct ; parfois c’est une configuration héritée d’un post forum d’il y a des années.

Task 14: Spot a pool that’s falling behind on TXG commits (classic backpressure)

cr0x@server:~$ sudo zpool iostat tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.20T  2.40T     40   2200  2.4M  240M
tank        1.20T  2.40T     35   2400  2.1M  260M
tank        1.20T  2.40T     38   2600  2.3M  280M

Interprétation : Un débit d’écriture soutenu élevé n’est pas intrinsèquement mauvais, mais si les applications bloquent sur sync pendant que le débit est élevé, cela peut indiquer que les TXG prennent plus de temps à synchroniser (pression de données sales), et vous approchez du point où ZFS doit restreindre. Un SLOG peut masquer le début de ce problème pendant que le pool accumule silencieusement du travail.

Méthode de diagnostic rapide

Voici la séquence « j’ai 10 minutes avant que l’appel d’incident ne tourne au rituel de blâme ». Vous essayez de répondre à une question : Le goulot est-il la latence sync, ou autre chose ?

Première étape : déterminer si la charge est sync-heavy

Vérifiez les propriétés du dataset : zfs get sync,logbias <dataset>.
Surveillez l’activité du vdev de log : zpool iostat -v <pool> 1. Si le vdev de log est inactif pendant la « douleur sync », le SLOG n’est pas sur le chemin.
Cherchez le comportement client (appels NFS commit, taux de fsync de la base, motifs de stockage VM). Si vous ne pouvez pas observer l’appli, observez au moins le côté serveur : stats NFS, iostat, latence.

Deuxième étape : si c’est sync-heavy, décidez si le SLOG est le goulot

Utilisez la latence par vdev : zpool iostat -v -l <pool> 5. Si le vdev de log a un wait plus élevé que prévu, il ne fait pas son travail.
Vérifiez la santé et les erreurs du périphérique : zpool status -v et smartctl.
Confirmez que le périphérique de log n’est pas derrière un chemin plus lent (lignes PCIe partagées, HBA saturé, multipath mal configuré).

Troisième étape : si le SLOG semble OK, le chemin de commit du pool est probablement le goulot

Vérifiez la latence des vdevs principaux dans zpool iostat -l. Un HDD lent, un SSD mourant, ou un vdev en reconstruction dominera.
Cherchez le travail en arrière-plan : scrub, resilver, snapshots lourds, send/recv, saturation CPU par compression/chiffrement.
Vérifiez la pression mémoire : si la machine manque de RAM ou que l’ARC est contraint, ZFS peut atteindre des limites de données sales et fortement throttler.

Quatrième étape : décidez quoi changer (par ordre de priorité)

Si sync-heavy et pas de SLOG : ajoutez un SLOG PLP mirroir approprié.
Si sync-heavy et SLOG présent mais de qualité grand public : remplacez-le.
Si le chemin de commit est lent : corrigez la disposition des vdevs, retirez le disque lent, ajoutez des miroirs, réduisez la largeur RAIDZ pour les charges IOPS, ou scalez horizontalement.
Si le problème vient de « quelqu’un a forcé le sync partout » : ajustez les réglages du dataset/export/appli avec une position claire sur la durabilité.

Trois mini-histoires du monde de l’entreprise

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Le ticket était formulé poliment : « Corruption intermittente du système de fichiers VM lors d’événements d’alimentation. » L’équipe stockage a d’abord été sur la défensive — personne n’aime qu’on lui dise que sa plateforme mange des données — mais le motif était trop propre. Cela n’arrivait qu’après un redémarrage brutal des PDU du rack pendant des tests de maintenance. Les redémarrages normaux allaient bien.

L’environnement était un datastore NFS basé sur ZFS pour un cluster d’hyperviseurs. Ils avaient un périphérique SLOG, et ils en étaient fiers. « On a acheté du NVMe, c’est rapide », disaient-ils, ce qui est la première phrase de nombreux postmortems. Le SLOG était un simple NVMe grand public parce que « c’est juste un journal ». Le pool lui-même était des miroirs de HDD, tout à fait respectables pour la capacité et généralement corrects pour le débit, mais la latence sync était leur point douloureux, donc le SLOG semblait le bon levier.

Après quelques reproductions et un silence inconfortable, la leçon est apparue : le NVMe accusait réception des flushs rapidement mais ne persistait pas de manière fiable les derniers instants d’écritures lors d’une coupure brutale de courant. Les hyperviseurs avaient été assurés que « vos commits sont sûrs », parce que le protocole NFS et les systèmes de fichiers invités comptent sur cette promesse. Puis le serveur a perdu l’alimentation. À l’import, ZFS a rejoué ce qu’il avait dans le journal. Ce qu’il n’avait pas, c’était le dernier bit que le périphérique avait prétendu être durable.

La correction n’a pas été héroïque. Ils ont remplacé le SLOG par un périphérique d’entreprise avec PLP et l’ont miroré, car ils ne voulaient pas qu’un seul composant soit l’axe « oups ». Ils ont aussi arrêté de dire « c’est juste un journal ». Dans ZFS, le journal fait partie de votre contrat de durabilité.

Ce qui a changé opérationnellement était plus important que le matériel : ils ont documenté ce que « sync safe » signifiait pour leurs exports NFS, ajouté la simulation de panne d’alimentation aux tests d’acceptation, et écrit une fiche de procédure commençant par « Confirmer que le SLOG a PLP. ». Les incidents de corruption ont cessé, et la seule chose qu’ils ont perdue était l’illusion que les pièces de performance peuvent être traitées comme des accessoires.

Mini-histoire n°2 : L’optimisation qui s’est retournée

Une application liée à la finance avait des rafales périodiques : fin de mois, fin de trimestre, fin d’année — la sainte trinité du « pourquoi c’est lent aujourd’hui ? ». Elle tournait sur des VM via NFS supportées par ZFS. Pendant les pics, la latence explosait et l’appli expirait. Quelqu’un a découvert que mettre sync=disabled rendait les graphiques magnifiques. Ils l’ont déployé rapidement, car le business criait et le changement était réversible. Pour être juste, ça a fonctionné. Ça a aussi posé une mine.

Le retour de bâton est arrivé quelques semaines plus tard sous la forme de « on a rebooté après des mises à jour du kernel et les dernières minutes de transactions de l’appli manquent. » Pas corrompu. Pas partiellement écrit. Juste manquant. La base avait émis des écritures sync au commit, le stockage a menti et l’univers a encaissé sa dette au prochain crash.

L’équipe a essayé d’arguer que la fenêtre manquante était petite. Mais la définition métier de « petit » est « aucun », surtout quand des auditeurs existent. Plus subtilement, ils ont réalisé qu’ils avaient entraîné l’équipe appli à supposer que « le stockage est rapide maintenant », donc ils ont augmenté la concurrence et réduit les retries. Quand ils sont revenus aux sémantiques sync correctes, la falaise de performance était plus sévère qu’avant parce que d’autres réglages avaient été modifiés entre-temps.

La correction à long terme a été ennuyeuse : un vrai SLOG mirroiré, avec PLP, dimensionné correctement, plus des changements dans l’appli pour grouper les commits de façon plus intelligente. Ils ont aussi défini des SLO explicites pour la latence de commit et mesuré les taux de fsync afin que le « sync » ne soit plus une propriété mystique. L’optimisation ne s’est pas contentée de se retourner — elle a endommagé la compréhension institutionnelle, et ils ont dû la reconstruire.

La leçon opérationnelle : si vous « optimisez » en changeant la correction, vous n’avez pas optimisé ; vous avez emprunté du temps à intérêt variable. ZFS vous permet de le faire. ZFS vous permettra aussi de l’expliquer plus tard.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Un cluster de stockage était en expansion. Rien de dramatique : ajouter des étagères, ajouter des vdevs, rééquilibrer les charges avec le temps. L’équipe avait un rituel : après tout changement matériel, ils lançaient une suite de vérification courte — contrôles d’état du pool, une sonde de latence d’écriture sync, et une charge client simulée produisant un flux constant de fsync. Ça prenait 20 minutes et tout le monde s’en plaignait jusqu’au jour où ça a servi.

Pendant l’expansion, la latence sync a doublé discrètement. Pas assez pour déclencher immédiatement des alertes, mais suffisant pour apparaître comme des pics de latence tail dans les opérations VM. La suite de vérification ennuyeuse l’a détecté. L’équipe a comparé les résultats avec la baseline et a vu que le vdev de log affichait maintenant des temps d’attente plus élevés que d’habitude.

Le coupable n’était pas ZFS du tout. Une mise à jour de firmware sur le backplane PCIe du nouveau serveur avait changé la négociation de lien, et le slot NVMe prévu pour le SLOG fonctionnait avec une largeur de voies réduite. Le SLOG était toujours « rapide » dans les tests de débit, car les chiffres séquentiels sont beaux, mais sa latence sous charges flush-heavy avait dégradé, ce qui est la seule chose pour laquelle le SLOG est payé.

Ils ont déplacé les périphériques SLOG vers d’autres emplacements, confirmé la largeur de voie, relancé la sonde de latence, et les pics tail ont disparu. Pas d’incident, pas d’impact client, pas d’appel d’incident. Le seul artefact visible était une ligne dans le compte-rendu de changement : « Correction de la largeur de voie NVMe ; restauration de la baseline de latence sync. »

C’est ce à quoi ressemble la compétence en production : pas des actes héroïques, mais de petits tests qui vous évitent d’apprendre la négociation PCIe via des messages Slack en colère.

Erreurs courantes, symptômes et corrections

Cette section est écrite dans le langage des symptômes, car c’est ainsi que vous rencontrez le SLOG dans la vraie vie.

Mistake 1: Adding a SLOG and expecting faster bulk writes

Symptômes : Pas d’amélioration notable ; les jobs de sauvegarde restent lents ; le débit séquentiel inchangé ; le vdev de log montre peu d’activité.

Pourquoi : La charge est asynchrone. Le SLOG accélère uniquement les accusés de réception des écritures sync.

Correction : Retirez le SLOG s’il ajoute un risque sans bénéfice, ou gardez-le seulement si vous avez des charges sync non mesurées. Optimisez la disposition des vdevs, recordsize, compression, ou le réseau si la charge est du I/O massif.

Mistake 2: Using a consumer SSD/NVMe without PLP as SLOG

Symptômes : Corruption rare mais catastrophique ou transactions manquantes après une perte brutale d’alimentation ; les reboots propres vont bien ; l’import après crash est parfois plus lent ; incohérences post-crash.

Pourquoi : Le périphérique accuse réception des écritures et des flushs qui ne sont pas réellement persistants.

Correction : Remplacez par un périphérique d’entreprise avec PLP et comportement de flush éprouvé. Miroitez-le si vous avez besoin de disponibilité et pour réduire le risque de perte de log lors d’une défaillance matérielle.

Mistake 3: Single-disk SLOG for a workload that treats sync as sacred

Symptômes : Après défaillance du SLOG, les clients voient des erreurs I/O ou subissent un changement de performance disruptif ; exposition au risque autour des écritures acquittées ; anxiété lors des remplacements de périphérique.

Pourquoi : Le périphérique de log fait désormais partie du chemin de durabilité ; un point unique de défaillance est un pari.

Correction : Miroitez le SLOG. Gardez des pièces de rechange. Testez les procédures de remplacement. Si le mirroring n’est pas possible, repensez si la charge doit être sur cette architecture.

Mistake 4: Setting `sync=disabled` to make graphs green

Symptômes : Amélioration des performances suivie de données manquantes/corrompues après un crash ; les auditeurs s’intéressent à vos plans de week-end.

Pourquoi : Vous avez dit à ZFS d’accuser réception des écritures sync sans les rendre durables.

Correction : Rétablissez sync=standard (ou always si requis). Ajoutez un SLOG adéquat et/ou changez le comportement applicatif (batching, group commit) pour réduire la fréquence des fsync.

Mistake 5: Treating SLOG as a “cache” and oversizing it

Symptômes : Aucun bénéfice d’une grande capacité SLOG ; budget dépensé sans réduction mesurable de la latence.

Pourquoi : Le SLOG stocke une courte fenêtre d’enregistrements ZIL, pas toutes les écritures.

Correction : Dimensionnez pour la latence et la sécurité, pas pour la capacité. Investissez dans la qualité (PLP, endurance), pas les téraoctets.

Mistake 6: Ignoring the main pool’s ability to commit TXGs

Symptômes : La latence sync s’améliore initialement avec le SLOG, puis le système subit des blocages périodiques ; le débit semble correct mais les applis expirent ; « tout fige toutes les quelques secondes ».

Pourquoi : Le SLOG découple l’accusé de réception mais pas la nécessité éventuelle d’écrire les données dans le pool. Si le pool ne peut pas suivre, il va throttler.

Correction : Améliorez la performance d’écriture du pool (plus de vdevs, miroirs, disques plus rapides), réduisez l’amplification d’écriture (recordsize, compression), ou réduisez la pression de la charge. Le SLOG n’est pas un substitut à un débit d’engagement adéquat.

Mistake 7: Confusing L2ARC with SLOG

Symptômes : « On a ajouté un SLOG et les lectures sont toujours lentes. »

Pourquoi : Le SLOG est pour les accusés de réception des écritures synchrones. L2ARC est une extension de cache de lecture. Problèmes différents, outils différents.

Correction : Si les lectures sont lentes, examinez le taux de hit ARC, les propriétés du dataset, les IOPS de lecture des vdevs, et éventuellement L2ARC. N’achetez pas un périphérique de log pour un problème de lecture.

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

Checklist: Decide whether you need a SLOG at all

Mesurez l’intensité sync : Identifiez les applis fsync-heavy (bases de données, VM/NFS) et si elles sont réellement bloquées sur la latence sync.
Observez l’activité du journal : Si vous avez déjà un SLOG, vérifiez qu’il est utilisé. Si vous n’en avez pas, estimez le bénéfice potentiel en mesurant la latence fsync actuelle.
Écartez les goulots évidents : Saturation réseau, saturation CPU, scrub/resilver, ou un disque unique défaillant peuvent dominer les symptômes.
Décidez de la position sur la durabilité : Confirmez que vous avez besoin des sémantiques sync correctes. Si non, documentez-le explicitement ; ne fonctionnez pas « accidentellement » en mode non sécurisé.

Checklist: Choose the right SLOG device

PLP est obligatoire : Choisissez des périphériques avec protection contre la perte d’alimentation et un comportement firmware d’entreprise.
Privilégiez la faible latence plutôt que la grande capacité : Votre objectif est une latence de flush rapide et constante.
Vérifiez l’endurance : Les charges sync-heavy peuvent écrire en continu ; assurez-vous que TBW/DWPD sont appropriés.
Évitez les falaises de performance : Testez sous charge soutenue ; surveillez le throttling thermique ou les pics de GC.
Miroitez si la correction importe : Particulièrement pour les datastores VM NFS et les bases critiques.

Step-by-step plan: Add a SLOG safely in production

Baseline d’abord : Capturez les percentiles de latence depuis votre monitoring et lancez un petit test fsync sur le dataset.
Confirmez les chemins de périphérique : Identifiez les périphériques de log via /dev/disk/by-id pour éviter les problèmes de renommage.
Ajoutez un journal mirroir : Utilisez zpool add POOL log mirror DEV1 DEV2.
Validez l’usage : Pendant la charge sync de pointe, vérifiez les écritures sur le vdev de log avec zpool iostat -v.
Re-baseline : Exécutez le même test fsync ; comparez les distributions de latence, pas seulement les moyennes.
Documentez le contrat : Enregistrez que « les écritures sync sont durables et protégées par un SLOG PLP mirroir », et notez les procédures de remplacement.

Step-by-step plan: If you suspect SLOG is hurting you

Vérifiez les erreurs : zpool status -v et les stats SMART.
Vérifiez la latence du log : zpool iostat -v -l POOL 5. Si le wait sur le log est élevé, vous avez un problème.
Considérez une suppression temporaire : Dans une fenêtre contrôlée, zpool remove POOL LOGVDEV et mesurez le comportement. C’est diagnostique, pas un plan permanent.
Remplacez par du bon matériel : Si vous confirmez que le SLOG est le goulot, remplacez-le par un périphérique conçu pour les charges sync.

FAQ

1) Does adding a SLOG make ZFS writes faster?

Uniquement les écritures synchrones. Il améliore la latence des opérations qui doivent être reconnues comme durables (fsync, O_SYNC, motifs NFS commit-heavy). Il n’augmente pas, à lui seul, le débit d’écritures asynchrones en masse.

2) Is SLOG the same thing as ZIL?

Non. Le ZIL est le mécanisme et existe dans chaque pool. Le SLOG est un périphérique séparé où les enregistrements ZIL sont stockés pour améliorer la latence des écritures synchrones.

3) How big should a SLOG be?

Généralement petit. Vous stockez une courte fenêtre glissante d’intention d’écriture sync jusqu’aux commits TXG. La taille est rarement la contrainte ; la latence et la sécurité électrique le sont.

4) Should I mirror my SLOG?

Si vous tenez à ne pas perdre les écritures sync acquittées à cause d’une défaillance d’un seul périphérique, oui. Pour les datastores VM via NFS et les bases critiques, le SLOG mirroir est un choix courant « correct par conception ».

5) Can a SLOG reduce write amplification on the main pool?

Pas vraiment. Il change l’endroit où l’intention de sync est enregistrée, pas la quantité de données que le pool doit finalement écrire. Il peut rendre le pattern I/O du pool moins chaotique en retirant les petites écritures sync des vdevs principaux, ce qui peut aider indirectement, mais il n’efface pas la charge.

6) What’s the difference between SLOG and L2ARC?

Le SLOG accélère les accusés de réception des écritures synchrones. L2ARC est un cache de lecture secondaire. Les confondre est courant et coûteux.

7) Is `sync=disabled` ever acceptable?

Seulement si vous acceptez de perdre des transactions récentes lors d’un crash et que vous avez explicitement accepté ce risque (et l’avez documenté). Beaucoup de charges « scratch » internes peuvent vivre avec. La plupart des bases de production et des datastores VM ne devraient pas.

8) Why did my performance get worse after adding a SLOG?

Causes courantes : le périphérique de log a une mauvaise latence de flush, il throttle thermiquement, il est derrière un chemin contrôleur contraint, ou la charge n’était pas sync-heavy et vous avez juste ajouté de la surcharge/complexité. Mesurez la latence du vdev de log avec zpool iostat -l et validez que les écritures sync l’utilisent effectivement.

9) Can I partition a device and use part of it as SLOG?

Techniquement possible, mais opérationnellement risqué sauf si vous êtes disciplinés. Les périphériques partagés peuvent créer de la contention et coupler les modes de défaillance. Le chemin sync veut de l’isolation et de la prévisibilité.

10) What dataset settings typically pair with a SLOG for VM/NFS?

Généralement sync=standard (ou always si votre environnement l’exige) et logbias=latency. Le reste dépend de la charge : recordsize, compression, atime, et les réglages d’export NFS importent, mais ils ne sont pas spécifiques au SLOG.

Conclusion

Un SLOG ZFS est un de ces composants qui ressemble à une mise à niveau simple jusqu’à ce que vous compreniez ce qu’il améliore réellement : une frontière de correction. Lorsque votre charge est sync-heavy, un SLOG approprié peut être transformateur, en particulier pour la virtualisation backée par NFS et les bases de données à commits lourds. Lorsque votre charge est asynchrone, c’est du poids mort. Et lorsque vous choisissez le mauvais périphérique — ou que vous utilisez le bon périphérique de la mauvaise manière — cela devient une jolie façon de transformer « tuning de performance stockage » en « conversation de récupération de données ».

La règle opérationnelle est simple : mesurez d’abord, optimisez la bonne chose, et traitez le périphérique de journal comme une partie de votre histoire de durabilité, pas comme une quête annexe. Si vous faites cela, le SLOG sera ennuyeux dans le meilleur sens : il rendra silencieusement les écritures sync rapides, et rien d’excitant ne se produira.