Protection contre les pertes de courant SLOG ZFS : la fonctionnalité indispensable de votre SSD

janvier 1, 2026 • février 3, 2026 • Lecture : 32 min • Views: 10

Cet article vous a aidé ?

Si vous exploitez ZFS en production assez longtemps, vous finirez par rencontrer le méchant de l’histoire : les écritures synchrones. Elles sont la raison pour laquelle votre datastore NFS paraît « mystérieusement » lent, votre plateforme VM se bloque pendant une heure chargée, ou votre base de données impose un budget de latence que vous n’arrivez pas à compenser avec plus de plateaux.

Le héros vers lequel on se tourne est un périphérique SLOG—un SSD dédié au journal d’intention d’écriture ZFS (ZIL). Mais voilà la surprise : la caractéristique la plus importante d’un SSD SLOG n’est pas le débit, ni même la latence brute. C’est la protection contre la perte de puissance (PLP). Sans elle, vous installez un accessoire de performance qui peut devenir un risque de durabilité. Autrement dit : vous pouvez rendre les choses plus rapides, mais aussi plus faciles à perdre le jour où tout va mal.

Ce qu’est un SLOG (et ce qu’il n’est pas)

Clarifions la terminologie, parce que la moitié des discussions sur les SLOG sur Internet sont en réalité des débats sur le problème que l’on essaie de résoudre.

ZIL est le journal d’intention ZFS. Il existe pour satisfaire la sémantique des écritures synchrones : quand une application demande une écriture qui doit être durable avant de continuer, ZFS a besoin d’un endroit pour consigner cette intention rapidement, même si le pool principal est lent (pensez RAID HDD). Si le système plante avant que ces écritures ne soient engagées dans le pool principal, ZFS peut rejouer le journal à l’import.

SLOG est un périphérique journal séparé—un vdev dédié utilisé pour stocker le ZIL sur un média rapide. En pratique, un SLOG est surtout un réducteur de latence pour les écritures synchrones. Il n’accélère pas vos écritures séquentielles en masse. Il n’améliore pas magiquement les workloads asynchrones. Il ne répare pas un pool déjà saturé en lectures aléatoires. Il fait une chose très bien : fournir aux écritures sync une piste d’atterrissage courte, rapide et fiable.

La surprise la plus courante : le SLOG n’est pas un « cache d’écriture » au sens habituel. ZFS écrit toujours les données dans le pool principal. Le SLOG est l’endroit où le système écrit l’information de transaction et (pour les écritures sync) les blocs de données nécessaires pour satisfaire la durabilité jusqu’à leur vidage vers le pool. C’est pourquoi les besoins en capacité du SLOG sont souvent modestes et pourquoi « rapide + sûr » bat « grand ».

Blague #1 : Un SLOG sans protection contre la perte de puissance, c’est comme un parachute emballé par quelqu’un qui « réussit généralement ». Techniquement un parachute, émotionnellement une suggestion.

Pourquoi la protection contre la perte de puissance est non négociable pour le SLOG

La protection contre la perte de puissance (PLP) est la capacité d’un SSD à préserver ses écritures en cours quand l’alimentation disparaît—généralement via des condensateurs embarqués qui fournissent suffisamment d’énergie pour vidanger les tampons DRAM volatils vers la NAND. Beaucoup de SSD grand public ont un cache d’écriture volatile et peuvent reconnaître des écritures avant que celles-ci ne soient réellement sûres sur le média persistant.

Cela peut être acceptable dans de nombreux scénarios de bureau parce que le système de fichiers ou l’application ne repose pas sur un ordre strict et une durabilité garantie. Le SLOG ZFS est l’opposé. ZFS utilise le journal pour tenir une promesse : « oui, cette écriture sync est durable maintenant. » Si votre SSD ment—reconnaît la complétion mais perd l’alimentation avant que les données soient véritablement persistées—you pouvez vous retrouver avec des enregistrements de journal d’intention manquants ou corrompus. Au mieux, vous perdez quelques secondes d’écritures synchrones reconnues (ce qui est déjà inacceptable pour les applications qui ont demandé la sync). Au pire, vous créez un bazar de replay qui augmente le temps de récupération ou produit des incohérences au niveau applicatif.

En termes SRE : si votre objectif de niveau de service inclut « les transactions validées survivent à un crash », le périphérique de log ne doit pas transformer une panne d’alimentation en perte silencieuse de données. La PLP n’est pas d’abord une question de performance ; elle vise à rendre légitime la performance que vous gagnez.

Il y a aussi une raison moins évidente : un SSD sans PLP peut échouer d’une manière qui ressemble à des « pics de latence aléatoires ». Sous des variations d’alimentation ou des accrochages du contrôleur, le disque peut forcer des vidanges de cache ou des reprises, faisant glisser la latence dans la plage millisecondes–secondes. Les écritures sync ZFS sont sensibles à la latence. Vos utilisateurs se moquent de la moyenne si le 99,9ᵉ percentile fait « pourquoi ma VM s’est figée ».

