ZFS logbias : latence vs débit — choisissez ce dont vous avez vraiment besoin

novembre 19, 2025 • février 3, 2026 • Lecture : 30 min • Views: 6

Cet article vous a aidé ?

ZFS a une réputation : intégrité à toute épreuve, paramètres par défaut sensés, et juste assez de boutons pour vous sauver d’une panne — ou la provoquer. logbias est l’un de ces réglages. Ce n’est pas spectaculaire, et ça ne réparera pas une pool fondamentalement lente. Mais cela peut absolument modifier la forme de vos performances, surtout quand vous tenez aux écritures synchrones.

Si vous gérez des bases de données, du stockage de VM, des exportations NFS, ou quoi que ce soit qui utilise fsync() comme s’il était payé à l’appel, votre vraie question n’est pas « À quelle vitesse est ZFS ? ». C’est « Que veux-je : une latence plus faible par synchronisation, ou plus de débit global sur la durée ? » logbias est l’endroit où vous dites à ZFS ce dont vous avez réellement besoin — plutôt que ce que vous espérez qu’il fasse.

Ce que `logbias` est réellement (et ce qu’il n’est pas)

logbias est une propriété par dataset (ou par zvol) qui influence la façon dont ZFS gère les écritures synchrones : s’il doit préférer utiliser le chemin du ZFS Intent Log (ZIL) pour un acquittement à faible latence, ou s’il doit favoriser d’abord l’envoi des données vers la pool principale pour un meilleur débit agrégé.

Deux valeurs comptent en pratique :

logbias=latency (par défaut) : prioriser une faible latence pour les écritures synchrones ; utiliser agressivement le chemin ZIL/SLOG.
logbias=throughput : essayer d’éviter les schémas de « double écriture » et réduire la dépendance au périphérique de log pour les grosses écritures synchrones ; pousser davantage vers la pool principale quand c’est raisonnable.

Ce que ce n’est pas :

Ce n’est pas un indicateur magique « rendre ma pool rapide ». Si votre pool est surchargée ou a un mauvais comportement d’écritures aléatoires, logbias ne le réglera pas.
Ce n’est pas la même chose que sync=disabled. logbias ne change pas les sémantiques de cohérence. sync=disabled le fait.
Ce n’est pas un substitut à un périphérique SLOG correct (si votre charge en a besoin), ni au bon dimensionnement des enregistrements ou au réglage de la base de données.

Résumé opérationnel en une phrase : logbias détermine où ZFS préfère payer le coût d’un acquittement d’écriture synchrone — sur le chemin du log maintenant, ou dans la pool principale bientôt — sans tromper les applications.

Blague #1 : Mettre logbias=throughput sans mesurer, c’est comme « optimiser » une réunion en supprimant l’ordre du jour — techniquement plus rapide, spirituellement désastreux.

Un modèle mental pratique : ZIL, SLOG, TXGs

Si vous traînez autour de ZFS assez longtemps, vous avez entendu ces acronymes lâchés comme s’ils allaient de soi. Ils ne le sont pas. Rendons-les utiles.

ZIL : le journal d’intention, toujours présent

Le ZFS Intent Log (ZIL) existe pour une seule tâche : permettre à ZFS d’accuser réception en toute sécurité des écritures synchrones. Lorsqu’une application effectue une écriture synchronisée (ou appelle fsync()), ZFS doit consigner suffisamment d’informations sur un stockage stable afin que, après un crash, il puisse rejouer ces opérations et préserver les garanties côté application.

Important : le ZIL n’est pas un cache d’écriture pour tout. C’est un journal des transactions synchrones récentes, et il n’est utilisé que pour la récupération après un arrêt non propre. En fonctionnement normal, les données finissent par atterrir dans la pool principale lors des commits des groupes de transactions (TXG).

SLOG : un périphérique séparé pour le ZIL, optionnel mais puissant

SLOG est le nom que les opérateurs donnent à un périphérique de log séparé attaché via des vdev(s) log (par exemple, un SSD entreprise ou un NVMe). Lorsqu’il est présent, ZFS écrit les enregistrements ZIL sur ce périphérique au lieu de les placer dans la pool principale.

C’est la nuance critique qui cause tant de débats en production : SLOG concerne la latence et les IOPS pour les écritures synchrones, pas l’accélération des écritures asynchrones, et pas l’augmentation de la bande passante totale pour les charges séquentielles.

TXGs : le système de regroupement qui rend ZFS efficace

ZFS regroupe les modifications en TXG et les engage périodiquement sur disque. La cadence par défaut est de l’ordre de la seconde (dépend de l’implémentation ; le point opérationnel est « traitement par lots »). Ce regroupement est là où ZFS gagne une grande partie de sa performance : il peut réordonner, fusionner, et écrire efficacement.

