Dimensionnement du SLOG ZFS : combien faut-il vraiment (non, « plus grand n’est pas mieux »)

Ce que fait réellement un SLOG (et ce qu’il ne fait pas)

Dans ZFS, le ZIL (ZFS Intent Log) est le mécanisme qui rend les écritures synchrones sûres. Si une application demande
qu’une écriture soit validée (« sync »), ZFS doit pouvoir rejouer cette écriture après un crash. Par défaut, ZFS stocke le
ZIL sur les disques du pool. Ça fonctionne, mais ça peut être lent car cela impose des E/S à faible latence et orientées petites écritures
aux mêmes vdevs qui font tout le reste.

Un SLOG (dispositif LOG séparé) est simplement un emplacement externe pour placer les enregistrements du ZIL. Il ne contient pas vos données à long terme.
Ce n’est pas un L2ARC. Ce n’est pas un levier magique « plus d’IOPS ». C’est un moyen de transformer la « latence des écritures synchrones » de « ce que votre pool
peut faire sous charge » en « ce que votre SLOG peut acquitter rapidement et en toute sécurité ».

Le modèle mental qui ne vous trahira pas à 3 h du matin

Pensez à une écriture synchrone en deux étapes :

1. ZFS reçoit l’écriture et a besoin d’une promesse durable avant de pouvoir ACKer au client.
2. ZFS écrit plus tard les blocs réels dans l’allocation normale du pool dans le cadre d’un commit de groupe de transaction (TXG).

Avec un SLOG, l’étape 1 devient « écrire un enregistrement de log sur le SLOG, flusher, ACK ». L’étape 2 se produit toujours sur le pool principal
lors du commit TXG. Le SLOG sert à rendre l’ACK rapide et sûr ; il n’accélère pas la majorité de vos écritures en régime permanent.

Si votre charge est majoritairement asynchrone (bases de données en write-back, copies en masse, ingestion média), le SLOG peut
ne presque rien faire. Si votre charge est très synchrone (NFS, iSCSI avec write barriers, images de VM sur NFS, bases de données avec durabilité stricte),
le SLOG peut faire la différence entre « ça va » et « arrêtez de m’envoyer des pages ».

Une idée paraphrasée de Werner Vogels (CTO d’Amazon) qui convient parfaitement au dimensionnement du SLOG : tout échoue ; concevez pour que l’échec soit un événement normal et contenu.
Votre conception SLOG doit partir du principe que le périphérique meurt, car il finira par le faire.

Faits intéressants et contexte historique

• ZFS a toujours eu un ZIL ; le SLOG est optionnel. Les premiers adopteurs blâmaient souvent ZFS pour une latence synchrone qui était en réalité « les disques qui font ce qu’ils savent faire ».
• Les commits TXG sont périodiques (souvent de l’ordre de quelques secondes), ce qui signifie que le ZIL est généralement de courte durée : c’est une zone de transit, pas de stockage.
• « SLOG » est un raccourci communautaire ; ZFS parle de « log vdev ». Le terme est resté parce que les ingénieurs stockage aiment les acronymes comme les chats aiment les boîtes.
• NFS a rendu le SLOG célèbre car de nombreux clients NFS par défaut utilisent une sémantique synchrone pour la sécurité, en particulier pour les datastores de VM et les activités riches en métadonnées.
• La protection contre la perte d’alimentation (PLP) est devenue la caractéristique déterminante des bons périphériques SLOG à mesure que les SSD sont devenus suffisamment rapides pour que la « latence » l’emporte sur le « débit » comme facteur limitant.
• Les premiers SSD grand public ont menti (parfois involontairement) sur le comportement de flush ; c’est pourquoi les conseils SLOG insistent beaucoup sur les disques d’entreprise avec PLP.
• Un SLOG est typiquement minuscule comparé à la taille du pool. Dans de nombreux systèmes de production, quelques dizaines de gigaoctets sont déjà généreux.
• Les SLOG en miroir sont devenus courants non pas parce que ZFS ne peut pas gérer la perte d’un SLOG (il le peut généralement), mais parce que les opérateurs détestent les temps d’arrêt évitables et les alertes effrayantes.
• NVMe a changé la conversation : ce n’est plus « peut-on rendre les écritures synchrones tolérables ? » mais « comment empêcher un périphérique rapide de masquer un pool lent et surchargé ? »

Règle de dimensionnement qui résiste à la production

Voici la vérité inconfortable : le dimensionnement du SLOG concerne presque jamais la capacité. Il s’agit de la latence,
de la durabilité et des schémas d’écriture. La capacité est la dernière case à cocher, et une petite.

Ce que vous dimensionnez réellement