Ce que la PLP ne garantit pas : elle ne rend pas un disque immortel, elle ne prévient pas les bugs firmware, et elle ne vous protège pas des kernel panics. Elle traite spécifiquement le problème « l’alimentation est partie alors que des données étaient dans des tampons volatils ». C’est une classe de panne majeure dans les datacenters comme dans les succursales.

Comment fonctionnent réellement le ZIL/SLOG : la version ingénieur

ZFS regroupe les écritures en groupes de transactions (TXG). Pour les écritures asynchrones, ZFS peut absorber les données en mémoire (ARC) puis les vidanger plus tard sur disque lorsque le TXG se synchronise. Pour les écritures synchrones, ZFS doit s’assurer que l’écriture est stable avant de l’accuser de réception à l’appelant. C’est là qu’intervient le ZIL.

Quand une application émet une écriture sync, ZFS enregistre suffisamment d’informations dans le ZIL pour rejouer cette écriture après un crash. Cet enregistrement peut inclure les données elles-mêmes selon la taille de l’écriture et la configuration. Le ZIL est écrit de manière séquentielle, comme un journal, ce qui est adapté aux périphériques à faible latence. Sur un pool sans journal séparé, ces écritures atterrissent sur les vdevs principaux, qui peuvent être des HDD avec une latence fsync misérable.

Avec un SLOG dédié, ZFS écrit ces enregistrements de journal sur le vdev SLOG au lieu de les disperser sur le pool. Plus tard, quand le prochain commit de TXG a lieu, le pool principal reçoit les données réelles et les entrées du ZIL deviennent obsolètes. Le SLOG n’est pas un foyer permanent ; c’est une zone de transit temporaire pour rendre la sémantique sync pratique.

Deux conséquences opérationnelles importent :

Le SLOG est sur le chemin d’accusé de réception pour les écritures synchrones. S’il est lent, vos clients sont lents.
Le SLOG doit être fiable en cas de coupure de courant. S’il ment, il casse la promesse.

Une autre subtilité : ZFS a déjà des garanties d’ordre. Un SLOG avec des caches volatils qui ignorent les vidanges ou réordonnent les écritures peut violer ces hypothèses. Les SSD entreprise avec PLP sont généralement conçus pour honorer les barrières d’écriture et les sémantiques de flush ; certains SSD grand public optimisent ces comportements au détriment de la robustesse pour obtenir de meilleurs scores de benchmark.

Faits intéressants et contexte historique

Le stockage ne se répète pas, mais il rime. Quelques points de contexte qui vous aideront à prendre de meilleures décisions SLOG :

ZFS a été créé chez Sun Microsystems au milieu des années 2000, quand les disques étaient énormes et lents et la RAM coûteuse ; sa conception transactionnelle supposait que les crashs arrivent et que la récupération doive être déterministe.
Le ZIL existe même sans SLOG. Les gens pensent parfois « pas de SLOG = pas de ZIL », mais ZFS a toujours un journal d’intention—par défaut il vit sur le pool.
La protection contre la perte d’alimentation dans les SSD est une vieille réalité en stockage entreprise—c’est essentiellement la version SSD du « cache d’écriture sur batterie » des contrôleurs RAID, sans les contraintes de maintenance des batteries.
Les benchmarks grand public de SSD masquent souvent la partie dangereuse. Beaucoup de tests mesurent le débit en régime établi et ignorent les sémantiques fsync/flush, précisément là où la bonne tenue d’un SLOG est cruciale.
NFS a rendu la sémantique sync problématique pour tout le monde. De nombreuses configurations NFS utilisent par défaut un comportement synchrone pour la sécurité, donc la latence de fsync du backend de stockage devient perceptible par les utilisateurs.
Les premiers SSD avaient parfois des falaises de performance dramatiques sous des workloads sync soutenus parce que leur firmware était optimisé pour des traces desktop, pas pour des journaux avec barrières strictes.
Le « cache d’écriture mensonger » n’est pas hypothétique. L’industrie a une longue histoire d’appareils qui reconnaissent des écritures avant persistance—parfois volontairement, parfois à cause d’un bug, parfois par « optimisation » des vidanges.
Le modèle copy-on-write de ZFS signifie qu’il n’écrase pas les blocs vivants ; il écrit de nouveaux blocs et met à jour les métadonnées. C’est excellent pour la cohérence, mais cela implique aussi que le chemin d’écriture sync fait plus de travail métadonnées qu’un système de fichiers simpliste.

Choisir un SSD pour SLOG : quoi exiger, quoi ignorer

Exiger : une vraie protection contre la perte de puissance