Les écritures synchrones interrompent la fête. ZFS veut toujours regrouper, mais il doit aussi fournir un acquittement stable. Le ZIL/SLOG est le compromis : « Je vais consigner assez pour survivre à un crash maintenant, puis je vais tout fusionner dans la pool principale plus tard en lot cohérent. »

La « double écriture » qui mérite votre attention

Dans de nombreuses charges lourdes en synchronisation, vous écrivez effectivement les données deux fois :

Écrire des enregistrements de log dans le ZIL (sur SLOG ou la pool) pour pouvoir accuser la synchronisation.
Plus tard, écrire les vrais blocs à leur emplacement final lors du commit TXG.

Ce n’est pas du « gaspillage » ; c’est la façon dont ZFS fournit la cohérence et la performance. Mais cela signifie que votre périphérique le plus rapide peut devenir votre goulot d’étranglement d’une manière très spécifique : un petit SLOG gérant de petites écritures synchrones peut plafonner le taux de transactions de toute votre application.

Latence vs débit : ce que `logbias` change

Voici l’explication niveau opérateur : ZFS doit décider comment gérer les écritures synchrones, en particulier les écritures volumineuses. Logger de grandes quantités de données dans le ZIL peut être coûteux et créer un second flux d’écritures que votre système devra ensuite absorber à nouveau. Dans ces situations, il peut être plus intelligent de traiter une « grosse écriture synchrone » comme « je devrais juste mettre ça dans la pool rapidement » plutôt que « je dois passer tout ça par le périphérique de log. »

logbias est l’indice qui oriente cette décision.

`logbias=latency` (par défaut) : rendre rapides les acquittements de sync

Quand votre charge envoie fréquemment des écritures synchrones et tient à la réactivité de chaque transaction — bases de données avec commits durables, NFS avec sémantique sync, disques VM avec barrières — la latence est reine.

Avec logbias=latency :

ZFS est plus enclin à diriger les données d’écriture synchrone vers le chemin ZIL/SLOG.
Si vous avez un bon SLOG (faible latence, protection contre la perte de puissance), vous verrez souvent une latence de commit nettement plus faible.
Votre pool peut rester relativement calme parce que le SLOG absorbe la tempête de sync, et la pool rattrape le retard lors des écritures TXG.

Ce qui peut mal tourner : si votre SLOG est lent, grand public, sans PLP, ou attaché via un bus déjà saturé, vous avez créé un point unique de défaillance de performance. La pool peut aller bien ; le chemin d’acquittement sync, non.

`logbias=throughput` : réduire la dépendance au log, favoriser l’écriture directe dans la pool

logbias=throughput est généralement utilisé pour des charges qui génèrent des écritures synchrones mais où la latence par écriture importe moins que le débit global — pensez aux grosses écritures séquentielles marquées synchrones en raison du comportement de l’application, des couches de virtualisation, ou de réglages conservateurs d’export.

Avec logbias=throughput :

ZFS est encouragé à éviter de faire transiter de grosses écritures synchrones par le ZIL, car cela peut se transformer en « les logger maintenant, les réécrire plus tard » à grande échelle.
La pool principale effectue davantage de travail lourd directement, ce qui peut être bénéfique si votre pool est large (plusieurs vdevs) et que votre SLOG est relativement petit.

Ce qui peut mal tourner : vous pouvez déplacer le goulot d’étranglement de la latence SLOG vers la latence d’écriture de la pool. Si la pool est composée de disques tournants lents, ou si elle est déjà fragmentée, ou si vous avez une forte pression de lecture, pousser plus de données sync « directement vers la pool » peut augmenter la latence visible pour l’application. En d’autres termes : vous avez obtenu du débit, et payé en latence de queue.

Ce que `logbias` ne corrige pas

Certaines problématiques sont en amont et riront de vos ajustements de propriété :

recordsize/volblocksize mal dimensionnés pour la charge.
Invités VM effectuant de petites écritures aléatoires synchrones sur des zvols thin-provisioned avec compression désactivée et sans TRIM.
Exportations NFS avec comportement sync qui force chaque écriture à être durable avant de revenir, combinées à un SLOG médiocre.
Une pool qui est simplement hors capacité d’IOPS.

Blague #2 : Le SLOG, c’est comme un videur de boîte — si vous embauchez quelqu’un de lent, peu importe la taille de la piste : personne ne rentre.

Faits et historique utilisables en réunion

Voici des points courts et concrets pour couper à travers le tuning cargo-cult lors des revues de conception.