Le SLOG doit être suffisamment grand pour contenir les enregistrements ZIL en attente qui ont été acquittés aux clients mais pas encore commités
sur le pool principal. Ces enregistrements sont libérés lorsque les TXG sync. Dans un système stable, le ZIL n’augmente pas indéfiniment ; il oscille.

Une formule de dimensionnement pratique ressemble à ceci :

Capacité SLOG nécessaire ≈ débit d’écriture synchrone soutenu de pointe × pire temps jusqu’au sync TXG + marge.

« Pire temps jusqu’au sync TXG » n’est pas juste une valeur de configuration ; c’est le temps que votre pool met pour terminer avec succès un TXG
sous charge. Si le pool est lent, fragmenté ou soumis à une charge pathologique, le sync TXG peut s’étirer.

Le chiffre avec lequel la plupart devraient commencer

Pour de nombreuses charges mixtes, commencez par 16–64 GiB de SLOG, en miroir si vous tenez à la disponibilité. Ce n’est pas une blague.
C’est parce que :

• Les TXG commitent souvent sur l’ordre de quelques secondes.
• Beaucoup de systèmes ne soutiennent pas des écritures sync de plusieurs gigaoctets par seconde ; ils soutiennent cela en mode async.
• Vous voulez de la marge pour les rafales et pour « le sync TXG qui s’est ralenti parce que le pool est occupé ».

Si vous avez besoin de plus de 64–128 GiB pour la capacité SLOG, je commence à suspecter que vous essayez de résoudre un problème de débit du pool
avec un dispositif de log. C’est comme acheter un pansement coûteux pour une jambe cassée.

Blague #1 : Un SLOG de 2 To, c’est comme installer un héliport sur un canoë — impressionnant en réunion, déroutant sur l’eau.

Quand « plus grand » est activement pire

Certains SSD deviennent plus lents sur des écritures petites et soutenues lorsqu’ils épuisent le cache SLC ou que leurs tables de mappage internes sont stressées.
Un gros disque grand public peut sembler rapide dans un benchmark puis s’effondrer durant de vraies tempêtes d’écritures synchrones. Pendant ce temps, un NVMe d’entreprise plus petit avec PLP reste d’une constance ennuyeuse. En stockage, « ennuyeux » est un compliment.

La latence est le vrai budget

Vos clients ne se soucient pas que votre SLOG puisse faire 3 GB/s en écritures séquentielles. Les écritures synchrones sont généralement petites (4–128 KiB),
souvent aléatoires, et régies par les sémantiques flush / FUA. Le métrique qui compte est la latence au 99e percentile
sur les écritures durables.

À quoi ressemble le « bon »

• Excellent : latence d’écriture durable inférieure à 100 microsecondes sur un NVMe PLP réel sous charge.
• Bon : quelques centaines de microsecondes à ~1 ms, stable.
• Mauvais : pics de plusieurs millisecondes, surtout périodiques (ils s’aligneront sur le comportement TXG et les timeouts clients).
• Affreux : dizaines à centaines de millisecondes lorsque le SSD fait du GC ou ment sur le flush.

Pourquoi le pool compte toujours

Le SLOG n’accélère que le chemin d’ACK. Le pool doit toujours absorber les écritures réelles lors du sync TXG. Si votre pool ne suit pas le débit moyen d’écriture,
vous pouvez « tamponner » dans le SLOG un moment, mais finalement vous aurez un retour de pression. Les symptômes incluent une latence synchrone croissante, des temps txg_sync en hausse et des blocages applicatifs.

Charges de travail : quand le SLOG aide, et quand c’est cosmétique

Charges de travail qui bénéficient souvent

• Datastores NFS pour virtualisation où l’hyperviseur effectue des écritures sync pour la sécurité des VM.
• iSCSI avec write barriers ou systèmes de fichiers invités effectuant fréquemment fsync.
• Bases de données avec durabilité activée (fsync fréquent), surtout pour de petits commits.
• Charges de fichiers riches en métadonnées : beaucoup de patterns create/rename/fsync.

Charges de travail où le SLOG est généralement futile

• Ingestion séquentielle lourde (médias, sauvegardes) qui est asynchrone ou peut tolérer l’asynchrone.
• Lots analytiques où les écritures sont tamponnées et engagées rarement.
• Tout ce qui a sync=disabled (oui, c’est rapide ; non, ce n’est pas sûr).

Le piège « écriture synchrone » : c’est l’appli qui décide, pas vous

ZFS respecte les sémantiques demandées. Si le client demande sync, ZFS fera du sync. Si le client ne le demande pas, ZFS ne le fera pas.
C’est pourquoi dimensionner un SLOG sans observer la charge, c’est de l’astrologie des performances.

Choix de périphériques : ce que les vendeurs ne mettent pas en avant

Non négociables pour un vrai périphérique SLOG