La PLP est l’élément clé. Sur un SSD entreprise, vous la verrez généralement décrite comme protection des données en cas de panne de courant, protection contre la coupure d’alimentation, ou vidange de cache soutenue par condensateurs. Physiquement, cela se traduit souvent par des rangées de condensateurs visibles sur le PCB (surtout sur les cartes U.2 / PCIe), mais pas toujours. Le vrai test est de savoir si l’appareil est conçu pour terminer en toute sécurité les écritures reconnues après une perte d’alimentation.

Opérationnellement, la PLP se corrèle avec :

Latence constante et basse pour les écritures sync
Respect des flushs et des barrières
Moins de « blocages mystères » sous pression

Exiger : faible latence, pas le débit de pointe

Le SLOG concerne le temps d’accusé. Les métriques clés sont la latence sous motifs d’écritures synchrones, en particulier les petites écritures avec flushs. Un disque qui fait 7 GB/s en séquentiel peut tout de même fournir une latence décevante sur des écritures 4K sync si son firmware et sa stratégie de cache ne sont pas conçus pour cela.

Préférer : endurance et comportement en régime stable

Les écritures SLOG sont petites, fréquentes et répétitives. Même si le ZIL est circulaire et que les anciennes entrées sont rejetées, vous pouvez générer une amplification d’écriture étonnante. Cherchez des disques avec de solides indices d’endurance et, surtout, un comportement stable sous écritures soutenues.

Préférer : topologie simple et surveillance robuste

Les périphériques NVMe offrent généralement d’excellentes latences et une bonne visibilité via les pages SMART/log. Le SATA peut fonctionner, mais il est plus facile de trouver des disques SATA grand public sans PLP, et la mise en file d’attente SATA peut devenir le goulot avec de nombreux clients. Utilisez ce qui convient à votre châssis et à votre plan de domaines de panne.

Ignorer : grande capacité

Un SLOG a typiquement juste besoin de couvrir quelques secondes de trafic d’écritures sync. Le dimensionnement pertinent se base sur le timeout TXG et le comportement en rafale, pas sur « combien de données je stocke ». Les SLOG énormes sont souvent le signe d’un achat guidé par des bullet points marketing.

Miroirez le SLOG si vous tenez à la disponibilité

Nuance importante : perdre un périphérique SLOG ne corrompt généralement pas le pool, mais cela peut entraîner la perte des dernières écritures synchrones reconnues qui ne vivaient que dans le journal. Opérationnellement, un SLOG mort fait retomber votre workload sync sur le pool principal, ce qui peut provoquer une chute de performance. Mirrorer le SLOG est un geste courant « ennuyeux mais correct » pour la disponibilité.

Blague #2 : Rien ne vous fait apprécier un SLOG en miroir comme expliquer au directeur financier pourquoi « c’est sûr » et « c’est lent » peuvent arriver en même temps.

Déployer un SLOG en sécurité : schémas qui survivent aux audits et aux pannes

Comprendre d’abord votre charge d’écritures sync

Si vous n’avez pas d’écritures synchrones, un SLOG n’aidera pas. Beaucoup de stacks VM et bases de données génèrent des écritures sync, mais certains workloads sont surtout async et ne s’en soucient pas. Mesurez avant d’acheter.

Utilisez un périphérique dédié, pas une partition partagée avec « autre chose »

En production, les périphériques de journal partagés deviennent vite une douleur partagée. Mélanger SLOG avec d’autres systèmes de fichiers, swap, ou « scratch temporaire » est une excellente façon d’introduire de la latence imprévisible.

Miroir pour la disponibilité, pas pour la vitesse

Un SLOG en miroir n’augmente pas les performances ; il améliore la résilience et peut lisser la latence tail quand un périphérique commence à mal se comporter. Si votre plateforme sert du stockage VM ou des bases de données, vous remercierez votre ancien vous d’avoir miroré.

Gardez-le proche du CPU, et gardez-le au frais

Un NVMe derrière un riser PCIe instable ou dans un slot M.2 surchauffé est une expérience de fiabilité non intentionnelle. Le throttling thermique apparaît comme des « pics » de latence sync aléatoires. Placez les périphériques de journal dans des baies avec un flux d’air approprié et surveillez les températures.

Tâches pratiques : commandes, vérifications et interprétation

Voici des tâches opérationnelles réelles que vous pouvez exécuter sur un système Linux avec OpenZFS. Les commandes supposent que vous avez un accès root ou sudo. Adaptez les noms de pool et chemins de périphérique.

Task 1: Confirm whether your workload is actually doing sync writes

cr0x@server:~$ zpool iostat -v 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        12.3T  5.1T    120   980     8.1M  34.2M
  raidz2    12.3T  5.1T    120   980     8.1M  34.2M
    sda         -      -     20   160     1.4M   5.7M
    sdb         -      -     20   160     1.3M   5.8M
    ...

