Vous avez acheté un SSD SATA « rapide », l’avez ajouté comme SLOG ZFS et espéré des miracles. À la place, vous avez obtenu un NFS plus lent, une latence VM instable,
ou — pire — une augmentation silencieuse du risque qui ne se révèle qu’au premier incident d’alimentation qui compte.
Un SLOG n’est pas un cache. Ce n’est pas un bouton turbo. C’est une promesse que vous faites aux applications : « cette écriture est sûre maintenant ».
Si vous tenez cette promesse avec un SSD SATA grand public, vous misez votre production sur un périphérique qui n’a jamais été conçu pour ce type d’engagement.
Ce que fait réellement un SLOG (et ce qu’il ne fait pas)
ZFS a deux concepts liés qui sont confondus dans les discussions : le ZIL (ZFS Intent Log) et le SLOG
(Separate LOG device).
ZIL : le journal d’intention dans le pool qui existe de toute façon
Le ZIL n’est pas une « fonctionnalité optionnelle ». Il fait partie de la façon dont ZFS fournit la sémantique POSIX pour les écritures synchrones.
Quand une application appelle fsync(), utilise O_SYNC, ou quand un protocole exige des écritures stables (bonjour, NFS), ZFS ne peut accuser réception
qu’après que les données sont protégées contre un crash.
Pour les écritures synchrones, ZFS écrit d’abord des enregistrements de transaction dans le ZIL. Plus tard, lors du commit normal du groupe de transactions (TXG),
les données sont écrites à leur emplacement final dans le pool. En cas de crash/redémarrage, ZFS rejoue le ZIL pour récupérer les dernières écritures synchrones reconnues.
SLOG : déplacer le ZIL vers un périphérique dédié
Par défaut, le ZIL se trouve dans le pool principal, réparti sur les vdevs de niveau supérieur. Ajouter un SLOG indique à ZFS : « placez les enregistrements du ZIL ici à la place ».
L’objectif est de réduire la latence des écritures synchrones et d’atténuer la pénalité d’écriture aléatoire des charges synchrones.
Cela n’aide que si votre charge émet des écritures synchrones. Si votre charge est majoritairement asynchrone (écritures en bulk typiques, nombreuses bases de données réglées pour l’async,
stockage média), un SLOG est un décoratif sur un monospace.
Ce qu’un SLOG n’est pas
- Ce n’est pas un L2ARC. Il ne met pas en cache les lectures.
- Ce n’est pas un cache write-back. Il n’absorbe pas toutes les écritures ; il accélère seulement l’accusé de réception des écritures synchrones.
- Ce n’est pas un cadeau de performance. Un mauvais SLOG peut aggraver la latence et augmenter le rayon d’impact des défaillances.
Le pattern d’écriture du SLOG est brutal : petites écritures, majoritairement séquentielles, sensibles à la latence et qui doivent être durables immédiatement.
Le périphérique doit respecter les flushs. Il doit disposer d’une protection contre la perte d’alimentation ou d’une durabilité équivalente.
Et il ne doit pas se bloquer sous une pression soutenue de fsync.
Blague n°1 : Utiliser un SSD SATA grand public comme SLOG, c’est comme utiliser un coussin de voyage comme casque de moto — souple, optimiste et dangereux à grande vitesse.
Pourquoi le SLOG sur SSD SATA déçoit ou échoue si souvent
L’argument de la mise à niveau bon marché est séduisant : « j’ai un SSD SATA en spare. Ajoute-le comme log. Les écritures sync vont plus vite. » Parfois on obtient un petit gain.
Souvent on obtient un chaos. Voici pourquoi.
1) Les SSD SATA mentent (ou du moins, négocient)
Le SLOG n’est aussi bon que la capacité du périphérique à rendre les écritures durables sur demande. En termes ZFS, cela signifie honorer les flushs de cache
et ne pas accuser réception tant que les données ne sont pas dans un média non volatile.
Beaucoup de SSD grand public ont des caches DRAM volatils et des niveaux variables de discipline firmware autour des commandes de flush. Certains sont excellents.
D’autres sont « corrects jusqu’à ce qu’ils ne le soient plus ». Le pire cas est un disque qui confirme rapidement mais perd les dernières secondes d’écritures lors d’une perte d’alimentation.
Pour un SLOG, c’est catastrophique : ZFS rejouera le ZIL au redémarrage, mais si le SLOG a perdu des enregistrements de log accusés, vous avez créé
une fenêtre de corruption silencieuse ou d’incohérence côté application.
2) La latence compte plus que la bande passante, et SATA est mauvais en latence sous pression
La performance des écritures synchrones est dominée par la latence tail. Un SLOG qui fait 50 000 IOPS dans un benchmark mais qui s’interrompt
occasionnellement pour du garbage collection, de la maintenance firmware, ou parce que le cache SLC pseudo-local est épuisé transformera « rapide » en « en rafales ».
Le protocole et les files d’attente de SATA sont aussi limités comparés au NVMe. Vous n’achetez pas seulement du débit ; vous achetez un meilleur comportement
sous des charges flush-intensives et parallèles.
3) L’endurance et l’amplification d’écriture apparaissent plus tôt que prévu
Un SLOG voit un flux constant de petites écritures. ZFS écrit des enregistrements de log, puis les jette après le commit du TXG.
Ce churn peut produire de l’amplification d’écriture et une usure soutenue.
Les disques SATA grand public ont souvent des indices d’endurance plus faibles et des performances d’écriture soutenue plus faibles une fois leur cache pseudo-SLC épuisé.
Le mode de défaillance n’est pas toujours « le disque meurt ». Souvent c’est : la latence se dégrade, puis vous commencez à voir des timeouts applicatifs,
puis quelqu’un désactive sync pour « régler » le problème, et maintenant vous roulez sans filet de sécurité.
4) Le « SLOG bon marché unique » est un point unique de dramatisation
ZFS peut fonctionner sans SLOG. Si le périphérique de log échoue, le pool continue généralement, mais vous pouvez perdre les dernières écritures synchrones
reconnues (parce qu’elles n’étaient que sur le SLOG défaillant).
Mirrorer le SLOG élimine cette catégorie de risque, mais alors votre « mise à niveau bon marché » nécessite deux périphériques — et vous devez toujours qu’ils soient
sûrs face à une perte d’alimentation et stables sous flush.
5) Vous n’avez peut-être pas du tout un problème de sync
Beaucoup de douleurs de performance ZFS ne viennent pas du ZIL. C’est un ARC sous-dimensionné, un mauvais recordsize, des vdevs HDD fragmentés,
trop de petits I/O sur RAIDZ, un CPU saturé par checksumming/compression, ou une pile hyperviseur mal configurée pour le sync.
Ajouter un SLOG à un système déjà limité en IOPS ailleurs est un classique « outil appliqué à la mauvaise plaie ».
Faits et contexte historique à connaître
Quelques points concrets — un peu d’histoire, un peu d’ingénierie — qui aident à couper à travers les mythes. Ce ne sont pas des anecdotes ; ils changent les décisions.
- ZFS a été conçu chez Sun au milieu des années 2000 avec un accent explicite sur l’intégrité des données : checksums de bout en bout et copy-on-write n’étaient pas des options.
- Le ZIL existe même sans SLOG ; ajouter un périphérique de log ne fait que le déplacer. Les personnes qui « ajoutent un SLOG pour des écritures plus rapides » se trompent souvent.
- NFS traite traditionnellement de nombreuses opérations comme synchrones (ou exige des sémantiques de stockage stable), d’où l’intérêt du SLOG dans les environnements NFS.
- Les premières générations de SSD rendaient le comportement des flushs notoirement incohérent ; des bugs firmware autour des barrières d’écriture et du FUA ont causé des années de « ça passe au benchmark » surprises.
- La profondeur de file et le surcoût du protocole SATA sont limités comparés au NVMe ; cela compte surtout pour les patterns flush-intensifs et les I/O parallèles.
- La protection contre la perte d’alimentation (PLP) était historiquement une caractéristique entreprise car elle nécessite du matériel (condensateurs) et une validation ; les disques grand public l’omettent souvent ou offrent des mesures partielles.
- Les TXG de ZFS se commitent typiquement toutes les quelques secondes (paramétrable), ce qui définit combien de temps les enregistrements de log peuvent vivre avant d’être supprimés — écritures courtes, forte rotation.
- « Désactiver sync » est devenu un remède populaire dans les piles de virtualisation parce que cela rend les benchmarks beaux ; cela rend aussi la récupération après crash ressemblant à une scène de crime.
Modes de défaillance : performance, cohérence et « tout semblait OK »
Défaillance de performance : le SLOG devient le goulot
Quand vous ajoutez un SLOG, les opérations synchrones doivent toucher ce périphérique de log. Si ce périphérique a une latence plus élevée que le meilleur chemin sync du pool
(par exemple, un pool de SSD décents, ou même un miroir de HDD bien compris), vous pouvez ralentir les écritures synchrones.
Symptôme classique : les écritures régulières du pool vont bien, les lectures vont bien, mais tout ce qui appelle fsync monte en pic à des dizaines ou centaines de millisecondes par intermittence.
Défaillance de cohérence : accuser réception d’écritures qui ne sont pas vraiment durables
Le scénario cauchemardesque est un disque qui renvoie le succès avant que les données soient réellement en sécurité. Avec un SLOG, ZFS utilise ce « succès » pour
dire aux applications « votre écriture synchrone est sûre ». Si l’alimentation tombe et que le disque perd ces enregistrements reconnus, ZFS ne peut pas rejouer ce qu’il n’a jamais reçu.
Le pool s’importera. Il peut même sembler sain. C’est votre application qui découvrira des transactions de dernière seconde manquantes ou corrompues.
Les gens demandent : « ZFS ne protège pas contre ça ? » ZFS protège contre beaucoup de choses. Il ne peut pas rendre un périphérique mentant honnête.
Défaillance de fiabilité : le SLOG meurt et vous perdez les dernières écritures sûres
Un SLOG non miroré est un seul périphérique qui se tient entre vous et la perte des écritures synchrones reconnues pendant la fenêtre de défaillance du périphérique.
Même si vous acceptez le risque, la réalité opérationnelle est plus laide : quand un SLOG commence à échouer, il échoue souvent en bloquant les I/O,
provoquant des tempêtes de latence à l’échelle du système. Maintenant vous dépannez en production pendant que la file d’attente de votre hyperviseur se remplit.
Défaillance opérationnelle : quelqu’un « répare » en désactivant sync
C’est là où la mise à niveau bon marché s’arrête souvent. Une équipe ajoute un SLOG SATA, voit une latence pire, bascule sync=disabled sur un dataset,
célèbre, et change sans le savoir les sémantiques de durabilité pour chaque VM ou client NFS qui utilise ce dataset.
Paraphrase d’une idée de Werner Vogels : « Tout échoue, tout le temps — concevez vos systèmes en partant de cette réalité. »
Mode opératoire de diagnostic rapide
Vous voulez trouver le goulot rapidement, sans réglages basés sur la croyance. Voici un ordre d’opérations pratique.
Première étape : prouvez que vous avez une charge sync
- Vérifiez les propriétés
syncdes datasets ZFS. - Vérifiez le comportement des applications/protocoles (exports NFS, réglages hyperviseur, patterns fsync des bases de données).
- Exécutez un test contrôlé d’écriture synchrone et comparez avec de l’asynchrone.
Deuxième étape : mesurez la latence et la saturation du SLOG
- Utilisez
iostatpour voir si le périphérique de log est le disque le plus sollicité pendant l’incident. - Recherchez des pics dans
await/ temps de service sur le SLOG. - Vérifiez si le SLOG est un SSD SATA avec un comportement de flush douteux ou sans PLP.
Troisième étape : confirmez la santé du pool et le comportement TXG
- Vérifiez qu’aucun vdev n’est dégradé ou en cours de resilver.
- Recherchez une amplification des écritures sync due à de petits blocs / mismatch de recordsize.
- Surveillez les temps de commit TXG et les limites de données dirty si vous suspectez des blocages.
Quatrième étape : décidez de supprimer, mirrorer ou remplacer le SLOG
- Si le SLOG est plus lent que le pool : retirez-le.
- Si vous avez besoin d’un SLOG pour les sémantiques NFS/VM : remplacez par NVMe PLP ou SATA entreprise avec condensateurs ; mirror-le si la charge importe.
- Si vous n’avez pas besoin d’accélération sync : ne mettez pas de SLOG « juste parce que ».
Tâches pratiques : commandes, sorties et décisions
Voici des tâches réelles que vous pouvez exécuter sur un hôte Linux utilisant OpenZFS. Chacune inclut ce que la sortie signifie et la décision à prendre.
Utilisez une fenêtre de test si vous changez des propriétés ; les commandes ci-dessous sont principalement en lecture sauf indication contraire.
Tâche 1 : Identifier si un SLOG existe et quel périphérique c’est
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
sdz ONLINE 0 0 0
errors: No known data errors
Sens : Il y a un vdev de log dédié (sdz). C’est votre SLOG.
Décision : Si sdz est un SSD SATA grand public, considérez-le comme suspect jusqu’à preuve du contraire.
Tâche 2 : Confirmer le réglage sync du dataset (et trouver des overrides « utiles »)
cr0x@server:~$ sudo zfs get -r sync tank
NAME PROPERTY VALUE SOURCE
tank sync standard default
tank/vmstore sync standard local
tank/nfs sync disabled local
Sens : tank/nfs a sync=disabled, ce qui change les sémantiques de cohérence.
Décision : Si cela a été fait pour « réparer la performance », traitez-le comme un risque en production et planifiez un retour en arrière avec un vrai SLOG ou un changement de charge.
Tâche 3 : Déterminer si le périphérique de log est SATA et quel modèle c’est
cr0x@server:~$ lsblk -d -o NAME,ROTA,TRAN,MODEL,SIZE,SERIAL | grep -E 'sdz|nvme'
sdz 0 sata CT500MX500SSD1 465.8G 2219E5A1B2C3
Sens : Le SLOG est un SATA Crucial MX500 (SSD grand public courant).
Décision : Supposez l’absence de PLP. Planifiez de valider le comportement de flush et la latence sous charge sync ; envisagez fortement de le remplacer par un périphérique avec PLP.
Tâche 4 : Vérifier si le disque affirme avoir un cache d’écriture volatile
cr0x@server:~$ sudo hdparm -W /dev/sdz
/dev/sdz:
write-caching = 1 (on)
Sens : Le cache d’écriture est activé. Ce n’est pas automatiquement mauvais si le disque a une PLP ; c’est dangereux si ce n’est pas le cas.
Décision : Si c’est un SSD grand public sans PLP, ne lui faites pas confiance comme périphérique de durabilité pour les accusés synchrones.
Tâche 5 : Récupérer les détails SMART et chercher des indices de protection perte d’alimentation
cr0x@server:~$ sudo smartctl -a /dev/sdz | sed -n '1,60p'
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron MX500 SSDs
Device Model: CT500MX500SSD1
Serial Number: 2219E5A1B2C3
Firmware Version: M3CR046
User Capacity: 500,107,862,016 bytes [500 GB]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s
Local Time is: Thu Dec 26 11:02:41 2025 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Sens : SMART identifie une famille de SSD grand public SATA. SMART confirme rarement « PLP » directement sur du SATA grand public.
Décision : Traitez l’absence d’un support PLP explicite comme « pas de PLP ». Pour un SLOG, cela vous pousse vers un remplacement ou une suppression.
Tâche 6 : Vérifier l’usure et les erreurs média sur le SLOG potentiel
cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Media_Wearout|Percent_Lifetime|Reallocated|Uncorrect|CRC|Wear|Errors'
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Percent_Lifetime_Remain|Power_Loss'
Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
Sens : Pas d’erreurs média évidentes. Cela ne signifie pas qu’il convient comme SLOG ; cela signifie juste qu’il ne meurt pas bruyamment.
Décision : Si vous voyez des erreurs CRC, suspectez le câblage/backplane — corrigez cela avant d’accuser ZFS.
Tâche 7 : Surveiller la latence par disque pendant la fenêtre d’incident
cr0x@server:~$ sudo iostat -x 1
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 2.0 18.0 64.0 980.0 98.0 1.20 22.3 8.1 24.0 1.8 36.0
sdz 0.0 420.0 0.0 2100.0 10.0 12.50 29.8 0.0 29.8 0.2 98.0
Sens : Le périphérique de log sdz est presque saturé avec de petites écritures (avgrq-sz ~10KB), et son await est élevé.
Décision : Votre SLOG est le goulot. Remplacez-le par un périphérique PLP à faible latence, mirror-le, ou retirez-le pour revenir au ZIL en pool.
Tâche 8 : Confirmer que des écritures sync ont bien lieu
cr0x@server:~$ sudo zpool iostat -v tank 1
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 4.22T 6.58T 120 980 9.8M 44.1M
raidz2-0 4.22T 6.58T 120 910 9.8M 40.7M
sda - - 20 150 1.7M 6.8M
sdb - - 20 150 1.6M 6.8M
sdc - - 20 150 1.6M 6.8M
sdd - - 20 150 1.6M 6.8M
sde - - 20 155 1.7M 6.8M
sdf - - 20 155 1.6M 6.7M
logs - - 0 70 0K 3.4M
sdz - - 0 70 0K 3.4M
Sens : Le vdev de log reçoit activement des écritures. Cela suggère fortement une activité sync.
Décision : Si vous attendiez de l’async, trouvez qui (NFS, hyperviseur, appli) force le sync. Réparez la charge ou fournissez un SLOG adapté.
Tâche 9 : Mesurer la latence écriture sync vs async avec fio (prudemment)
Exécutez ceci sur un dataset de test, pas directement sur des chemins de production à moins de savoir ce que vous faites.
cr0x@server:~$ sudo fio --name=syncwrite --directory=/tank/test --rw=write --bs=4k --iodepth=1 --numjobs=1 --size=512M --fsync=1 --direct=1
syncwrite: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
write: IOPS=620, BW=2480KiB/s (2540kB/s)(512MiB/211498msec)
lat (usec): min=450, max=85000, avg=1600.12, stdev=4100.55
Sens : La latence des écritures sync a de vilains pics tail (max 85ms). C’est ce que ressentent les utilisateurs.
Décision : Si la latence max est élevée et corrélée à la saturation du SLOG, remplacez/supprimez le SLOG plutôt que d’essayer de bricoler autour.
Tâche 10 : Valider si le SLOG est miroré (il devrait l’être, si cela a de l’importance)
cr0x@server:~$ sudo zpool status tank | sed -n '1,40p'
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
logs
sdz ONLINE 0 0 0
Sens : SLOG mono-périphérique. S’il échoue, vous risquez de perdre les dernières écritures synchrones reconnues.
Décision : Si votre activité tient à ces écritures (stockage VM, NFS pour répertoires utilisateurs, bases de données), miroirez le SLOG ou n’en utilisez pas.
Tâche 11 : Vérifier si le pool est en cours de resilver/scrub (indicateur de surcharge)
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 10:41:01 2025
1.92T scanned at 1.34G/s, 512G issued at 356M/s, 4.22T total
0B repaired, 12.13% done, 02:45:19 to go
config:
...
Sens : Un scrub est en cours. Cela peut amplifier les problèmes de latence, surtout sur des pools HDD.
Décision : Si la plainte de performance coïncide avec scrub/resilver, arrêtez les réglages et retestez après la fin de la maintenance.
Tâche 12 : Déterminer si le dataset utilise de petits blocs qui pénalisent RAIDZ
cr0x@server:~$ sudo zfs get recordsize,volblocksize,compression tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore recordsize 128K local
tank/vmstore volblocksize - -
tank/vmstore compression lz4 local
Sens : Si c’est un dataset d’images VM basé sur des fichiers, 128K peut aller, mais souvent vous voulez des blocs plus petits pour les I/O aléatoires.
Décision : Si votre problème est des écritures sync aléatoires sur RAIDZ, envisagez des miroirs pour les workloads VM ou ajustez l’approche de stockage VM — n’attendez pas d’un SLOG SATA qu’il sauve la physique de RAIDZ.
Tâche 13 : Vérifier si votre SLOG est réellement utilisé (et non contourné)
cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
version: 5000
name: 'tank'
...
vdev_tree:
type: 'root'
id: 0
guid: 12345678901234567890
children[0]:
type: 'raidz'
...
children[1]:
type: 'log'
id: 1
guid: 998877665544332211
children[0]:
type: 'disk'
path: '/dev/disk/by-id/ata-CT500MX500SSD1_2219E5A1B2C3'
Sens : La configuration du pool inclut un vdev de log. ZFS l’utilisera pour les écritures sync sauf si désactivé au niveau dataset ou d’autres contraintes.
Décision : Si vous attendiez un log miroré mais voyez un seul enfant, vous avez trouvé une erreur de conception, pas un réglage.
Tâche 14 : Retirer un SLOG problématique (si vous décidez qu’il vous nuit)
Ceci change le comportement. Planifiez-le. Communiquez-le. Et rappelez-vous : retirer le SLOG n’« éteint » pas le ZIL ; il le renvoie dans le pool.
cr0x@server:~$ sudo zpool remove tank sdz
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
errors: No known data errors
Sens : Le log dédié a disparu. Les écritures synchrones retournent au ZIL en pool.
Décision : Si la latence s’améliore immédiatement, le SLOG SATA était votre goulot. L’étape suivante est soit « pas de SLOG », soit « SLOG PLP miroré approprié ».
Tâche 15 : Si vous devez avoir un SLOG, ajoutez-le en miroir, en utilisant des IDs de périphérique stables
cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B
cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
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
nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A ONLINE 0 0 0
nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B ONLINE 0 0 0
errors: No known data errors
Sens : SLOG miroré utilisant des NVMe (exemple). C’est la bonne structure pour la fiabilité.
Décision : Si vous ne pouvez pas vous permettre deux périphériques appropriés, vous ne pouvez pas vous permettre de SLOG pour des charges sync importantes. Fonctionnez sans.
Trois mini-histoires d’entreprise tirées du terrain
Mini-histoire n°1 : Un incident causé par une fausse hypothèse
Une entreprise de taille moyenne a consolidé quelques vieux NAS en un serveur ZFS flambant neuf. Ils utilisaient NFS pour les répertoires utilisateurs et les sorties de build.
Quelqu’un a lu que « SLOG accélère les écritures » et a ajouté un SSD SATA grand public comme périphérique de log. Ils ont fait un test rapide de copie de fichiers, n’ont vu aucun régression évidente,
et sont passés à autre chose. Tout le monde aime une victoire rapide. Tout le monde aime une case cochée.
Quelques semaines plus tard, un court incident d’alimentation a touché le rack — transfert UPS, pas une coupure totale. Le serveur est resté en ligne. Le SSD SATA ne l’a pas été.
Il a disparu du bus un moment puis est revenu. ZFS n’a pas paniqué immédiatement ; le pool est resté en ligne. L’équipe a poussé un soupir de soulagement.
Le lendemain, des développeurs se sont plaints de builds « aléatoires » et d’artéfacts corrompus. Rien n’était systématiquement cassé.
Relancer le même build réussissait. C’est le pire type de défaillance : intermittent, démoralisant et difficile à reproduire.
Le détail clé était l’hypothèse : ils croyaient que le SLOG était « juste pour la performance », pas pour la durabilité. Ils croyaient aussi qu’un SSD est intrinsèquement plus sûr que des disques rotatifs.
Mais le SLOG était l’unique emplacement où vivaient ces enregistrements synchrones reconnus jusqu’au commit TXG.
Quand le périphérique a eu un comportement erratique pendant une anomalie d’alimentation, certaines écritures reconnues du log ne sont jamais arrivées.
La réparation n’a pas été héroïque. Ils ont retiré le SLOG, forcé les clients à remonter, et arrêté le motif de corruption. Plus tard ils ont ajouté un périphérique de log miroré,
sûr contre la perte d’alimentation, et documenté pourquoi il existait. La leçon est restée parce que l’incident a été assez douloureux pour marquer, sans être catastrophique.
Mini-histoire n°2 : Une « optimisation » qui a mal tourné
Un cluster de virtualisation hébergeait des charges mixtes : quelques bases de données sensibles à la latence, beaucoup de VM générales. L’équipe stockage a vu des pics périodiques de fsync.
Ils ont ajouté un SLOG SATA au backend ZFS en espérant aplatir ces pics.
Au départ, la latence médiane s’est légèrement améliorée. L’équipe a célébré. Puis la clôture mensuelle est arrivée et le pattern réel a changé :
beaucoup de transactions sync concurrentes. Le disque SLOG a atteint ses limites d’écriture soutenue, le cache pseudo-SLC a été épuisé, et la latence d’écriture est passée de « globalement acceptable » à « instable et parfois terrible ».
Les VM ne se sont pas seulement ralenties ; elles ont synchronisé leur misère. Quand le SLOG se bloquait, il bloquait les accusés synchrones pour de nombreuses VM,
provoquant la mise en file des OS invités, des timeouts applicatifs, des retries qui ont accru la pression d’écriture. Les tempêtes de latence ont une capacité à s’auto-entretenir.
Quelqu’un a proposé le correctif classique : désactiver sync sur le zvol qui alimente le stockage VM. Les graphes ont l’air fantastiques.
Cela a aussi transformé une charge crash-consistante en un « bonne chance ». Une semaine plus tard, un panic hôte a forcé un redémarrage.
Une base de données est revenue avec des erreurs de récupération coûteuses à diagnostiquer et impossibles à « prouver » complètement après coup.
Ils ont annulé l’« optimisation », retiré le SLOG SATA, et plus tard installé un SLOG NVMe PLP miroré. La vraie solution n’était pas « un SSD plus rapide ».
C’était une latence stable et des sémantiques correctes, plus une politique claire : personne ne désactive sync sans acceptation de risque signée.
Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une autre organisation utilisait ZFS pour NFS et iSCSI avec un mix de miroirs HDD et miroirs SSD. Ils avaient un SLOG — mais il était miroré, et composé de disques entreprise avec protection contre la perte d’alimentation.
Le choix semblait extravagant comparé à un SSD SATA bon marché. Il ne l’était pas.
Ce qui les distinguait n’était pas seulement le matériel ; c’était le processus. Ils traitaient le SLOG comme un composant de durabilité, pas comme un jouet de performance.
Ils suivaient la SMART, exécutaient des exercices mensuels d’injection de défauts pendant une fenêtre de maintenance : retirer un périphérique SLOG, confirmer que le pool reste sain,
confirmer que la latence reste acceptable, remplacer, resilver, répéter.
Un jour, un bug firmware a fait qu’un périphérique SLOG a commencé à lancer des erreurs. La surveillance a déclenché tôt — avant que les utilisateurs ne hurlent. Ils ont mis le périphérique hors ligne proprement,
l’ont remplacé, et ont continué à fonctionner sur la jambe restante du miroir. Pas de perte de données. Impact de latence minimal. Un ticket, un remplacement, et terminé.
L’incident n’est jamais devenu une histoire interne parce qu’il n’est jamais devenu dramatique. C’est le point. L’ennuyeux est une fonctionnalité en stockage.
Erreurs fréquentes : symptôme → cause racine → correctif
1) Symptôme : « Ajouter un SLOG a rendu le NFS plus lent »
Cause racine : Le SLOG SATA a une latence fsync pire que le chemin ZIL en pool, surtout sous charge ou pendant le garbage collection.
Correctif : Retirez le SLOG et retestez ; si vous avez besoin de SLOG, remplacez-le par un périphérique PLP à faible latence (de préférence miroré).
2) Symptôme : « Des pics de latence toutes les quelques minutes »
Cause racine : Maintenance firmware du SSD, épuisement du cache SLC pseudo-local, ou rafales liées au TXG interagissant avec un SLOG saturé.
Correctif : Observez iostat -x pour le %util et await du SLOG. Si le SLOG est saturé, remplacez-le ou retirez-le.
3) Symptôme : « C’est rapide en benchmark, les utilisateurs se plaignent encore »
Cause racine : Vous avez benchmarké le débit, mais les utilisateurs ressentent la latence tail. Les workloads sync se préoccupent du 1% le plus lent.
Correctif : Utilisez fio --fsync=1 avec faible iodepth et suivez la latence maximale ; résolvez la latence tail, pas le débit pic.
4) Symptôme : « Nous avons désactivé sync et tout s’est amélioré »
Cause racine : Vous avez supprimé l’obligation de rendre les écritures durables avant l’accusé. La performance « s’améliore » parce que vous avez changé le contrat.
Correctif : Réactivez sync pour les datasets qui ont besoin de cohérence ; déployez un SLOG approprié ou redessinez la charge (par ex. cache local, journalisation côté application).
5) Symptôme : « Après un incident d’alimentation, les données applicatives sont incohérentes »
Cause racine : Le SLOG non PLP a perdu des écritures reconnues, ou le disque a menti sur le flush. ZFS ne peut pas rejouer ce qui n’a jamais été persisté.
Correctif : Arrêtez d’utiliser du SATA grand public comme SLOG. Utilisez des périphériques PLP ; miroirez le SLOG ; revoyez l’UPS et la politique de cache d’écriture.
6) Symptôme : « Le pool s’importe bien, mais les dernières transactions manquent »
Cause racine : Les accusés sync ont été faits sur la base d’un SLOG qui n’a pas persisté.
Correctif : Traitez comme incident de durabilité. Auditez l’historique des propriétés sync des datasets et le matériel SLOG. Remplacez par un miroir PLP, puis validez les procédures de récupération.
7) Symptôme : « Le disque SLOG se déconnecte souvent du bus SATA »
Cause racine : Problèmes de câblage/backplane, instabilité d’alimentation, ou firmware du SSD grand public mal adapté aux patterns de flush soutenus.
Correctif : Réparez le chemin matériel (câbles, firmware HBA, alimentation), puis arrêtez d’utiliser ce modèle comme périphérique de log. Un SLOG instable vaut moins que pas de SLOG.
8) Symptôme : « L’usure du SLOG augmente rapidement »
Cause racine : Taux élevé d’écritures synchrones + amplification d’écriture ; l’endurance consommateur est insuffisante.
Correctif : Utilisez des disques d’endurance entreprise pour le log, dimensionnez correctement, et surveillez l’usure ; envisagez de modifier la charge pour réduire les fsync forcés (là où c’est sûr).
Blague n°2 : Désactiver sync pour « réparer » la latence SLOG, c’est comme enlever l’alarme incendie parce qu’elle est trop bruyante.
Listes de contrôle / plan étape par étape
Étape par étape : décider si vous devez avoir un SLOG du tout
- Listez les consommateurs du dataset. NFS ? Images VM ? Bases de données ? Identifiez qui émet des écritures synchrones.
- Vérifiez les propriétés des datasets. Si
sync=disabledest présent quelque part, signalez-le comme risque. - Mesurez la latence des écritures sync sans SLOG. Si elle est déjà acceptable, n’ajoutez pas de complexité.
- Si vous avez besoin d’un SLOG, définissez le contrat. Accélérez-vous les écritures sync pour la cohérence, ou masquez-vous un problème d’architecture ?
Étape par étape : si vous avez déjà installé un SLOG SSD SATA
- Identifiez le périphérique et le modèle. Si c’est consommateur, supposez « pas de PLP ».
- Vérifiez s’il est miroré. Si non, documentez le risque et priorisez la remédiation.
- Observez sous charge. Surveillez
iostat -xetzpool iostat -vpendant des périodes sync-intensives. - Exécutez un test fio sync contrôlé. Suivez la latence maximale et le jitter, pas seulement les IOPS.
- Prenez la décision : retirez-le ou remplacez-le par des périphériques PLP mirorés.
Étape par étape : construire une configuration SLOG correcte (celle que vous ne regretterez pas)
- Choisissez des périphériques conçus pour des écritures durables et faible latence. PLP est la caractéristique clé ; la latence constante est la caractéristique cachée.
- Utilisez deux périphériques en miroir. Si vous ne pouvez pas, acceptez que vous avez choisi le « risque » comme fonctionnalité.
- Utilisez des chemins de périphérique stables. Préférez
/dev/disk/by-id/..., pas/dev/sdX. - Testez la bascule. Mettez un périphérique de log hors ligne pendant une fenêtre de maintenance ; confirmez que le pool reste sain et que la latence demeure acceptable.
- Surveillez l’usure et les erreurs. Définissez des alertes pour la SMART, les erreurs média et les reset bus.
Checklist opérationnelle : éléments à documenter pour que le vous du futur ne souffre pas
- Quels datasets exigent les sémantiques sync et pourquoi (exports NFS, stockages VM, volumes de bases de données).
- Le comportement attendu si le SLOG échoue (quel risque existe, quelles alertes se déclenchent, quelles procédures d’intervention).
- Comment retirer/remplacer le SLOG en toute sécurité.
- Qui est autorisé à changer les propriétés
syncet sous quelle approbation.
FAQ
1) Un SLOG accélérera-t-il toutes les écritures sur ZFS ?
Non. Il n’aide que les écritures synchrones. Les écritures asynchrones contournent le SLOG et passent par le buffering normal du TXG et le commit.
2) Comment savoir si ma charge est sync-intensive ?
Recherchez des écritures lourdes sur le vdev de log via zpool iostat -v. Confirmez les réglages sync des datasets.
Pour NFS et de nombreuses piles VM, supposez une part significative de sync à moins d’avoir vérifié les réglages client/serveur.
3) Utiliser un SSD SATA grand public comme SLOG est-ce toujours une mauvaise idée ?
Pour des expérimentations homelab non critiques, oui. En production quand la cohérence des données compte, c’est généralement un mauvais pari.
Le risque est la durabilité et les pics de latence, pas seulement la vitesse brute.
4) Quelle est la différence entre ZIL et SLOG ?
Le ZIL est le mécanisme. Le SLOG est un périphérique dédié où sont stockés les enregistrements du ZIL. Sans SLOG, le ZIL vit dans le pool.
5) Le SLOG doit-il être miroré ?
Si vous tenez à ce que les écritures synchrones reconnues survivent à la défaillance d’un périphérique, oui. Un SLOG unique est un point unique de perte de « ces écritures ».
6) Si le SLOG meurt, est-ce que je perds tout le pool ?
En général non ; le pool peut continuer ou s’importer sans le périphérique de log selon le timing de la défaillance et la configuration. Le danger réel est la perte des dernières écritures synchrones reconnues.
7) Pourquoi ne pas simplement mettre sync=disabled et oublier le problème ?
Parce que vous changez le contrat de stockage. Les bases de données, les fichiers systèmes VM et les clients NFS peuvent croire que les données sont sûres alors qu’elles ne le sont pas.
C’est ainsi que vous obtenez « tout semblait correct » suivi d’incohérences après un crash.
8) Quelle taille doit faire un SLOG ?
Souvent plus petit que ce que l’on pense. Vous stockez des enregistrements de log à courte durée de vie jusqu’au commit TXG. La capacité aide pour le sur-provisionnement et l’endurance,
mais la cohérence de latence et la PLP comptent plus que la capacité.
9) Le NVMe est-il toujours meilleur pour le SLOG ?
NVMe a tendance à offrir de meilleures caractéristiques de latence et de mise en file, mais « NVMe » n’est pas une garantie de PLP ou de comportement constant.
Il faut toujours choisir des modèles connus pour leur comportement de flush durable et leur latence tail stable.
10) Mon problème pourrait-il venir de l’ARC ou de la RAM, pas du SLOG ?
Oui. Si les lectures thrashent et que le système manque de mémoire, tout devient lent et vous risquez d’attribuer à tort le problème au log.
C’est pourquoi le diagnostic rapide commence par prouver que c’est un goulet d’écriture sync.
Conclusion : prochaines étapes actionnables aujourd’hui
Un SLOG SSD SATA est tentant parce qu’il est peu coûteux et facile. C’est aussi pourquoi il est une source fiable de douleur en production :
il change les sémantiques de durabilité, concentre la latence sync sur un seul périphérique, et met à nu les comportements problématiques des SSD grand public.
Prochaines étapes pratiques :
- Exécutez le mode opératoire de diagnostic rapide. Confirmez que vous avez un problème sync avant d’acheter du matériel ou de basculer des propriétés.
- Si vous avez déjà un SLOG grand public, mesurez-le. S’il est saturé ou instable, retirez-le et retestez. Ne devinez pas.
- Si vous avez besoin d’un SLOG pour la cohérence NFS/VM, faites-le correctement. Utilisez des périphériques protégés contre la perte d’alimentation et mirror-les.
- Cessez de traiter
sync=disabledcomme un réglage de performance. Traitez-le comme une acceptation de risque qui nécessite une supervision et une approbation responsables.
L’objectif n’est pas d’atteindre des chiffres de benchmark maximaux. L’objectif est une latence stable et des sémantiques fiables — surtout le jour le plus mauvais, quand l’alimentation vacille,
un disque dysfonctionne, et que votre travail consiste à expliquer la réalité à des personnes à qui on a promis la sécurité.