• Protection contre la perte d’alimentation (PLP) : condensateurs ou équivalent pour que le flush soit réellement durable.
• Latence basse et cohérente sous petites écritures soutenues : pas seulement « IOPS de pointe ».
• Endurance : les tempêtes d’écriture synchrone peuvent provoquer une amplification d’écriture infernale ; choisissez en conséquence.
• Comportement correct des flush/FUA : vous voulez que le périphérique respecte les barrières d’écriture.

Quelle classe de capacité acheter

Achetez pour la latence et la PLP, puis choisissez une capacité qui couvre votre besoin calculé avec marge. En pratique :

• Besoins effectifs 16–64 GiB : un SSD/NVMe d’entreprise 100–400 GB est généralement suffisant.
• Débit sync élevé ou temps TXG long : 400–800 GB apporte de la marge, mais ne transformez pas ça en trophée.
• Stockage multi-tenant servant de nombreux clients : envisagez un SLOG NVMe en miroir avec latence consistante, pas une capacité plus grande.

Pourquoi les SSD grand public sont une mauvaise idée (même quand ils « fonctionnent »)

Le mode de défaillance n’est pas juste « il meurt ». C’est « il ment ». Les périphériques grand public peuvent acquitter une écriture avant qu’elle ne soit
réellement durable, surtout en cas de perte d’alimentation. Cela transforme votre SLOG en tromperie : il est rapide jusqu’au moment où vous en aurez besoin.

Mi-roir ou pas : mathématiques de fiabilité et réalité opérationnelle

La perte d’un périphérique SLOG ne détruit généralement pas votre pool. ZFS peut revenir à l’utilisation du ZIL sur le pool.
Mais « généralement » n’est pas rassurant en production.

L’impact opérationnel de la perte d’un SLOG unique varie selon l’implémentation et l’environnement :

• La performance peut s’effondrer immédiatement (les écritures sync retournent sur les disques du pool).
• Vous pourriez devoir remplacer le matériel sous pression.
• Certaines équipes choisissent de prendre une fenêtre d’arrêt pour restaurer le profil de latence attendu plutôt que de boiter.

Mon choix par défaut et tranché : mettre le SLOG en miroir si ce système sert des clients sync sensibles à la latence (NFS pour VM, bases de données, stockage partagé).
Le coût incrémental est généralement inférieur à la première réunion post-incident.

Blague #2 : Un SLOG sur un seul disque en production, c’est comme une seule carte d’accès pour tout le bureau — efficace jusqu’à ce que quelqu’un la fasse tomber dans un latte.

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

Le seul dimensionnement qui compte est celui que vous pouvez défendre par des mesures. Voici des tâches pratiques à exécuter aujourd’hui.
Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Identify whether your pool has a SLOG and its topology

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

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            sda                      ONLINE       0     0     0
            sdb                      ONLINE       0     0     0
            sdc                      ONLINE       0     0     0
            sdd                      ONLINE       0     0     0
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0
        logs
          mirror-1                   ONLINE       0     0     0
            nvme0n1p1                ONLINE       0     0     0
            nvme1n1p1                ONLINE       0     0     0

errors: No known data errors

Sens : Il y a un log vdev en miroir (SLOG) utilisant deux partitions NVMe. Bien.
Si vous ne voyez pas de section logs, vous utilisez le ZIL sur le pool.

Décision : Si vous servez des clients sync intensifs et qu’il n’y a pas de SLOG, c’est une amélioration à envisager.
Si vous avez un SLOG non miroir et que la disponibilité compte, planifiez un miroir.

Task 2: Check dataset sync settings (the “did someone get clever?” test)

cr0x@server:~$ sudo zfs get -o name,property,value -s local,inherited sync tank/vmstore
NAME         PROPERTY  VALUE
tank/vmstore sync      standard

Sens : standard respecte les demandes de l’application. always force le sync (souvent plus lent),
disabled ment aux clients (rapide, dangereux).

Décision : Si vous trouvez sync=disabled sur un stockage VM ou base de données en production, considérez-le comme une décision d’acceptation de risque,
pas comme un réglage de performance.

Task 3: Confirm the workload is actually issuing sync writes

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         12.1T  43.7T    210    980  32.1M  88.4M
  raidz2-0                   12.1T  43.7T    210    780  32.1M  61.2M
    sda                          -      -     35    130  5.3M   9.9M
    sdb                          -      -     34    129  5.2M   9.8M
    sdc                          -      -     36    131  5.4M  10.0M
    sdd                          -      -     35    128  5.3M   9.7M
    sde                          -      -     35    131  5.3M  10.0M
    sdf                          -      -     35    131  5.3M  10.0M
logs                             -      -      0    200   0K   27.2M
  mirror-1                       -      -      0    200   0K   27.2M
    nvme0n1p1                    -      -      0    100   0K   13.6M
    nvme1n1p1                    -      -      0    100   0K   13.6M