Interprétation : Ceci montre l’IO du pool, mais pas sync vs async. C’est votre premier contrôle « est-ce que quelque chose se passe ». Si les écritures sont faibles mais que les clients se plaignent, la latence plutôt que le débit peut être le problème.

Task 2: Check ZFS dataset sync settings (the foot-gun)

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

Interprétation : standard respecte les demandes de sync des applications. disabled ment aux applications (gain de performance, risque de durabilité). always force la sync et peut écraser les performances sans SLOG.

Task 3: See whether you already have a SLOG configured

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        logs
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

Interprétation : Cherchez une section logs. Si elle existe, vous avez un SLOG. Si c’est un périphérique unique, décidez si la disponibilité justifie un miroir.

Task 4: Identify the actual device model and firmware

cr0x@server:~$ lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN,SERIAL
NAME    MODEL                    SIZE ROTA TRAN SERIAL
sda     ST12000NM0007           10.9T    1 sata ZS0A...
nvme0n1 INTEL SSDPE2KX040T8     3.7T    0 nvme PHM...

Interprétation : Vous voulez savoir ce qui est réellement installé. « Un SSD quelconque » n’est pas une stratégie d’inventaire.

Task 5: Check NVMe health, including power cycles and media errors

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 3%
data_units_written                  : 184,221,991
media_errors                        : 0
num_err_log_entries                 : 0
power_cycles                        : 27
power_on_hours                      : 3912
unsafe_shutdowns                    : 1

Interprétation : unsafe_shutdowns est un indice sur les événements d’alimentation. Un seul n’est pas alarmant ; une croissance non expliquée en est une.

Task 6: Check if the drive is doing thermal throttling (latency killer)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | grep -i -E 'tnvmcap|mn|fr'
mn        : INTEL SSDPE2KX040T8
fr        : VDV10131
tnvmcap   : 4000787030016

Interprétation : C’est l’identification. Associez-la à la température SMART et à la réalité du flux d’air de votre châssis. Si votre SLOG chauffe, il finira par « benchmarker » comme un appareil bien pire.

Task 7: Watch SLOG IO directly via iostat by vdev

cr0x@server:~$ zpool iostat -v tank 1
                              operations         bandwidth
pool                        read  write        read  write
--------------------------  ----  -----       ----  -----
tank                         180  2200       12.1M  95.4M
  raidz2-0                    180   400       12.1M  18.2M
    sda                         30    70        2.1M   4.6M
    ...
logs                             -  1800          -  77.2M
  mirror-1                        -  1800          -  77.2M
    nvme0n1                       -   900          -  38.6M
    nvme1n1                       -   900          -  38.6M

Interprétation : Si vous voyez de nombreuses écritures sur logs, vous avez du vrai trafic sync. Si les logs sont au repos, votre goulot est ailleurs ou vos clients n’émettent pas d’écritures sync.

Task 8: Check ZFS pool properties that impact sync behavior

cr0x@server:~$ zpool get -o name,property,value,source ashift,autotrim,autoreplace,cachefile tank
NAME  PROPERTY     VALUE     SOURCE
tank  ashift       12        local
tank  autotrim     on        local
tank  autoreplace  off       default
tank  cachefile    /etc/zfs/zpool.cache  local

Interprétation : Pas directement lié au SLOG, mais un ashift mal aligné et le trim négligé peuvent causer une amplification d’écriture et des latences imprévisibles.

Task 9: Add a mirrored SLOG (safe pattern) to an existing pool

cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

Interprétation : Cela crée un vdev de journal en miroir. Assurez-vous que ces périphériques ne sont utilisés nulle part ailleurs et qu’ils sont identifiés de façon stable (les chemins by-id sont préférables en production).

Task 10: Remove a SLOG correctly (when decommissioning)

cr0x@server:~$ sudo zpool remove tank nvme0n1

Interprétation : Sur les versions OpenZFS qui le supportent, vous pouvez retirer des périphériques de log. Confirmez l’état ensuite. Ne retirez pas juste physiquement le périphérique en espérant que ZFS s’en sorte. Ça fonctionnera, mais vous apprendrez ce que signifie un pool dégradé à 3h du matin.

Task 11: Generate a sync write test that actually exercises the SLOG

cr0x@server:~$ sudo zfs create -o sync=standard tank/slogtest
cr0x@server:~$ cd /tank/slogtest
cr0x@server:~$ sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ /usr/bin/time -f "elapsed=%e sec" dd if=/dev/zero of=./syncfile bs=8k count=20000 oflag=dsync status=none
elapsed=9.84 sec

Interprétation : oflag=dsync force chaque écriture en mode synchrone. C’est plus proche de ce que font les bases de données et les clients NFS. Comparez les résultats avec et sans SLOG (et en charge) pour voir s’il aide.

Task 12: Verify that your SLOG is not being bypassed due to dataset settings

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