ZFS a été conçu autour des sémantiques transactionnelles, pas pour « écrire en place immédiatement ». Les TXG sont fondamentaux, pas accessoires.
Le ZIL existe même sans SLOG. Si vous n’ajoutez pas de vdev de log, les enregistrements ZIL atterrissent sur les périphériques de la pool principale.
Le SLOG n’est utilisé que pour les écritures synchrones. Les écritures asynchrones en streaming ne s’accéléreront pas parce que vous avez ajouté un périphérique de log.
Le ZIL n’est généralement lu qu’après un crash. En fonctionnement sain, les données ZIL sont « écritures seules » et sont abandonnées après le commit TXG.
La protection contre la perte de puissance (PLP) n’est pas une fonctionnalité de performance ; c’est une fonctionnalité de cohérence. Sans PLP, un acquittement « rapide » peut devenir une « perte de données rapide ».
Beaucoup de piles de virtualisation et de stockage réseau génèrent des écritures sync de manière conservatrice (barrières, flushes, écritures stables). Parfois l’application n’est pas paranoïaque ; c’est la pile qui l’est.
Les premiers déploiements ZFS ont popularisé la recette « ajoutez un SSD SLOG », mais les SSD grand public du marché ont souvent menti sur la durabilité des flush — les opérateurs l’ont appris à leurs dépens.
Les périphériques de log séparés peuvent être mis en miroir, car perdre un SLOG pendant l’exploitation peut provoquer un panic/arrêt de la pool sur certaines plateformes/configurations — la disponibilité compte.
La latence et le débit peuvent évoluer en sens opposé lorsque vous changez le chemin d’acquittement sync, car vous changez quel périphérique devient « la porte ».

Trois mini-histoires du monde de l’entreprise (échec, retour de flamme, sauvetage)

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

Une entreprise de taille moyenne exploitait un service NFS sur ZFS pour des artefacts de build et des images VM. Ils avaient un problème de performance : certains clients se plaignaient de « pauses aléatoires ». Quelqu’un a proposé le classique : « Ajoutez un NVMe rapide comme SLOG ; ZFS va décoller. » Les achats ont livré un NVMe grand public avec d’excellents benchmarks séquentiels et un prix qui a fait sourire la finance.

Ils l’ont ajouté comme vdev de log unique et sont partis. Pendant quelques jours, ça allait mieux — latence moyenne des écritures NFS plus basse, moins de tickets. Puis ils ont eu un événement d’alimentation : transfert UPS bref, rien de dramatique. Le serveur de stockage est reparti, et en quelques minutes la pool a eu des problèmes. Les clients ont vu des erreurs d’E/S et des montages bloqués. La machine n’était pas morte ; c’était pire : elle était vivante et confondue.

La cause racine était douloureusement ordinaire. Le NVMe grand public ne fournissait pas de protection fiable contre la perte de puissance pour les sémantiques de flush. Pendant l’événement d’alimentation, des enregistrements de log qui avaient été acquittés comme durables ne l’étaient en réalité pas. ZFS a fait exactement ce qu’il devait : il a refusé de continuer en toute sécurité quand la chaîne de log n’avait pas de sens. L’équipe avait supposé « SSD rapide = bon SLOG », et la production n’était pas d’accord.

La correction n’était pas un tuning mystique. Ils ont remplacé le SLOG par un périphérique entreprise avec PLP et l’ont mis en miroir. Puis ils ont fait la partie ennuyeuse : documenter que « le SLOG n’est pas un cache ; c’est une promesse. » Ils ont aussi ajouté de la supervision pour détecter la latence et les erreurs du périphérique de log avant que cela ne devienne un incident global.

2) Optimisation qui s’est retournée contre eux : « logbias=throughput partout »

Un autre environnement : un cluster de virtualisation utilisant des zvols pour les disques VM via iSCSI. L’équipe de stockage a observé que le SLOG était occupé, et certaines VM avaient un débit d’écriture médiocre. Quelqu’un a lu que logbias=throughput peut améliorer les performances pour les grosses écritures sync et a décidé de l’appliquer partout : tous les datasets, tous les zvols, sans exception. La fenêtre de changement était courte et la motivation compréhensible : moins de changements signifie moins d’erreurs.

Le lendemain, les tickets d’assistance ne parlaient pas de débit. Ils disaient « la VM est lente », « les commits de la base de données se bloquent parfois », et celui qui attire l’attention : « API de paiement en timeout intermittente. » Les graphiques semblaient corrects en moyenne. Les latences de queue, non.