--------------------------  -----  -----  -----  -----  -----  -----

Sens : Les écritures frappent le vdev logs. C’est du trafic synchrone qui est journalisé.
Si la bande passante du log est proche de zéro alors que les clients se plaignent de latence, votre charge peut être majoritairement asynchrone ou goulot d’ailleurs.

Décision : Si les ops/bw du log sont significatifs pendant la fenêtre de problème, la latence du SLOG importe. Sinon, arrêtez d’obséder sur la taille du SLOG.

Task 4: Look at per-dataset latency with extended iostat (OpenZFS)

cr0x@server:~$ sudo zpool iostat -r -v tank 1 3
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         12.1T  43.7T    220    990  33.0M  90.1M   2ms  24ms     1ms  20ms
  raidz2-0                   12.1T  43.7T    220    790  33.0M  62.0M   3ms  28ms     2ms  23ms
logs                             -      -      0    200   0K   28.1M    -    1ms      -    1ms
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----

Sens : Le vdev log affiche ~1 ms d’attente en écriture, tandis que le vdev principal affiche beaucoup plus. C’est attendu : le SLOG est rapide, le pool est plus lent.
Si l’attente en écriture du log est élevée, votre SLOG est le goulot d’étranglement pour les ACKs sync.

Décision : Si l’attente du log est constamment supérieure à la tolérance de votre application, remplacez le périphérique SLOG (latence), pas « une plus grande capacité ».

Task 5: Confirm ashift and device alignment (performance hygiene)

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
34:        vdev_tree:
58:                ashift: 12

Sens : ashift: 12 indique des secteurs 4K. Un mauvais alignement peut provoquer de l’amplification d’écriture et des pics de latence.

Décision : Si ashift est incorrect pour vos périphériques, planifiez une reconstruction/migration. On ne peut pas « régler » un pool mal aligné.

Task 6: Validate the SLOG device supports durable writes (PLP hints)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | egrep -i 'oncs|vwc|psd|mn'
mn      : INTEL SSDPE2KX040T8
oncs    : 0x001f
vwc     : 0x0001

Sens : vwc indique la présence d’un Volatile Write Cache. Cela ne prouve pas la PLP, mais c’est un indice utile pour la validation d’inventaire.
La confirmation réelle vient des spécifications du modèle et du vendeur — mais vous pouvez au moins détecter des discordances évidentes.

Décision : Si vous ne pouvez pas établir la confiance PLP, n’utilisez pas le périphérique pour le SLOG dans un système où la correction importe.

Task 7: Check if TRIM/discard is enabled and behaving (latency stability)

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

Sens : TRIM peut aider le comportement steady-state des SSD, réduisant les chutes de latence à long terme.
Ce n’est pas un outil de dimensionnement SLOG, mais cela change l’histoire du type « après quelques semaines, c’est devenu lent ».

Décision : Si vous êtes sur SSD/NVMe et que la plateforme le supporte, envisagez autotrim=on après tests.

Task 8: Observe TXG behavior indirectly via ZFS stats (Linux)

cr0x@server:~$ grep -E 'sync|async|txg' /proc/spl/kstat/zfs/txg | head -n 20
1 0 0x01 4 336 64080000 2110536636251
name                            type data
birth                           4    174541
timeout                         4    5
synced                          4    174538
opened                          4    174540

Sens : timeout montre l’intervalle TXG cible (souvent 5s). Si votre pool ne peut pas sync les TXG rapidement,
l’« intervalle » réel s’allonge, et votre SLOG doit garder les enregistrements plus longtemps.

Décision : Si le sync TXG prend du retard pendant les pics, réparez le débit/latence du pool ; n’augmentez pas simplement le SLOG.

Task 9: Capture sync write pressure with a targeted fio test (carefully)

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/test --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=1G --fsync=1 --runtime=20 --time_based --group_reporting
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
Starting 1 process
sync4k: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=580KiB/s][w=145 IOPS][eta 00m:00s]
sync4k: (groupid=0, jobs=1): err= 0: pid=14219: Fri Dec 26 12:14:21 2025
  write: IOPS=148, BW=594KiB/s (608kB/s)(11.6MiB/20s)
    lat (usec): min=820, max=9980, avg=1420.53, stdev=401.11
    clat percentiles (usec):
     |  1.00th=[  950],  5.00th=[ 1057], 10.00th=[ 1106], 50.00th=[ 1369]
     | 90.00th=[ 1795], 95.00th=[ 1975], 99.00th=[ 2474], 99.90th=[ 5866]

Sens : Ce test émet des petites écritures avec fsync. Les percentiles de latence sont ce qui compte.
Si le 99e percentile est de plusieurs millisecondes, les VM et bases de données ressentiront des « saccades ».