Interprétation : Si c’est disabled, vous verrez probablement de bonnes performances—jusqu’au test de cohérence après crash. Si c’est always, attendez-vous à une utilisation SLOG plus élevée et assurez-vous que le périphérique peut la supporter.

Task 13: Check for extreme latency at the block layer

cr0x@server:~$ iostat -x 1 /dev/nvme0n1
Linux 6.8.0 (server)  12/25/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.12    0.00    2.01    8.55    0.00   85.32

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  svctm
nvme0n1          0.00  950.00    0.00 7600.00    0.00    0.00  42.10   0.45   0.08

Interprétation : Pour un bon périphérique SLOG, vous voulez un await bas sous charge sync. Si await grimpe à des dizaines ou centaines de millisecondes, quelque chose ne va pas : throttling, firmware, erreurs PCIe, ou contention.

Task 14: Inspect kernel logs for NVMe resets or PCIe issues

cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|pcie|reset|timeout' | tail -n 30
[Thu Dec 25 01:12:44 2025] nvme nvme0: I/O 123 QID 4 timeout, aborting
[Thu Dec 25 01:12:44 2025] nvme nvme0: Abort status: 0x0
[Thu Dec 25 01:12:45 2025] nvme nvme0: resetting controller

Interprétation : Un périphérique SLOG qui se réinitialise occasionnellement donnera l’impression de « gels fsync aléatoires ». Ce n’est pas un problème de tuning ZFS ; c’est la stabilité matérielle/firmware.

Task 15: Confirm the pool is healthy and not silently retrying errors

cr0x@server:~$ zpool status -x
all pools are healthy

Interprétation : Si vous voyez des erreurs ou des vdevs dégradés, corrigez-les d’abord. Le SLOG ne sauvera pas un pool déjà en feu.

Playbook de diagnostic rapide : trouver le goulot en minutes

Ceci est la séquence « quelqu’un hurle dans le chat, les VM sont lentes, que vérifie-t-on en premier ». Elle est optimisée pour la rapidité et le signal, pas pour l’exhaustivité.

First: confirm you’re dealing with synchronous write latency

Vérifiez les symptômes côté client : NFS « server not responding », blocages de commit de base de données, IO wait hyperviseur, workloads invités riches en fsync.
Sur l’hôte ZFS, surveillez l’IO par vdev :
```
cr0x@server:~$ zpool iostat -v tank 1
```
Signal : Si logs montre beaucoup d’écritures, vous êtes sur de la latence d’écritures synchrones. Si les logs sont inactifs, la plainte porte probablement sur la latence de lecture, le CPU, le réseau, ou une saturation d’écritures asynchrones.

Second: check whether the SLOG device is the limiter

Regardez la latence au niveau bloc :
```
cr0x@server:~$ iostat -x 1 /dev/nvme0n1
```
Signal : Un await élevé sur le périphérique SLOG corrèle directement avec des écritures sync bloquées.
Vérifiez les resets/timeouts :
```
cr0x@server:~$ sudo dmesg -T | grep -i -E 'nvme|timeout|reset' | tail
```
Signal : Toute réinitialisation de contrôleur pendant la fenêtre d’incident est un indice imparable.
Vérifiez thermals et santé :
```
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|media_errors|unsafe_shutdowns|percentage_used'
```
Signal : Surchauffe ou augmentation des erreurs media sont des problèmes de fiabilité déguisés en problèmes de performance.

Third: if SLOG is fine, check pool and system contention

Saturation au niveau pool :
```
cr0x@server:~$ zpool iostat -v tank 1
```
Signal : Si les vdevs principaux montrent d’énormes queues/utilisations et que les logs sont modérés, vous êtes peut-être limité par les vidages de données ou les lectures.
CPU et IO wait :
```
cr0x@server:~$ vmstat 1
```
Signal : Un wa soutenu élevé ou une CPU système saturée peut indiquer une contention plus large.
Réseau (pour NFS/iSCSI) :
```
cr0x@server:~$ ip -s link show dev eth0
```
Signal : Drops, erreurs, ou débordements de buffer peuvent faire paraître le stockage lent.

Erreurs courantes : symptômes et correctifs

Mistake 1: “Any SSD will do for SLOG”

Symptôme : Excellente performance dans des tests légers, latence tail terrible sous charge réelle ; écritures reconnues manquantes après des événements d’alimentation ; histoires de récupération effrayantes.

Fix : Utilisez un SSD entreprise avec PLP. Si vous ne pouvez pas vérifier la PLP, considérez le périphérique comme non-PLP et ne le placez pas sur le chemin de durabilité des écritures sync.

Mistake 2: Using `sync=disabled` as a “performance feature”

Symptôme : Tout est rapide jusqu’à une panne ; ensuite la base de données a besoin de réparation, les VM ont des systèmes de fichiers corrompus, ou l’application observe des commits « réussis » qui n’ont jamais été écrits sur disque.