Ce qui s’est passé était architectural. Certaines VM faisaient de grosses écritures séquentielles (tâches de sauvegarde) et ont effectivement vu le débit s’améliorer. Mais les voisins bruyants n’étaient pas le problème. Les charges sensibles étaient des bases de données petites et sync-intensives. En se détournant du chemin du log, le système a poussé plus de travail sync vers la pool principale. La pool pouvait le faire, mais pas à faible latence quand elle était mélangée à de la charge de lecture et à une activité de scrub périodique. La latence de commit a explosé, puis a entraîné des timeouts applicatifs.

Ils ont fait un rollback sélectif : logbias=latency pour les zvols de base de données, logbias=throughput pour les volumes de sauvegarde et d’ingestion massive. Puis ils ont défini des SLO de performance qui suivaient explicitement la latence p95/p99 des commits pour les écritures sync, pas seulement MB/s. L’optimisation n’était pas mauvaise ; l’hypothèse qu’un seul réglage convient à toutes les charges l’était.

3) Une pratique ennuyeuse mais correcte qui a sauvé la mise : « mesurer la latence sync et mettre le SLOG en miroir »

Une société de services financiers (du genre qui traite le stockage comme un produit de première classe) utilisait ZFS pour plusieurs clusters PostgreSQL internes. Ils avaient déjà été piqués par du hardware « rapide mais fragile », donc leur pratique était presque terne : SLOG d’entreprise en miroir avec PLP, et un tableau de bord qui suivait les métriques liées au ZIL et la latence des écritures sync.

Un après-midi, les équipes applicatives ont commencé à signaler une légère élévation de la latence des transactions. Pas une panne — juste les signes avant-coureurs que l’on ignore habituellement jusqu’au week-end. Le SRE de garde a vérifié le tableau et a remarqué un changement : la latence d’écriture du vdev de log avait augmenté, tandis que la latence de la pool était normale. C’est une odeur très spécifique.

Ils ont examiné les logs système et ont vu des erreurs médias intermittentes sur l’un des périphériques SLOG. Parce que le vdev de log était en miroir, la pool est restée saine et le service est resté opérationnel. Parce qu’ils mesuraient la bonne chose (la latence sync), ils l’ont détecté avant que cela ne devienne un incident. Ils ont remplacé le périphérique défaillant pendant les heures ouvrables sans drame, ce qui est le meilleur type de rapport d’incident : celui que personne n’écrit.

C’est la partie difficile à vendre en réunion budgétaire : la pratique ennuyeuse n’a pas « augmenté les performances ». Elle a empêché la performance de devenir une indisponibilité.

Playbook de diagnostic rapide

Ceci est la séquence « vous avez 15 minutes avant l’appel d’escalade ». L’objectif est d’identifier si votre goulot est la sémantique applicative, le chemin du log, ou la pool principale.

Premier point : confirmez que vous avez bien affaire à des écritures synchrones

Vérifiez les propriétés dataset/zvol : sync, logbias.
Vérifiez le comportement client/protocole : montages NFS, paramètres de durabilité de la base, barrières d’écriture VM.
Cherchez des symptômes : forte latence avec faible débit, beaucoup de petites écritures, schémas intensifs en fsync.

Deuxième point : déterminez si le chemin du log (SLOG) est la porte

Si vous avez un SLOG, vérifiez la latence du vdev de log et les erreurs.
Comparez la latence de commit applicative à la latence du périphérique SLOG. Si elles suivent, vous avez trouvé votre point d’étranglement.
Vérifiez si le SLOG est saturé (IOPS, profondeur de file) ou en pause (latence de flush).

Troisième point : si ce n’est pas le SLOG, la pool est votre goulot (ou le CPU l’est)

Vérifiez la latence d’écriture et l’utilisation de la pool. Si vos vdevs de pool sont proche de 100% occupés, vous êtes à court de capacité.
Vérifiez la pression ARC et l’amplification de lecture ; des lectures lourdes peuvent priver les écritures.
Vérifiez la surcharge CPU due à la compression, au checksumming et au chiffrement si le processeur est saturé.

Point de décision

Si la latence des écritures synchrones est le problème :

Privilégiez logbias=latency avec un SLOG approprié pour les datasets sensibles à la latence.
Considérez logbias=throughput uniquement lorsque la charge est volumineuse et séquentielle et que des écritures supplémentaires vers la pool ne violeront pas vos SLOs de latence.

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

Ce sont des tâches réelles que vous pouvez exécuter sur un système OpenZFS-on-Linux typique. Adaptez les noms de pool/dataset à votre environnement. L’objectif n’est pas d’exécuter des commandes pour le sport ; c’est de transformer logbias de folklore en choix mesuré.

Tâche 1 : Inspecter `logbias` et `sync` actuels sur un dataset

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

Interprétation : Ce dataset est explicitement réglé sur logbias=latency. Le comportement sync est standard (respecter les requêtes de l’application). Si vous déboguez la latence de commit, c’est la baseline attendue.