Décision : Si la latence est trop élevée, regardez d’abord la latence et l’ordonnancement du périphérique SLOG. Si le SLOG est rapide mais que l’ensemble est lent, le pool est le limiteur.

Task 10: Verify the SLOG is actually being used by your dataset path

cr0x@server:~$ sudo zfs get -o name,property,value logbias,recordsize,primarycache tank/vmstore
NAME         PROPERTY      VALUE
tank/vmstore logbias       latency
tank/vmstore recordsize    128K
tank/vmstore primarycache  all

Sens : logbias=latency incite ZFS à favoriser le SLOG pour le comportement sync. throughput peut réduire la dépendance au SLOG dans certains patterns.

Décision : Pour VM/NFS/bases de données où la latence sync importe, gardez logbias=latency. Ne le traitez pas comme un interrupteur « ça accélère » sans preuve.

Task 11: Check for periodic stalls and correlate with system I/O latency

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

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda              5.2   120.1    0.30    9.50      164.3     7.20   58.30     9.10    60.40   0.95  99.1
nvme0n1          0.0    98.0    0.00   12.80       267.0     0.10    1.05     0.00     1.05   0.08   0.9

Sens : Les disques magnétiques sont saturés à ~99% avec des awaits ~60 ms, ce qui allongera le temps de sync TXG.
NVMe est correct ici ; le vdev du pool est le goulot.

Décision : Si les disques du pool sont saturés, corrigez la disposition des vdevs, ajoutez des vdevs ou réduisez l’amplification d’écriture. Un SLOG plus grand ne changera pas le fait que sda est en feu.

Task 12: Inspect ARC pressure (to avoid blaming SLOG for memory issues)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:15:01  3120   210      6   180   5     20   1    10   0   112G   128G
12:15:02  2980   260      9   225   8     25   1    10   0   112G   128G
12:15:03  3410   240      7   210   6     20   1    10   0   112G   128G

Sens : Si l’ARC thrash et que les misses augmentent, vous pouvez être limité par les lectures, pas par les écritures sync.
Le SLOG ne sauvera pas une charge liée aux lectures.

Décision : Si miss% est élevé et que la latence est dominée par les lectures, ajustez la mémoire/ARC, ajoutez de la RAM ou revisitez recordsize/special vdev.

Task 13: Check ZFS pool properties that influence write behavior

cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim,listsnapshots,autoreplace tank
ashift	12
autotrim	on
listsnapshots	off
autoreplace	off

Sens : Pas directement du dimensionnement SLOG, mais ces valeurs reflètent l’intention opérationnelle de base. autoreplace off est courant ; assurez-vous simplement d’avoir un workflow de remplacement.

Décision : Si le comportement du pool est incohérent entre environnements, standardisez. Le dépannage SLOG devient plus simple quand le reste est sain.

Task 14: Simulate SLOG removal impact (planned maintenance window)

cr0x@server:~$ sudo zpool remove tank nvme0n1p1
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
            sda                      ONLINE       0     0     0
            sdb                      ONLINE       0     0     0
            sdc                      ONLINE       0     0     0
            sdd                      ONLINE       0     0     0
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0
        logs
          nvme1n1p1                  ONLINE       0     0     0

errors: No known data errors

Sens : Vous avez retiré un côté du miroir ; vous fonctionnez maintenant sans miroir. C’est une façon contrôlée de prouver votre dépendance au SLOG.

Décision : Si la latence devient inacceptable en mode dégradé, vous avez prouvé que le SLOG est critique et il doit être mis en miroir avec des périphériques appropriés et de l’alerte.

Feuille de route pour un diagnostic rapide

Quand les utilisateurs disent « le stockage est lent », ils décrivent un symptôme. Votre travail est de trouver quel sous-système ment.
Voici une séquence rapide et de niveau production qui identifie rapidement les goulots SLOG.

1) Confirmer qu’il s’agit bien de latence synchrone

• Vérifiez si le dataset affecté est utilisé par NFS/iSCSI/VMs/bases de données.
• Exécutez zpool iostat -v et voyez si les écritures frappent logs.
• Vérifiez la propriété sync du dataset pour des réglages surprise.

2) Décider : le SLOG est-il lent, ou le pool est-il lent ?

• Si le vdev log montre une forte attente en écriture : votre périphérique SLOG est le facteur limitant.
• Si le vdev log est rapide mais que les disques du pool ont un await/%util élevé : le pool ne peut pas sync les TXG rapidement.
• Si ni l’un ni l’autre : suspectez le client/réseau, les réglages NFS ou le comportement applicatif (tempêtes de fsync).

3) Trouver la périodicité et corréler

• Cherchez des pics toutes les quelques secondes (rythme TXG) ou minutes (GC SSD ou tâches de snapshot).
• Corrélez avec iostat -x et la latence ZFS zpool iostat -r.