Fix : Remettez les datasets en sync=standard (ou gardez standard et ajoutez un SLOG approprié). Si un fournisseur exige sync=disabled, traitez cela comme une décision d’acceptation de risque, pas comme un levier de tuning.

Mistake 3: Oversizing SLOG and undersizing expectations

Symptôme : Vous avez acheté un SSD énorme et n’avez vu aucune amélioration.

Fix : Le succès d’un SLOG tient à la latence et à la correction, pas à la capacité. Mesurez la latence d’écriture sync ; dimensionnez pour quelques secondes de trafic peak sync, pas pour des téraoctets.

Mistake 4: Single SLOG device on a platform that can’t tolerate surprises

Symptôme : Un SSD meurt, et soudainement NFS/VM devient inutilisable ou vous perdez les derniers writes sync reconnus juste avant la panne.

Fix : Mirrorez le SLOG. C’est une assurance bon marché comparée au temps d’incident et à la confiance des parties prenantes.

Mistake 5: Putting SLOG on a thermally constrained M.2 slot

Symptôme : Performance excellente pendant 5–15 minutes, puis les latences fsync explosent ; l’hôte semble hanté.

Fix : Déplacez le SLOG dans une baie correctement refroidie ou ajoutez des dissipateurs/flux d’air. Surveillez les températures. La stabilité thermique, c’est de la performance.

Mistake 6: Confusing SLOG with L2ARC or “special vdev”

Symptôme : Vous avez ajouté des périphériques et rien n’a amélioré, ou la mauvaise chose a amélioré.

Fix : Le SLOG aide les écritures sync. L2ARC aide les lectures (et généralement pas les plus sensibles en latence sauf si le working set est énorme). Le special vdev aide les métadonnées et petits blocs (et peut être dangereux si non miroré). Choisissez selon le goulot, pas selon l’intuition.

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

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

Identifiez le type de charge. NFS pour VM ? Bases de données ? iSCSI ? Ceux-ci tiennent souvent à la sémantique sync.
Mesurez la douleur liée aux écritures sync. Utilisez zpool iostat -v 1 et un test ciblé dd ... oflag=dsync sur un dataset représentatif.
Confirmez les propriétés des datasets. Assurez-vous de sync=standard sauf si vous acceptez explicitement le risque de disabled.
Si les écritures sync sont présentes et lentes, planifiez un SLOG. N’achetez pas de matériel avant d’avoir confirmé le besoin.

Plan étape par étape : sélectionner un SSD SLOG

Exigez la PLP. Si vous ne pouvez pas valider la PLP, considérez-la absente.
Priorisez la cohérence de latence. Les disques commercialisés pour workloads mixtes ou datacenter sont souvent mieux comportés.
Prévoyez l’endurance. Surtout pour des clusters NFS/VM occupés où les écritures sync sont constantes.
Préférez NVMe quand c’est possible. Le SATA peut fonctionner, mais NVMe gagne généralement pour la mise en file et la latence.
Planifiez le mirroring pour la disponibilité. Un appareil améliore la performance ; deux améliorent l’opérationnel.

Plan étape par étape : déployer un SLOG en miroir en sécurité

Inventoriez les périphériques par chemins stables. Utilisez /dev/disk/by-id plutôt que /dev/nvme0n1 brut quand possible.

Ajoutez le miroir de journal.

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-SSD_A /dev/disk/by-id/nvme-SSD_B

Vérifiez l’état du pool.
```
cr0x@server:~$ zpool status -v tank
```
Testez la charge d’écritures sync. Lancez dd ... oflag=dsync ou un générateur de workload pendant une fenêtre de maintenance.
Mettez en place la surveillance. Suivez les erreurs NVMe media, les unsafe_shutdowns, la température et les métriques de latence.

Trois mini-récits du monde corporate

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise de taille moyenne exploitant un cluster de virtualisation, l’équipe stockage avait une appliance NFS sur ZFS qui « fonctionnait bien » depuis des mois. Quelqu’un a proposé d’ajouter un SLOG pour améliorer la réactivité des VM aux heures de pointe. L’acheteur a trouvé un NVMe grand public peu cher avec des graphiques de benchmark impressionnants. Il est entré en production un vendredi, parce que bien sûr.

La performance a semblé fantastique. Les courbes de latence ont chuté. Le mail de succès est parti. Puis un événement d’alimentation a frappé l’immeuble—rien de dramatique, juste une courte interruption que l’UPS aurait dû masquer, sauf qu’un pack de batteries était en retard de remplacement. L’hôte a redémarré, a importé le pool, et NFS est revenu. Les hyperviseurs se sont reconnectés. Tout le monde a poussé un soupir.

Dans les heures qui ont suivi, quelques VMs ont commencé à montrer des corruptions au niveau applicatif : une base de données a nécessité une récupération, une file de messages avait des entrées acquittées manquantes, et un serveur de fichiers avait des trous dans les logs qui ne correspondaient à aucune maintenance planifiée. L’équipe a d’abord suspecté les hyperviseurs ou les OS invités parce que le pool s’était importé proprement et zpool status semblait normal.