Tâche 2 : Trouver où `logbias` est défini sur la pool

cr0x@server:~$ sudo zfs get -r -o name,property,value,source logbias tank | grep -v default
tank                     logbias   latency     default
tank/db                  logbias   latency     local
tank/backups             logbias   throughput  local

Interprétation : Vous avez des intentions mixtes : les bases de données sont biaisées latence ; les sauvegardes sont biaisées débit. C’est généralement sain, si vos charges diffèrent vraiment.

Tâche 3 : Vérifier si vous avez un vdev de log séparé (SLOG)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:33 with 0 errors on Sun Dec 22 03:10:01 2025
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
          mirror-1                  ONLINE       0     0     0
            nvme0n1p2               ONLINE       0     0     0
            nvme1n1p2               ONLINE       0     0     0

Interprétation : Vous avez un SLOG en miroir. C’est une posture de production solide pour les charges sync-intensives : performance plus disponibilité.

Tâche 4 : Surveiller les IO et la latence au niveau de la pool

cr0x@server:~$ sudo zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         3.21T  8.54T    210    460  18.4M  62.1M
  raidz2-0                    3.21T  8.54T    210    460  18.4M  62.1M
    sda                           -      -     35     78  3.1M  10.5M
    sdb                           -      -     37     80  3.3M  10.2M
    sdc                           -      -     34     76  3.0M  10.4M
    sdd                           -      -     35     77  3.1M  10.6M
logs                              -      -      -      -
  mirror-1                        -      -      0    920    0B  12.4M
    nvme0n1p2                     -      -      0    470    0B   6.2M
    nvme1n1p2                     -      -      0    450    0B   6.1M

Interprétation : Beaucoup d’écritures vont vers le vdev de log : fort indice que vous avez une activité sync-intensive. Si les applications se plaignent de latence, vous savez maintenant où regarder ensuite : latence du périphérique de log et comportement des flush.

Tâche 5 : Récupérer des statistiques de latence étendues (là où c’est supporté)

cr0x@server:~$ sudo zpool iostat -v -l tank 2
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         3.21T  8.54T    190    510  16.9M  64.8M   3ms  18ms     2ms  15ms
  raidz2-0                    3.21T  8.54T    190    240  16.9M  52.1M   2ms  22ms     2ms  19ms
logs                              -      -      0   1080    0B  12.7M    -   2ms       -   1ms
  mirror-1                        -      -      0   1080    0B  12.7M    -   2ms       -   1ms

Interprétation : Les écritures du vdev de log sont de faible latence (bon). Les écritures de la pool sont plus lentes (22ms). Si la latence sync est bonne mais que le débit est mauvais, la pool peut être la limite ; si la latence sync est mauvaise, le log pourrait être la porte. Des chiffres comme ceux-ci vous aident à séparer les deux.

Tâche 6 : Vérifier l’alignement recordsize / volblocksize (souvent la taxe cachée)

cr0x@server:~$ sudo zfs get -o name,property,value recordsize tank/db
NAME     PROPERTY    VALUE
tank/db  recordsize  16K

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize tank/vm-001
NAME         PROPERTY     VALUE
tank/vm-001  volblocksize 8K

Interprétation : Les bases de données se comportent souvent mieux avec des records plus petits (par ex. 8K–16K) selon la taille de page DB et le pattern d’accès. Les VM utilisent fréquemment 8K volblocks par défaut pour les zvols. Le désalignement peut amplifier les IO et aggraver les tempêtes sync quel que soit logbias.

Tâche 7 : Vérifier si la charge force le sync au niveau ZFS

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

Interprétation : standard est normalement ce que vous voulez : respecter les demandes d’application. Si quelqu’un a mis sync=always « pour la sécurité », attendez-vous à plus de trafic ZIL. Si quelqu’un a mis sync=disabled « pour la performance », attendez-vous à des benchmarks plus rapides et à des rapports d’incident plus créatifs.

Tâche 8 : Modifier `logbias` pour un dataset spécifique (portée sûre)

cr0x@server:~$ sudo zfs set logbias=throughput tank/backups
cr0x@server:~$ sudo zfs get -o name,property,value,source logbias tank/backups
NAME         PROPERTY  VALUE       SOURCE
tank/backups logbias   throughput  local

Interprétation : C’est un changement à faible risque si le dataset héberge de grosses écritures séquentielles et que vous pouvez tolérer une latence par écriture plus élevée. Ne faites pas cela sur le dataset qui contient vos journaux de transaction sauf si vous aimez les appels d’urgence.

Tâche 9 : Benchmark de la latence d’écriture sync de façon réaliste