4) Valider la classe du périphérique SLOG

• Confirmez un modèle PLP capable (inventaire + info contrôleur).
• Vérifiez firmware, throttling thermique et problèmes de slot PCIe (NVMe peut rétrograder).

5) Parlez de taille seulement ensuite

Si vous ne pouvez pas démontrer que le ZIL se remplit au-delà de la capacité actuelle du SLOG entre deux sync TXG, « plus grand SLOG » est superstition.
Corrigez la latence, le débit du pool, les sémantiques sync. La taille vient en dernier.

Erreurs courantes (symptôme → cause → correctif)

1) Gel du datastore VM pendant 1–5 secondes, puis récupération

Symptôme : blocages périodiques, souvent alignés sur des rafales d’écritures de métadonnées.

Cause racine : sync TXG trop long parce que les vdevs du pool sont saturés ; le SLOG n’accélère que le chemin ACK mais ne peut pas sauver un pool qui se noie.

Correctif : ajouter des vdevs, passer aux miroirs pour les IOPS, réduire l’amplification d’écriture (recordsize, volblocksize, compression), ou séparer les charges. Vérifiez avec iostat -x.

2) Le SLOG « aide » pendant une semaine, puis la latence devient étrange

Symptôme : latence synchrone en hausse progressive, pics sporadiques affreux.

Cause racine : effondrement du steady-state d’un SSD grand public (GC, épuisement du cache SLC), absence de TRIM, ou throttling thermique.

Correctif : remplacer par un périphérique d’entreprise PLP ; assurer autotrim=on si approprié ; surveiller températures NVMe et état du lien PCIe.

3) La défaillance du périphérique SLOG provoque une panne « parce qu’on a paniqué »

Symptôme : le pool reste en ligne mais la performance chute ; les opérations décident de prendre une interruption.

Cause racine : SLOG non miroir servant une charge sync critique ; la défaillance renvoie le trafic sync sur le pool.

Correctif : mettre le SLOG en miroir ; garder des périphériques de rechange ; répéter le remplacement ; alerter sur la dégradation du log vdev.

4) « On a ajouté un énorme SLOG et rien n’a changé »

Symptôme : même débit, mêmes plaintes de latence.

Cause racine : la charge est majoritairement asynchrone, ou le goulot est lecture, réseau, CPU, ou bande passante d’écriture du pool.

Correctif : mesurer l’activité du vdev log ; vérifier les misses ARC ; valider les réglages NFS/clients ; profiler le comportement fsync de l’appli avant de changer le matériel.

5) Incohérence des données après un événement de panne d’alimentation

Symptôme : corruption au niveau applicatif ou transactions manquantes après coupure brutale.

Cause racine : périphérique SLOG sans vraie protection contre la perte d’alimentation acquittant prématurément les écritures.

Correctif : n’utiliser que des périphériques PLP d’entreprise ; ne comptez pas sur un « UPS » comme unique stratégie de durabilité ; validez la politique de sémantiques sync.

6) Le SLOG est rapide, mais les écritures synchrones restent lentes

Symptôme : latence du vdev log semble basse, pourtant les clients voient des temps de commit élevés.

Cause racine : application effectuant des fsyncs supplémentaires, réglages NFS serveur/client forçant le sync, ou latence réseau dominante.

Correctif : inspecter les options de montage client, les réglages d’export NFS, les options de durabilité de la base ; mesurer la latence de bout en bout, pas seulement le disque.

Trois mini-histoires d’entreprise issues du terrain

Incident causé par une mauvaise hypothèse : « Le SLOG est un cache d’écriture »

Une entreprise SaaS de taille moyenne utilisait ZFS pour un cluster de virtualisation interne. L’équipe stockage a ajouté un « gros NVMe rapide » comme SLOG,
car le document d’achat indiquait « write cache pour ZFS ». C’était un disque grand public, mais les courbes de benchmark étaient magnifiques.

Le cluster a immédiatement semblé meilleur. Les tickets ont ralenti. L’équipe a déclaré victoire et est passée à autre chose. Deux mois plus tard, un événement
électrique a frappé une armoire. L’UPS a couvert la plupart des serveurs, mais une tête de stockage est tombée brutalement. Au redémarrage, le pool s’est importé. Aucune erreur ZFS évidente.
Pourtant l’équipe base de données a commencé à signaler des invariants cassés : des transactions acquittées par les invités n’étaient pas là.

Le postmortem a été brutal car ZFS « semblait sain ». La défaillance était sémantique : le périphérique SLOG avait acquitté des flushs qui n’étaient pas
réellement durables. ZFS a fait ce qu’on lui a demandé ; le périphérique a menti sur ce qu’il prétendait faire.