Le postmortem a finalement pointé la « mise à niveau » de la semaine précédente : le SSD SLOG. Le disque grand public avait un cache d’écriture volatile et pas de PLP. Sous perte d’alimentation, il avait reconnu des écritures sync qui n’ont jamais été écrites en NAND. ZFS a fait ce qu’il pouvait au replay, mais il ne peut pas rejouer des enregistrements de journal qui n’étaient jamais réellement écrits. Le système a tenu sa part du contrat ; le périphérique ne l’a pas fait.

La solution n’a pas été un sysctl astucieux. Ils ont remplacé le périphérique de journal par un SSD entreprise avec PLP, l’ont miroré, et ajouté une politique : si un périphérique participe à l’accusé de réception de durabilité, il doit être explicitement certifié pour la sécurité en cas de perte d’alimentation. La partie embarrassante n’était pas que le SSD soit bon marché—c’était que l’hypothèse « SSD = sûr » n’ait jamais été remise en question.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation exploitait ZFS sur un grand pool HDD et servait de l’iSCSI à une flotte de serveurs applicatifs. Ils combattaient la latence durant des jobs batch. Quelqu’un a lu que sync=disabled peut « rendre ZFS rapide » et l’a proposé comme optimisation réversible. C’était implémenté sur un dataset critique avec l’argument : « le SAN a un UPS, et l’application réessaie de toute façon. »

Ce qui est arrivé ensuite était subtil. Les jobs batch sont devenus plus rapides, oui. Tellement rapides que les systèmes en amont ont augmenté la concurrence. La latence avait l’air meilleure au début, mais maintenant le pool absorbait plus d’écritures en mémoire. Sous des rafales lourdes, le système a atteint la pression mémoire, et les sync TXG sont devenus plus brutaux. La plateforme a développé un nouveau pattern : des pauses périodiques où tout s’arrêtait pour rattraper le retard.

Puis le retour de flamme est arrivé : un kernel panic déclenché par un driver non lié. Quand la machine a redémarré, le pool s’est importé, mais l’application a découvert des incohérences qui n’étaient pas censées être possibles selon son modèle transactionnel. Le panic n’était pas une coupure d’alimentation, mais l’effet était le même : la mémoire volatile avait disparu, et avec sync=disabled le stockage avait menti sur la durabilité tout du long.

La leçon réelle n’était pas « ne jamais changer les réglages ». C’était que le réglage modifie le contrat avec l’application. De plus, un gain de performance peut créer une demande qui déplace les goulots. Après le retour à sync=standard et le déploiement d’un SLOG PLP miroir approprié, ils ont obtenu la plupart du bénéfice de performance sans invalider les garanties de durabilité. Le système est devenu prévisible et rapide au lieu d’occasionnellement rapide et parfois catastrophique.

J’ai vu ce schéma à plusieurs reprises : une optimisation risquée « marche » jusqu’à ce qu’elle devienne une dépendance. Alors ce n’est plus un réglage ; c’est une décision de conception non documentée.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un établissement financier (du genre qui a des exigences sur le mot « durable ») utilisait ZFS pour des home directories NFS et un petit cluster de bases de données. Leur SLOG était une paire miroir de SSD SATA entreprise avec PLP. Pas excitant. Pas nouveau. Mais soigneusement choisi : firmware stable, comportement connu, endurance décente.

Ils faisaient aussi quelque chose impopulaire : des tests trimestriels « tirer la prise » en laboratoire qui reflétaient la production. Pas sur l’array en production, mais sur le même modèle sous charge réaliste. Ils validaient que, après une coupure brutale, le pool s’importait proprement et que les dernières écritures sync reconnues restaient cohérentes au niveau applicatif. Ils suivaient la santé des disques et remplaçaient les SSD vieillissants selon les indicateurs d’usure plutôt que l’espoir.

Une année, un entrepreneur en maintenance a accidentellement coupé l’alimentation du mauvais segment de baie. L’UPS a couvert la plupart, mais un PDU a chuté assez longtemps pour redémarrer la tête de stockage. Les clients se sont déconnectés. Les alertes ont sonné. Les gens ont couru au datacenter avec ce mélange d’urgence et de résignation.

Le système est revenu exactement comme les runbooks le décrivaient. ZFS a rejoué le journal, les exports ont repris, et les applications ont récupéré sans réparation de données. L’incident a quand même coûté en attention humaine, mais il n’est pas devenu une crise d’intégrité des données. Plus tard, lors du postmortem, l’équipe a réalisé que la raison pour laquelle elle était calme n’était pas de l’héroïsme—c’était la répétition. Ils avaient déjà vu ce mode de panne en test et avaient déjà défini ce que « correct » signifiait.