Utilisez fio si disponible. Cet exemple effectue des écritures aléatoires 4K de type sync via fdatasync=1.

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/dbtest --rw=randwrite --bs=4k \
  --iodepth=1 --numjobs=1 --size=2G --direct=1 --fdatasync=1 --time_based --runtime=60 --group_reporting
sync4k: (groupid=0, jobs=1): err= 0: pid=22190: Tue Dec 24 10:11:09 2025
  write: IOPS=820, BW=3280KiB/s (3359kB/s)(192MiB/60001msec)
    clat (usec): min=500, max=32000, avg=1215.4, stdev=820.1
    lat (usec): min=510, max=32050, avg=1222.0, stdev=822.0

Interprétation : Ceci indique ce que ressent l’application : environ 1,2 ms de latence moyenne de complétion, avec des queues allant jusqu’à 32 ms. Si vous changez logbias ou le hardware SLOG et que cela ne bouge pas, vous touchez le mauvais niveau.

Tâche 10 : Comparer le comportement avec un test orienté débit

cr0x@server:~$ sudo fio --name=seq128k --directory=/tank/backuptest --rw=write --bs=128k \
  --iodepth=16 --numjobs=4 --size=8G --direct=1 --fsync=0 --time_based --runtime=60 --group_reporting
seq128k: (groupid=0, jobs=4): err= 0: pid=22310: Tue Dec 24 10:13:30 2025
  write: IOPS=2100, BW=262MiB/s (275MB/s)(15.4GiB/60001msec)

Interprétation : Ceci est du débit asynchrone. Le SLOG n’importera pas beaucoup ici, et logbias non plus sauf si votre pile force des sémantiques sync. Si votre « mise à niveau SLOG » a changé ce nombre, quelque chose d’autre a aussi changé.

Tâche 11 : Identifier si les clients NFS forcent le comportement synchrone

cr0x@server:~$ mount | grep nfs
10.0.0.20:/export/vmstore on /mnt/vmstore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.42)

cr0x@server:~$ nfsstat -m | sed -n '1,6p'
/mnt/vmstore from 10.0.0.20:/export/vmstore
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys

Interprétation : Les options de montage ne racontent pas toujours toute l’histoire ; les sémantiques NFS et les patterns d’fsync côté application jouent. Mais cela confirme que vous n’êtes pas monté en lecture seule ou avec un petit rsize/wsize qui ferait tout ressentir comme de la mélasse.

Tâche 12 : Vérifier les statistiques ZFS pour l’activité ZIL (Linux)

cr0x@server:~$ awk 'NR==1 || /zil/ {print}' /proc/spl/kstat/zfs/arcstats | head
13 1 0x01 122 4880 167920131122 293229773812
zil_commit_count                         4    189223
zil_commit_writer_count                  4    189223
zil_itx_count                            4    812333
zil_itx_indirect_count                   4    1102

Interprétation : Si les compteurs de commit augmentent rapidement pendant la fenêtre d’incident, vous avez une charge sync. Corrélez avec la latence du périphérique de log. Si les commits sont faibles mais que l’application est lente, vous vous battez probablement contre autre chose (saturation de la pool, CPU, réseau, comportement invité).

Tâche 13 : Confirmer que vos périphériques de log ne meurent pas silencieusement

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,25p'
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
Data Units Written:                 12,345,678
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Interprétation : Les erreurs médias et les entrées du journal d’erreurs comptent plus que le « pourcentage utilisé ». Un SLOG est martelé par de petites écritures et des flushs ; un périphérique peut sembler « sain » jusqu’au moment où il ne l’est plus. Surveillez les compteurs d’erreurs et la latence, pas seulement la capacité.

Tâche 14 : Valider où se trouve votre goulot avec `iostat`

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              30.0    75.0   3072   10432   18.5   2.1   98.0
sdb              29.0    76.0   2976   10384   19.0   2.0   97.5
sdc              28.0    74.0   2880   10240   18.9   2.0   97.1
sdd              29.0    75.0   2992   10368   19.2   2.1   98.3
nvme0n1           0.0   480.0      0    6144    1.1   0.2    9.5
nvme1n1           0.0   470.0      0    6016    1.0   0.2    9.2

Interprétation : Les HDD sont saturés à ~98% d’utilisation. Même si votre SLOG est rapide, la pool est saturée, ce qui finira par affecter la synchronisation via la pression des TXG et la réactivité globale du service. Si votre « correctif » n’était que logbias, il ne survivra pas à cette réalité.

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

Checklist : choisir `logbias` par dataset