Le correctif n’était pas « plus grand » ni « plus ». Il était ennuyeux : NVMe PLP pour SLOG, en miroir, et une politique bannissant les disques grand public sur le chemin d’acquittement d’écriture.
Ils ont aussi cessé d’appeler le SLOG un cache dans la doc interne. Les mots comptent. Le mauvais mot crée un mauvais modèle mental, et le mauvais modèle écrit des chèques
que vos données ne peuvent pas honorer.

Optimisation qui a mal tourné : forcer sync=always pour « utiliser davantage le SLOG »

Dans une grande entreprise, une équipe a remarqué que leur SLOG brillant montrait à peine du trafic pendant les heures normales. Quelqu’un a conclu que le SLOG était « gaspillé »
et a appliqué sync=always sur le dataset NFS principal pour justifier le matériel. Le changement a été merged lors d’un sprint « durcissement stockage » avec de bonnes intentions et trop peu de scepticisme.

En un jour, les temps de réponse applicatifs sont devenus instables. Pas catastrophiquement lents — pire. Intermittents. Les équipes ont d’abord cherché du côté DNS, puis des load balancers,
puis des versions du kernel, parce que les graphiques stockage semblaient « corrects » en débit moyen.

Le vrai problème était auto-infligé : des charges qui écrivaient auparavant en async (et étaient conçues pour ça) ont été forcées en sync. Le SLOG
a accepté un flux de petits commits, et le pool a dû les absorber au sync TXG. La latence de queue a augmenté sur l’ensemble. Le changement a aussi augmenté l’amplification d’écriture et usé les SSD.

Le retour à sync=standard a stabilisé la latence immédiatement. Ils ont conservé le SLOG car les rafales métadonnées NFS et certains clients en ont bénéficié.
Mais la leçon est restée : ne forcez pas les sémantiques de durabilité pour « utiliser ce que vous avez acheté ». Rendez le système correct d’abord, puis rendez-le rapide là où ça compte.

Pratique ennuyeuse mais correcte qui a sauvé la journée : SLOG en miroir et remplacement répété

Une société de services financiers exploitait NFS sur ZFS pour un cluster traitant des fenêtres de batch sensibles au temps. Le design stockage était peu glamour :
SLOG en miroir sur SSD PLP, alertes reliées à l’astreinte, et un exercice trimestriel où ils simulaient une défaillance de périphérique log.

Un trimestre, un périphérique log a commencé à renvoyer des erreurs média. La surveillance a prévenu. L’astreinte a remplacé le composant pendant les heures de bureau sans drame
parce qu’ils s’étaient entraînés. La performance a à peine bougé car le log était en miroir et le périphérique survivant a pris la charge.

La morale est que personne en dehors de l’infra n’a remarqué. C’est le succès en exploitation : l’absence d’histoires.
L’équipe a quand même écrit une note interne, mis à jour le runbook et vérifié les versions de firmware sur la flotte.

C’est pourquoi je recommande le SLOG en miroir pour la production synchrone. Pas parce que c’est théoriquement requis, mais parce que cela évite des moments « on aurait dû » évitables.
L’incident le moins cher est celui auquel vous n’êtes jamais invité à expliquer.

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

Étape par étape : dimensionner et déployer un SLOG correctement

1. Confirmez que la charge est synchrone.
   Utilisez zpool iostat -v pendant le pic. Si les logs montrent de l’activité, vous êtes en territoire SLOG.
2. Mesurez la latence acceptable.
   Pour VM et bases de données, visez une latence d’écriture durable stable sous la milliseconde si possible.
3. Estimez le besoin en capacité.
   Débit d’écriture synchrone de pointe × pire temps sync TXG × marge. Si vous ne connaissez pas le débit, mesurez-le.
4. Sélectionnez la classe de périphérique d’abord, la taille ensuite.
   SSD/NVMe d’entreprise PLP, latence cohérente, endurance adéquate. Évitez les pièces grand public sur le chemin d’acquittement.
5. Mettez-le en miroir pour la production.
   Surtout si le stockage sert de nombreux clients ou si vos fenêtres de maintenance sont serrées.
6. Partionnez intentionnellement.
   Utilisez une partition dédiée pour le SLOG si nécessaire, mais ne partagez pas le périphérique avec des workloads aléatoires.
7. Ajoutez-le proprement.
   Vérifiez que zpool status le montre sous logs.
8. Validez l’amélioration avec des tests sync.
   Utilisez des tests fio sûrs sur un dataset non critique ou en fenêtre de maintenance. Comparez la latence tail, pas seulement les moyennes.
9. Mettez en place une surveillance de la santé et de la latence du log vdev.
   Alertez sur les erreurs périphériques, la dégradation et les changements significatifs des temps d’attente du log vdev.
10. Répétez la panne.
    Entraînez-vous à remplacer un périphérique log. Si vous ne pouvez pas le faire calmement, vous n’avez pas vraiment conçu pour ça.