La conclusion est presque énervante de simplicité : PLP plus miroir plus validation transforme « on pense que c’est sûr » en « on sait comment ça se comporte ». C’est ça l’ingénierie de production.

FAQ

1) Do I always need a SLOG for ZFS?

Non. Si votre workload est majoritairement asynchrone (ou orienté lecture), un SLOG peut n’apporter presque rien. Le SLOG compte quand les écritures sync représentent une part significative de votre budget de latence : NFS pour VM, bases de données avec beaucoup de fsync, certains stacks iSCSI, et tout workload qui demande explicitement la durabilité par écriture.

2) Can I use an old consumer SSD as a SLOG if I mirror it?

Le mirroring aide face à la panne d’un appareil, pas à la correction en cas de perte d’alimentation. Deux disques qui peuvent chacun mentir sur la durabilité ne sont pas une machine à vérité. Mirrorer des disques non-PLP peut réduire le downtime mais ne corrige pas le risque fondamental « reconnu mais pas persistant ».

3) How big should my SLOG be?

Généralement petit. Pensez « secondes de trafic sync maximal », pas « pourcentage du pool ». Beaucoup de systèmes production utilisent des SLOGs de quelques dizaines à quelques centaines de Go, souvent parce que le SSD entreprise approprié existe dans cette taille, pas parce que ZFS en a besoin.

4) Should I put the SLOG on NVMe or SATA?

NVMe est généralement préférable pour la latence et la gestion des queues, surtout avec de nombreux clients. Le SATA peut convenir s’il s’agit d’un vrai disque entreprise PLP et que votre taux d’écritures sync n’est pas extrême. La clé est une latence basse et consistante sous petites écritures avec flush.

5) Does a SLOG help with async write throughput?

Pas vraiment, et parfois pas du tout. Les écritures asynchrones sont principalement gouvernées par le sync des TXG vers le pool principal, la mémoire et la bande passante d’écriture du pool. Le SLOG aide le chemin d’accusé des écritures synchrones.

6) What about using a “special vdev” instead of SLOG?

Outil différent. Un special vdev accélère les métadonnées et (optionnellement) les petits blocs, aidant les lectures aléatoires et certains patterns d’écriture. Il ne remplace pas le journal d’écriture sync. De plus, les special vdevs doivent être traités comme critiques (mirrorez-les) car les perdre peut être catastrophique pour le pool.

7) If I have PLP, do I still need a UPS?

Oui. La PLP couvre un problème étroit : que le SSD persiste en toute sécurité les écritures reconnues quand l’alimentation disparaît. Un UPS couvre le problème plus large : maintenir l’ensemble du système stable, éviter des cycles de crash répétés, et vous donner le temps d’un arrêt ordonné. Ils se complètent.

8) How do I know whether my SSD really has PLP?

Faites confiance à la documentation entreprise du vendeur et au positionnement produit, mais vérifiez opérationnellement : cherchez des SSD datacenter-class explicitement marketés avec « power-loss data protection », vérifiez les designs à condensateurs, et évitez les disques où la PLP est vague ou absente. Surveillez aussi le comportement : les appareils sans PLP montrent souvent des performances de flush suspectes et une latence sync incohérente. En fin de compte, vous voulez des preuves, pas de l’espoir.

9) Does ZFS ignore drive caches or force flushes?

ZFS utilise des flushs et des sémantiques d’ordre appropriées pour les opérations synchrones, mais il ne peut pas forcer un périphérique à être honnête. Si le firmware reconnait la complétion avant que les données soient persistées, l’OS ne peut pas rendre cela vrai rétrospectivement. C’est pourquoi la PLP importe.

10) What happens if my SLOG dies?

Si le périphérique SLOG échoue, ZFS peut généralement continuer avec le pool (souvent en état dégradé ou après suppression du journal), mais vous pouvez perdre les dernières écritures sync reconnues qui vivaient uniquement dans le journal. La performance retombera probablement sur la latence sync du pool principal, ce qui peut être brutal sur des pools HDD. Le mirroring réduit la probabilité qu’une seule défaillance SSD devienne une outage.

Conclusion

Un SLOG n’est pas un accessoire de vanité pour ZFS. C’est une solution ciblée pour une douleur spécifique : la latence d’écritures synchrones. Mais dès que vous placez un périphérique sur le chemin où les applications attendent un accusé de réception durable, vous avez promu ce périphérique de « stockage rapide » à « partie de la vérité ».

C’est pourquoi la protection contre la perte de puissance est la fonctionnalité que votre SSD SLOG doit posséder. La PLP rend la performance honnête. Miroirez-le si la disponibilité compte. Gardez-le au frais. Mesurez le comportement sync avant et après. Et quand vous êtes tenté par un disque bon marché aux jolis benchmarks, souvenez-vous que ZFS est transactionnel—votre périphérique de journal doit l’être aussi.