Classifiez la charge : Est-elle dominée par de petites écritures sync (commits DB, opérations riches en métadonnées), ou par de grosses écritures séquentielles sync (ingestion en masse avec sémantique sync) ?
Définissez la métrique de succès : latence p95/p99 pour les commits, ou MB/s pour les écritures massives. Si vous ne pouvez pas la nommer, vous ne pouvez pas la tuner.
Vérifiez si vous avez un vrai SLOG : grade entreprise, PLP, faible latence ; de préférence en miroir pour la disponibilité.
Réglez logbias=latency pour les datasets sensibles à la latence : bases de données, disques VM riches en métadonnées, répertoires home NFS interactifs.
Réglez logbias=throughput pour les datasets massifs : sauvegardes, ingestion média, staging de gros fichiers — surtout quand les sémantiques sync sont inévitables.
Benchmarkez avant et après : utilisez un benchmark de type sync pour les charges sync, pas un test d’écriture streaming qui ignore fsync.

Plan étape par étape : déploiement sûr en production

Choisissez un dataset avec une identité de charge claire et un propriétaire clair (quelqu’un qui confirmera succès ou douleur).
Capturez les métriques de référence (latence sync, IOPS, latence queue, utilisation pool, latence SLOG si présente).
Changez une seule variable : réglez logbias (ne changez pas aussi recordsize, compression et hardware dans la même fenêtre).
Observez pendant le pic, pas seulement pendant la fenêtre de maintenance. Les problèmes sync apparaissent souvent sous contention.
Revenez en arrière rapidement si les latences de queue se dégradent. Gardez la commande de rollback prête.
Documentez la raison (quelle charge, quelle métrique s’est améliorée, quelle métrique s’est dégradée). Cela évite « l’amnésie de tuning » six mois plus tard.

Garde-fous opérationnels

N’utilisez jamais sync=disabled comme contournement de performance sur des charges revendiquant des exigences de durabilité. Si vous devez le faire, traitez-le comme une décision de risque délibérée avec validation.
Mettre en miroir les périphériques SLOG pour la disponibilité si votre plateforme et votre tolérance au risque l’exigent. Perdre un périphérique de log peut devenir une indisponibilité.
Séparez les charges bulk des charges sensibles à la latence au moins au niveau dataset, idéalement au niveau pool si la contention est sévère.

Erreurs courantes, symptômes, corrections

Erreur 1 : supposer que `logbias=throughput` est « plus rapide » en général

Symptômes : les moyennes semblent correctes, mais la latence p95/p99 empire ; les bases de données timeout ; les VM « saccadent » sous charge.

Pourquoi : vous avez déplacé le travail sync d’un log rapide vers une pool occupée, augmentant la contention et la latence de queue.

Correction : mettez logbias=latency sur les datasets sensibles à la latence ; conservez throughput pour les datasets massifs uniquement. Vérifiez avec des benchmarks sync et des métriques de queue.

Erreur 2 : acheter un « SSD rapide » pour SLOG sans PLP

Symptômes : problèmes intermittents de pool après événements d’alimentation ; erreurs d’E/S mystérieuses ; ZFS refuse d’importer proprement ou se plaint du replay de log.

Pourquoi : le périphérique ment (ou est ambigu) sur la durabilité des flush. Les acquittements sync deviennent peu fiables.

Correction : utilisez des périphériques entreprise avec PLP ; mettez le vdev de log en miroir ; surveillez les logs d’erreurs et la latence du périphérique.

Erreur 3 : oublier que SLOG n’aide pas les écritures asynchrones

Symptômes : vous ajoutez un SLOG et ne voyez aucun changement dans les tests d’écriture en streaming ; la direction vous demande pourquoi vous « avez gaspillé de l’argent ».

Pourquoi : votre charge est principalement asynchrone ; le SLOG n’est pas sur le chemin critique.

Correction : benchmarkez la bonne chose (latence sync) et validez que l’application/protocole émet réellement des écritures sync.

Erreur 4 : définir des propriétés globales et appeler ça « standardisation »

Symptômes : une équipe est contente, une autre est en feu ; les graphiques de stockage semblent « ok » mais les SLO produits échouent.

Pourquoi : des charges mixtes nécessitent des politiques mixtes. ZFS vous donne un contrôle par dataset pour une raison.

Correction : définissez des classes de charge et appliquez des propriétés en conséquence : DB vs sauvegarde vs VM vs répertoires home.

Erreur 5 : ignorer la saturation de la pool parce que « le SLOG est rapide »

Symptômes : la latence sync est initialement bonne, puis se dégrade avec le temps ; tempêtes périodiques lors du scrub/resilver ; « pauses aléatoires ».

Pourquoi : les commits TXG doivent toujours atterrir. Une pool saturée devient finalement le problème de tout le monde.