Checklist d’achat (imprimez ceci avant que quelqu’un n’achète un « SSD rapide »)

• PLP : oui, documenté.
• Latence d’écriture aléatoire steady-state : cohérente, pas seulement des benchmarks bursty.
• Endurance adaptée au volume sync attendu.
• Firmware mature et comportement connu avec votre OS/kernel.
• Thermique : ne throttlera pas dans votre châssis.
• Format et interface : NVMe généralement préféré pour la latence ; SAS peut convenir si consistant.
• Budget incluant le miroir.

FAQ

1) Un SLOG plus grand rend-il ZFS plus rapide ?

Pas habituellement. La taille du SLOG importe rarement une fois qu’il est « assez grand ». La latence et la durabilité comptent. Si la performance s’améliore avec un SLOG plus grand,
cela signifie souvent que vos sync TXG prennent trop de temps et que vous tamponnez plus longtemps — vous ne résolvez pas la cause racine.

2) Comment savoir si ma charge utilise le SLOG ?

Exécutez zpool iostat -v pendant la charge et vérifiez si le vdev logs montre des ops/bande passante en écriture.
S’il est proche de zéro, votre charge n’émets pas beaucoup d’écritures sync ou elles ne passent pas par ce chemin de pool.

3) Le SLOG est-il la même chose que le L2ARC ?

Non. L2ARC est un cache de lecture. Le SLOG sert le ZIL, qui concerne la survie des écritures synchrones acquittées après un crash.
Confondre les deux conduit à acheter le mauvais matériel.

4) Que se passe-t-il si le périphérique SLOG meurt ?

Typiquement le pool reste en ligne et ZFS revient à l’utilisation du ZIL sur le pool, mais les performances des écritures sync peuvent chuter brutalement.
Opérationnellement, attendez-vous à des alertes et à des changements de latence visibles par les clients.

5) Dois-je mettre le SLOG en miroir ?

Si vous tenez à une latence et une disponibilité cohérentes pour des charges sync sensibles : oui. Si c’est une machine de laboratoire ou un système non critique : peut-être pas.
Mais reconnaissez ce que vous choisissez — risque et perturbation, pas seulement « économiser une baie disque ».

6) Puis-je utiliser une partition d’un NVMe plus grand comme SLOG ?

Oui, mais ne partagez pas le reste de ce NVMe avec d’autres workloads qui peuvent introduire des pics de latence. La contention annule tout l’intérêt.
Si vous partitionnez, gardez le périphérique dédié aux rôles ZFS.

7) sync=disabled élimine-t-il le besoin d’un SLOG ?

Il élimine les garanties de durabilité. Cela peut être acceptable pour des données strictement jetables, mais pour des VMs et des bases de données c’est une décision de politique
avec des conséquences. Traitez-la comme retirer la ceinture de sécurité parce que la voiture est plus légère.

8) logbias=throughput est-il plus rapide que logbias=latency ?

Ça peut l’être, selon les patterns d’écriture, mais ce n’est pas un gain gratuit. Pour des clients sync sensibles à la latence, latency est généralement le bon défaut.
Changez-le uniquement avec mesure et plan de retour arrière.

9) Quelle taille de SLOG raisonnable pour Proxmox ou hôtes VM sur NFS ?

Couramment 16–64 GiB de besoin effectif, implémentés comme une paire NVMe miroir PLP 100–400 GB. Si vous observez des débits sync soutenus élevés
et des TXG sync lents, ajustez — mais vérifiez que vous ne masquez pas un goulot du pool.

10) Un SLOG rapide peut-il masquer un pool lent ?

Brèvement, oui. Il peut rendre les ACKs rapides tandis que le pool peine toujours à committer les TXG. Finalement le système subira un retour de pression.
Si votre pool est chroniquement saturé, corrigez le design du pool.

Conclusion : prochaines étapes pratiques

Dimensionnez votre SLOG comme un opérateur, pas comme un collectionneur. Vous voulez un périphérique capable d’acquitter rapidement, correctement et de manière cohérente les écritures synchrones —
et une capacité qui couvre le burst entre deux sync TXG avec marge. C’est tout.

Prochaines étapes qui font réellement la différence :

1. Mesurez si les écritures sync sont le problème (zpool iostat -v, propriété dataset sync, tests fio fsync en fenêtre sûre).
2. Si les écritures sync limitent, achetez pour PLP + stabilité de latence, pas pour la capacité. Mettez en miroir si vous valorisez la disponibilité.
3. Si le sync TXG est lent, arrêtez de chercher des SLOG et redesign du pool pour IOPS/bande passante d’écriture.
4. Rédigez un runbook pour la défaillance du log vdev et exercez-vous une fois. Votre futur vous remerciera d’être moins fatigué.