Correction : ajoutez des vdevs, repensez la disposition, réduisez la fragmentation, séparez les charges, ou migrez vers des médias plus rapides. logbias ne peut pas fabriquer des IOPS.

FAQ

1) Est-ce que `logbias=throughput` désactive le ZIL ?

Non. Le ZIL existe toujours et ZFS fournit toujours les sémantiques synchrones. logbias influence la préférence de ZFS pour certains schémas d’écritures sync, surtout les grosses, mais n’enlève pas les garanties de cohérence.

2) Si j’ai un SLOG, dois-je toujours utiliser `logbias=latency` ?

Pour les charges sync sensibles à la latence, oui, c’est généralement le bon choix par défaut. Pour les datasets massifs avec de grosses écritures sync, logbias=throughput peut réduire la pression sur le log et améliorer le débit agrégé. La bonne réponse est « par dataset, par charge, mesurée. »

3) Ajouter un SLOG plus rapide améliorera-t-il le débit de ma base de données ?

Ça peut augmenter le taux de transactions si la base est limitée par la latence de fsync() et que vous êtes bottlenecké par des écritures stables lentes. Mais ça ne réparera pas des plans de requête médiocres, une RAM insuffisante, ou une pool saturée. Mesurez la latence de commit avant d’acheter du matériel.

4) Quelle est la différence entre ZIL et SLOG en une phrase ?

Le ZIL est le mécanisme de journal d’intention qui existe toujours ; le SLOG est un périphérique séparé que vous fournissez optionnellement pour que les écritures ZIL atterrissent quelque part de plus rapide (et idéalement plus sûr) que la pool principale.

5) Est-il sûr de fonctionner sans SLOG ?

Oui, dans le sens où la cohérence est toujours garantie : les enregistrements ZIL seront écrits dans la pool principale. Les performances peuvent souffrir pour les charges sync-intensives parce que les périphériques de la pool doivent gérer le chemin d’acquittement synchrone.

6) Dois-je mettre mon SLOG en miroir ?

Si le service compte et que le comportement de la plateforme rend la perte d’un périphérique de log disruptive, le miroir est le choix raisonnable. La performance est rarement la raison de mettre en miroir ; c’est la disponibilité. En production, la disponibilité gagne généralement.

7) `logbias` peut-il corriger les « pauses aléatoires » NFS ?

Parfois. Si les pauses sont dues à la latence d’acquittement des écritures synchrones et que votre périphérique de log est le goulot (ou manquant), régler logbias et/ou ajouter un SLOG approprié peut aider. Si les pauses proviennent de la saturation de la pool, de problèmes réseau, ou du comportement côté client, non.

8) Dois-je utiliser `sync=disabled` au lieu de toucher à `logbias` ?

Uniquement si vous choisissez explicitement de risquer la perte de données en cas de panne ou crash, et que les propriétaires applicatifs acceptent que la durabilité soit optionnelle. Pour la plupart des systèmes de production, sync=disabled n’est pas une option de tuning ; c’est une décision de politique avec conséquences.

9) Comment savoir si mon application effectue des écritures sync ?

Regardez l’augmentation des compteurs de commit ZIL, une activité d’écriture élevée sur le vdev de log, et des benchmarks qui changent radicalement quand vous forcez fdatasync/fsync. Vérifiez aussi les réglages applicatifs (modes de durabilité de la base) et les sémantiques des protocoles (écritures stables NFS, barrières de virtualisation).

10) Si mon SLOG est rapide, pourquoi ma pool est-elle toujours occupée ?

Parce que le SLOG vous aide seulement à accuser rapidement réception des écritures synchrones. Les données doivent toujours être écrites à leur emplacement final lors du commit TXG. Si la pool est sous-dimensionnée, fortement fragmentée, ou partage des charges mixtes, elle peut rester le goulot à long terme.

Conclusion

logbias n’est pas un réglage « boost de performance ». C’est une déclaration de priorités. Quand vous mettez logbias=latency, vous dites : « Je tiens à la rapidité d’acquittement des écritures synchrones, et j’ai construit le système — en particulier le SLOG — pour que ce soit sûr et rapide. » Quand vous mettez logbias=throughput, vous dites : « Je tiens à déplacer les données efficacement, et je suis prêt à sacrifier un peu de temps de réponse par écriture pour éviter de transformer le chemin du log en un second travail. »

Les systèmes qui tournent bien en production ne choisissent pas une seule idéologie. Ils choisissent par charge, mesurent les bonnes métriques (y compris la latence de queue), et gardent les parties ennuyeuses — PLP, miroir, supervision — non négociables. Si vous faites cela, logbias cesse d’être une propriété mystérieuse et redevient ce qu’elle aurait dû être dès le départ : un choix délibéré.