Fondamentaux de ZFS : Ce que vous obtenez en pratique (et quand ext4/XFS l’emporte)

décembre 16, 2025 • février 3, 2026 • Lecture : 31 min • Views: 9

Cet article vous a aidé ?

ZFS a une réputation : soit c’est le système de fichiers qui sauve votre carrière, soit celui qui dévore discrètement votre RAM pendant que votre base de données se plaint. Les deux histoires peuvent être vraies. ZFS n’est pas un « système de fichiers » au sens étroit ; c’est un système de stockage qui traite les disques, la redondance, le cache et l’intégrité des données comme un seul problème de conception. C’est pourquoi il peut paraître magique quand il convient — et obstiné quand ce n’est pas le cas.

Voici le point de vue opérationnel : ce que ZFS vous apporte réellement sur du matériel réel avec des modes de défaillance réels, comment l’interroger avec des commandes que vous utiliserez à 2h du matin, et les cas honnêtes où ext4 ou XFS est simplement l’outil le mieux adapté. Si vous cherchez une religion, vous êtes dans la mauvaise salle. Si vous voulez garder les données correctes et la latence ennuyeuse, poursuivez la lecture.

Table des matières

1) Ce qu’est réellement ZFS (et pourquoi il se comporte différemment)
2) Ce que vous obtenez réellement en pratique
3) Quand ext4/XFS l’emporte (et pourquoi ce n’est pas de l’hérésie)
4) Faits intéressants & contexte historique
5) Tâches pratiques : commandes que vous exécuterez réellement
6) Guide de diagnostic rapide (trouver le goulot d’étranglement vite)
7) Trois mini-récits du monde de l’entreprise
8) Erreurs courantes : symptômes et correctifs
9) Checklists / plan étape par étape
10) FAQ
Conclusion

1) Ce qu’est réellement ZFS (et pourquoi il se comporte différemment)

Avec ext4 ou XFS, vous avez généralement un périphérique bloc (peut‑être un volume RAID, peut‑être LVM) et un système de fichiers qui repose dessus. ZFS renverse la pile : il gère la « RAID », la gestion des volumes et le système de fichiers, de sorte qu’il peut appliquer une intégrité de bout en bout. C’est pourquoi ZFS parle plus de pools, vdevs et datasets que de « partitions ».

Modèle central en une phrase

Un pool ZFS (zpool) est composé d’un ou plusieurs vdevs (périphériques virtuels). Un vdev peut être un miroir, un groupe RAIDZ, un disque unique (s’il vous plaît, évitez), ou un dispositif à usage spécial. ZFS stripe les données à travers les vdevs, pas à travers les disques à l’intérieur d’un vdev. Cette distinction est importante quand vous augmentez la capacité ou la performance : ajouter des vdevs augmente le débit ; changer le type d’un vdev n’est… pas vraiment une opération simple.

Le copy-on-write est la fonctionnalité derrière les fonctionnalités

ZFS utilise le copy-on-write (CoW). Lorsque vous modifiez un bloc, il écrit un nouveau bloc ailleurs puis met à jour les pointeurs de métadonnées pour le référencer. Cela rend les snapshots bon marché (ce ne sont que d’anciens pointeurs) et réduit fortement le risque d’écritures fragmentées produisant de l’incohérence. Mais cela signifie aussi que la fragmentation se comporte différemment, et que les sémantiques d’écriture synchrone sont une variable de performance de premier plan.

Checksums de bout en bout : la partie que vous ne remarquez pas jusqu’à ce que ça arrive

Chaque bloc a un checksum stocké dans ses métadonnées parentes. Les lectures vérifient ces checksums ; les réparations se font automatiquement si la redondance existe. Ce n’est pas de la « paranoïa bitrot ». C’est une hygiène de base dans un monde où les disques, contrôleurs, firmwares et câbles mentent parfois.

Blague #1 : ZFS, c’est comme un détecteur de fumée — on le remarque surtout quand il hurle, et là on est très contents qu’il ait été installé.

2) Ce que vous obtenez réellement en pratique

2.1 Intégrité des données que vous pouvez opérationnaliser

L’argument honnête : ZFS attrape les corruptions silencieuses que d’autres piles peuvent servir à votre application comme des « données valides ». Il le fait avec des checksums sur chaque bloc et l’auto‑réparation quand la redondance existe (miroir/RAIDZ). En pratique, vous opérationnalisez cela via des scrubs, qui parcourent le pool et vérifient tout.

Ce que cela change dans vos opérations quotidiennes :

Vous pouvez planifier un scrub et traiter les erreurs de checksum comme un signal actionnable plutôt que comme une histoire de fantôme.
Vous pouvez prouver qu’une sauvegarde est cohérente au niveau stockage, pas seulement « elle s’est terminée ».
Vous pouvez remplacer proactivement des disques instables parce que ZFS vous dira qu’il répare, pas seulement qu’ils échouent.

2.2 Snapshots suffisamment rapides pour être ennuyeux

Les snapshots ZFS sont quasi‑instantanés parce qu’ils sont des marqueurs de métadonnées. En pratique, cela change votre posture opérationnelle : vous pouvez snapshotter avant des changements risqués, snapshotter fréquemment pour la récupération contre ransomware, et garder des rétentions courtes sans craindre des tempêtes d’E/S.

La nuance est subtile : les snapshots sont bon marché à créer, pas gratuits à conserver. Si vous en conservez des milliers et que vous faites ensuite beaucoup de réécritures aléatoires, vos métadonnées et le profil de fragmentation changent. ZFS continuera de fonctionner ; vos SLO de latence peuvent ne pas suivre.

2.3 Compression qui aide généralement plus qu’elle ne nuit

La compression moderne de ZFS (souvent lz4) est l’une de ces rares fonctionnalités à la fois performante et utile. Vous obtenez souvent un meilleur débit effectif car vous déplacez moins d’octets sur disque. Pour de nombreuses charges, c’est un repas gratuit — sauf que ce n’est pas gratuit ; c’est « payé » en CPU, dont vous pourriez déjà manquer.

En pratique : activez compression=lz4 sur la plupart des datasets par défaut sauf si vous avez une raison mesurée de ne pas le faire (par ex., médias déjà compressés, appliances saturées CPU).

2.4 Contrôles au niveau dataset : quotas, réservations et stockage multi‑locataire sensé

Les datasets ZFS vous offrent des propriétés par arborescence : compression, recordsize, atime, quotas, réservations, planification de snapshots, points de montage. C’est là que ZFS ressemble à une plateforme de stockage plutôt qu’à « un système de fichiers ». Dans les systèmes d’entreprise, c’est souvent la différence entre « chaos serveur NFS partagé » et « service de stockage prévisible ».

2.5 Réplication prédictible avec send/receive

zfs send/zfs receive sont un cadeau pratique. Ils répliquent les snapshots sous forme de flux, et les incrémentales peuvent être efficaces. Lorsqu’ils sont bien mis en place, ce n’est pas juste une sauvegarde — c’est un chemin de reconstruction, une stratégie de migration, et un mécanisme DR que vous pouvez tester sans héroïsme.

2.6 D’où viennent les surprises de performance

ZFS peut être extrêmement rapide, mais il est sensible aux profils de charge et à la configuration. La surprise la plus commune en production concerne les écritures synchrones : si votre charge utilise beaucoup fsync() (bases de données, NFS, images VM), ZFS les respectera. Sans un SLOG approprié (et une protection contre la perte d’alimentation adéquate), cela peut se transformer en pics de latence qui font croire que « ZFS est lent ». Il n’est pas lent ; il est honnête.

Blague #2 : ZFS ne perd pas vos données — il vous oblige juste à affronter vos hypothèses, ce qui est étrangement pire.

3) Quand ext4/XFS l’emporte (et pourquoi ce n’est pas de l’hérésie)

3.1 Quand la simplicité est votre SLO

ext4 est la Toyota Corolla des systèmes de fichiers Linux : pas excitant, mais elle démarre chaque matin. Si votre pile de stockage fournit déjà redondance et garanties d’intégrité (bon contrôleur RAID avec cache + BBU, SAN d’entreprise avec checksums, stockage bloc cloud avec garanties d’intégrité), ext4 peut être le bon choix car il a moins de pièces mobiles et moins de réglages à mal configurer.

XFS est de la même veine « ennuyeux dans le bon sens », surtout pour les gros fichiers, l’I/O parallèle, et certaines charges lourdes en métadonnées où ses allocation groups évoluent bien.

3.2 Quand vous ne pouvez pas vous permettre les effets secondaires du CoW

Le copy-on-write change le schéma d’écriture. Pour certaines charges — surtout celles qui réécrivent des blocs en place en attendant une localité stable — le CoW peut créer de la fragmentation et de l’amplification de lecture avec le temps. Vous pouvez atténuer, tuner, concevoir autour. Mais si vous voulez « écrire les octets à leur place, garder la localité », XFS/ext4 peut offrir un comportement à plus long terme prévisible.

3.3 Quand vous avez besoin du minimum de surcharge

Les checksums, métadonnées et fonctionnalités de ZFS coûtent quelque chose. Souvent vous récupérez ce coût (compression, moins de corruptions, snapshots faciles). Mais pour des systèmes très légers — appliances embarquées, VM minimales, ou environnements où la RAM est précieuse — ext4 peut l’emporter simplement parce que son empreinte mémoire et CPU est petite et facile à raisonner.

3.4 Quand votre équipe opérationnelle n’est pas équipée pour ZFS

Ce n’est pas une attaque ; c’est la réalité. ZFS est convivial opérationnellement une fois maîtrisé, mais il nécessite la compréhension de l’agencement de vdev, ashift, scrubs, gestion des snapshots et de l’ARC. Si vous n’avez pas des personnes qui prendront en charge ces détails, ext4/XFS réduit la surface d’erreurs subtiles.

3.5 Quand vous avez besoin de modèles de croissance en ligne que ZFS n’offre pas

L’extension ZFS est basée sur les vdevs. Vous pouvez souvent agrandir un miroir en remplaçant des disques par des disques plus grands et laisser resilver, ou ajouter de nouveaux vdevs pour étendre le pool. Mais vous ne pouvez pas « convertir RAIDZ1 en RAIDZ2 » après coup de manière triviale, et le rééquilibrage des données entre vdevs n’est pas comme une reshape RAID traditionnelle. Si vos réalités d’achat exigent des reshapes fréquents et maladroits, ext4/XFS sur LVM/MDRAID peut mieux convenir.

4) Faits intéressants & contexte historique (court, concret)

ZFS a été conçu chez Sun Microsystems au milieu des années 2000 dans Solaris pour remplacer la séparation « gestionnaire de volumes + système de fichiers » et réduire le risque de corruption.
Sa revendication de « système de fichiers 128 bits » signifie surtout « nous ne manquerons pas d’espace de sitôt », pas une promesse que vous attacherez des disques de la taille de Jupiter.
Les checksums de bout en bout de ZFS répondaient directement à la corruption silencieuse dans des piles de stockage réelles — pas des rayons cosmiques théoriques, mais des défaillances ordinaires de matériel et firmware.
Les snapshots CoW sont devenus un outil opérationnel pratique dans ZFS des années avant que la notion de « snapshot » ne devienne courante dans les plateformes VM et conteneurs.
ZFS a popularisé l’idée que la compression peut être une fonctionnalité de performance, pas seulement un truc de capacité — car réduire l’I/O peut être plus rapide que déplacer des octets bruts.
OpenZFS a évolué en une implémentation ouverte multi‑plateforme ; sur Linux il est devenu le standard de facto pour l’usage de ZFS malgré des contraintes de licence qui l’empêchent d’être dans l’arbre du noyau.
RAIDZ n’est pas « RAID5/6 mais brandé ». Les détails d’implémentation (largeur de stripe variable, pointeurs de blocs) rendent son comportement différent — surtout lors d’écritures partielles.
Les scrubs ZFS ne sont pas la même chose que les « consistency checks » RAID. Ils vérifient les checksums de bout en bout et peuvent réparer avec la redondance.
L’ARC (Adaptive Replacement Cache) est plus qu’un cache de pages ; c’est un cache géré par ZFS avec des politiques observables et réglables.

5) Tâches pratiques : commandes que vous exécuterez réellement

Tous les exemples supposent Linux avec OpenZFS installé. Remplacez les noms de pool/dataset selon le cas. Après chaque commande, je vous dis ce que la sortie signifie opérationnellement, pas académiquement.

Tâche 1 : Inventaire des pools et santé de base

cr0x@server:~$ sudo zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  7.25T  3.10T  4.15T        -         -    12%    42%  1.00x  ONLINE  -

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

Interprétation : FRAG est un indice, pas un verdict, mais s’il augmente et que la performance se dégrade, vous le corrélerez avec la charge. status -x est votre contrôle rapide « est‑ce que quelque chose brûle ? ».

Tâche 2 : Obtenir le détail en cas de problème

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:55 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Interprétation : Les compteurs READ/WRITE/CKSUM vous indiquent si vous avez affaire à un disque en train de mourir, un câble/contrôleur instable, ou une corruption sur disque. « Scrub repaired » non nul n’est pas automatiquement panique, mais c’est un ticket.

Tâche 3 : Voir les datasets et où l’espace est parti

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             3.10T  3.92T   192K  /tank
tank/home         420G  3.92T   410G  /home
tank/vm           1.90T  3.92T  1.20T /tank/vm
tank/backups      780G  3.92T   120G  /tank/backups

Interprétation : USED inclut les snapshots et descendants. REFER est « les données live dans ce dataset ». Si USED est énorme et REFER modeste, les snapshots sont probablement en cause.

Tâche 4 : Trouver rapidement le gonflement des snapshots

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation -s used | tail -n 5
tank/vm@auto-2025-12-24-0100    120G  1.20T  Wed Dec 24 01:00 2025
tank/vm@auto-2025-12-23-0100    118G  1.19T  Tue Dec 23 01:00 2025
tank/vm@auto-2025-12-22-0100    111G  1.18T  Mon Dec 22 01:00 2025
tank/vm@auto-2025-12-21-0100    109G  1.18T  Sun Dec 21 01:00 2025
tank/vm@auto-2025-12-20-0100    103G  1.17T  Sat Dec 20 01:00 2025

Interprétation : Ce used est « blocs uniques détenus par le snapshot ». S’il augmente quotidiennement, votre taux de churn est élevé (images VM, bases de données). Planifiez la rétention en conséquence.

Tâche 5 : Vérifier les propriétés clés qui changent la performance

cr0x@server:~$ sudo zfs get -o name,property,value -s local,default recordsize,compression,atime,sync,logbias tank/vm
NAME     PROPERTY     VALUE
tank/vm  atime        off
tank/vm  compression  lz4
tank/vm  logbias      latency
tank/vm  recordsize   128K
tank/vm  sync         standard

Interprétation : recordsize doit correspondre à votre taille d’I/O dominante pour les fichiers (les bases de données préfèrent souvent 16K/8K, les images VM souvent 16K/64K selon). sync et logbias décident comment ZFS traite les charges synchrones.

Tâche 6 : Activer la compression en toute sécurité sur un dataset

cr0x@server:~$ sudo zfs set compression=lz4 tank/home
cr0x@server:~$ sudo zfs get -o name,property,value compression tank/home
NAME       PROPERTY     VALUE
tank/home  compression  lz4

Interprétation : Cela affecte les blocs nouvellement écrits. Cela ne réécrira pas les anciennes données à moins de les réécrire/copier. Opérationnellement, c’est bien : vous pouvez activer sans grande migration.

Tâche 7 : Mesurer si la compression aide réellement

cr0x@server:~$ sudo zfs get -o name,property,value compressratio,logicalused,used tank/home
NAME       PROPERTY     VALUE
tank/home  compressratio 1.42x
tank/home  logicalused   580G
tank/home  used          420G

Interprétation : Si compressratio reste proche de 1.00x pour un dataset rempli de données déjà compressées, vous brûlez surtout du CPU pour rien. Si c’est 1.3x+ sur des datasets généralistes, c’est souvent un gain net.

Tâche 8 : Lancer et surveiller un scrub

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 24 02:10:11 2025
        1.25T scanned at 1.10G/s, 410G issued at 360M/s, 3.10T total
        0B repaired, 13.2% done, 0:02:41 to go

Interprétation : « scanned » vs « issued » vous dit combien de données sont réellement lues vs la traversée des métadonnées. Si les scrubs prennent une éternité, vous êtes peut‑être limité en IOPS ou confronté à des disques lents/SMR.

Tâche 9 : Remplacer un disque défaillant dans un miroir (cas courant)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       FAULTED     12     0     3  too many errors

cr0x@server:~$ sudo zpool replace tank ata-SAMSUNG_SSD_2 /dev/disk/by-id/ata-SAMSUNG_SSD_NEW
cr0x@server:~$ sudo zpool status tank
  scan: resilver in progress since Wed Dec 24 03:01:10 2025
        210G scanned at 2.5G/s, 88G issued at 1.0G/s, 3.10T total
        88G resilvered, 2.8% done, 0:49:12 to go

Interprétation : Remplacer via /dev/disk/by-id évite la roulette des noms de périphériques après reboot. Surveillez la vitesse de resilver ; si elle rampe, votre pool est occupé ou un côté est malade.

Tâche 10 : Confirmer ashift (alignement taille secteur) avant de valider une conception de pool

cr0x@server:~$ sudo zdb -C tank | grep -E "ashift|vdev_tree" -n | head
35:            ashift: 12
36:            asize: 7998634579968

Interprétation : ashift=12 signifie des secteurs 4K. Se tromper d’ashift est une taxe permanente. Si vous vous retrouvez avec ashift=9 sur des périphériques modernes 4K/8K, vous paierez pour cela en amplification d’écriture.

Tâche 11 : Observer le comportement de l’ARC (la RAM aide‑t‑elle ou manque‑t‑elle juste ?)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "size|c_max|hit|miss" | head
hits                            1802345678
misses                           234567890
size                            17179869184
c_max                           25769803776

Interprétation : Un taux de hit élevé signifie généralement que les lectures sont servies depuis la RAM. Si les misses explosent pendant l’accès au working set, vous manquez de RAM ou votre modèle d’accès est trop grand/aleatoire pour être mis en cache efficacement.

Tâche 12 : Surveiller en temps réel l’I/O et la latence du pool

cr0x@server:~$ sudo zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.10T  4.15T    820   1600   210M   380M
  mirror-0  3.10T  4.15T    410    800   105M   190M
    sda         -      -    205    400  52.5M  95.0M
    sdb         -      -    205    400  52.5M  95.0M

Interprétation : Si un disque unique effectue un travail disproportionné dans un miroir, suspectez des erreurs, des bizarreries de firmware, ou un périphérique silencieusement plus lent. Si les ops sont élevées mais le débit faible, vous êtes limité en IOPS (aléatoire). Si le débit est élevé mais les ops modérées, c’est du streaming.

Tâche 13 : Créer un dataset pour une base de données et définir des valeurs par défaut sensées

cr0x@server:~$ sudo zfs create tank/pg
cr0x@server:~$ sudo zfs set atime=off compression=lz4 recordsize=16K tank/pg
cr0x@server:~$ sudo zfs get -o name,property,value atime,compression,recordsize tank/pg
NAME     PROPERTY     VALUE
tank/pg  atime        off
tank/pg  compression  lz4
tank/pg  recordsize   16K

Interprétation : Ce n’est pas « le seul tuning possible pour les bases de données », mais c’est un point de départ raisonnable : recordsize plus petit pour les pages DB, pas de churn atime, compression activée.

Tâche 14 : Snapshotter et revenir en arrière en toute sécurité (quand vous allez faire quelque chose d’audacieux)

cr0x@server:~$ sudo zfs snapshot tank/home@pre-upgrade
cr0x@server:~$ sudo zfs list -t snapshot tank/home
NAME                     USED  AVAIL  REFER  MOUNTPOINT
tank/home@pre-upgrade       0      -   410G  -

cr0x@server:~$ sudo zfs rollback tank/home@pre-upgrade

Interprétation : Le snapshot est instantané. Le rollback est rapide mais destructeur pour les changements après le snapshot. En pratique : snapshotpez, modifiez, validez, puis conservez ou détruisez le snapshot selon le résultat.

Tâche 15 : Répliquer avec send/receive (incrémental)

cr0x@server:~$ sudo zfs snapshot tank/home@daily-1
cr0x@server:~$ sudo zfs snapshot tank/home@daily-2

cr0x@server:~$ sudo zfs send -i tank/home@daily-1 tank/home@daily-2 | sudo zfs receive -u backup/home
cr0x@server:~$ sudo zfs list -t snapshot backup/home | tail -n 2
backup/home@daily-1          0      -   410G  -
backup/home@daily-2          0      -   412G  -

Interprétation : Les flux incrémentaux signifient que vous ne déplacez que les changements. Le -u garde le dataset démonté jusqu’à ce que vous soyez prêt. Opérationnellement : vous pouvez tester des restaurations sans perturber les points de montage de production.

6) Guide de diagnostic rapide (trouver le goulot d’étranglement vite)

Ceci est la séquence « ne pas gesticuler ». L’objectif est de décider si votre problème est matériel, disposition du pool, chemin d’écriture synchrone, mémoire/cache, ou votre charge.

Étape 1 : Le pool est‑il sain, ou faites‑vous des tests sur un système dégradé ?

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

Si non sain : stoppez le tuning de performance. Remplacez le périphérique défaillant, résolvez les erreurs de câblage/contrôleur, laissez le resilver se terminer. Les performances pendant le resilver ne sont pas la ligne de base ; c’est le mode urgence.

Étape 2 : Le pool manque‑t‑il d’espace ou est‑il fortement fragmenté ?

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  7.25T  6.70T  550G  92%   61%  ONLINE

Interprétation : Les pools au‑dessus de ~80–85% de capacité souffrent souvent. Ce n’est pas une faute morale ; c’est la réalité de l’allocateur. Si CAP est élevé et les écritures lentes, l’espace libre est la première chose à corriger.

Étape 3 : Êtes‑vous lié par les écritures synchrones (latence fsync) ?

cr0x@server:~$ sudo zpool iostat -v tank 1

Interprétation : Cherchez des ops d’écriture élevées avec faible bande passante et forte latence au niveau système. Si votre appli fait des écritures synchrones et que vous n’avez pas de SLOG adéquat, ZFS attendra une écriture stable. Sur des pools HDD, ça peut être brutal.

Étape 4 : L’ARC aide‑t‑il ou manque‑t‑il de RAM ?

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "hits|misses|size|c_max" | head

Interprétation : Si votre working set tient et que le taux de hit est bon, les lectures devraient être rapides. Si les misses dominent et que votre charge est orientée lecture, il vous faut peut‑être plus de RAM — ou accepter que le pattern ne soit pas cachable.

Étape 5 : Un vdev unique est‑il le goulot ?

cr0x@server:~$ sudo zpool iostat -v tank 1

Interprétation : ZFS stripe à travers les vdevs, donc les performances évoluent souvent avec le nombre de vdevs. Un seul vdev RAIDZ est une unité de performance. Si vous avez construit « un énorme RAIDZ2 » en espérant le nombre d’IOPS de « beaucoup de disques », la réalité arrive ici.

Étape 6 : Les snapshots et le churn causent‑ils une amplification des écritures ?

cr0x@server:~$ sudo zfs list -t snapshot -o name,used -s used | tail

Interprétation : Un grand espace unique de snapshot plus une charge réécrivant souvent signifie que le pool alloue constamment de nouveaux blocs. Cela peut ressembler à « la performance d’écriture aléatoire s’est effondrée » alors que le vrai problème est la politique de rétention vs le taux de churn.

7) Trois mini‑récits du monde de l’entreprise (plausibles, techniquement exacts)

Mini‑récit A : Un incident causé par une mauvaise hypothèse (ZFS n’est pas le cache du contrôleur RAID)

Une entreprise pour laquelle j’ai travaillé a déplacé un cluster PostgreSQL d’un SAN vers une paire de serveurs de stockage locaux. Le vieux SAN avait un cache d’écriture batté par batterie ; la base profitait d’un fsync() à faible latence et n’y pensait jamais. Les nouveaux serveurs ont été construits avec des HDD en RAIDZ2 et « pas besoin d’extras car ZFS est intelligent ».

Le week‑end de migration s’est bien passé jusqu’au lundi matin quand le trafic client est revenu et que la latence de commit est passée de « acceptable » à « l’application timeoute ». La surveillance montrait un CPU presque inactif, des disques non saturés en bande passante, et pourtant la base se bloquait. Cas classique : le système était lié aux écritures synchrones. Chaque commit transactionnel voulait du stockage stable, et le stockage stable sur un pool RAIDZ HDD sans dispositif log dédié signifie attendre la latence rotationnelle et la comptabilité de parité.

L’hypothèse erronée était subtile : « ZFS a un ZIL, donc c’est comme avoir un cache d’écriture ». Le ZIL est un mécanisme de correction, pas un accélérateur magique. Sans SLOG conçu pour les écritures synchrones à faible latence (et sans protection contre la perte d’alimentation), ZFS fait simplement la chose sûre lentement.

La correction n’a pas été héroïque. Ils ont ajouté des NVMe entreprise en miroir comme SLOG, vérifié que les dispositifs avaient une vraie protection contre la perte d’alimentation, et ont annulé un réglage malencontreux : quelqu’un avait mis sync=disabled pendant des tests et supposé que « tout va bien » parce que rien n’avait crashé. Après le changement, la base a retrouvé une latence de commit prévisible, et le postmortem avait une morale simple : « la correction est une exigence de performance ».

Mini‑récit B : Une optimisation qui s’est retournée contre eux (recordsize et images VM)

Un autre environnement faisait tourner un cluster de virtualisation privé avec des dizaines d’images VM actives sur ZFS. Un ingénieur a lu un guide de tuning et décidé « de gros blocs = plus rapide », puis a défini recordsize=1M sur le dataset VM. Le benchmark sur un système tranquille avait l’air excellent pour les lectures séquentielles. Tout le monde a célébré et a continué.

Deux mois plus tard, des plaintes de latence ont commencé à apparaître sporadiquement. Pas constantes, mais en pics : une VM « gelait » brièvement sous une charge d’écriture aléatoire. Le pool n’était pas plein, aucun disque ne ratait, l’ARC semblait sain. Le problème était le modèle d’écriture : les images VM font beaucoup de petites écritures aléatoires. Avec un recordsize très grand, les petites réécritures peuvent déclencher un comportement read‑modify‑write et augmenter l’amplification d’écriture. Ajoutez des snapshots (parce que les snapshots VM étaient conservés plus longtemps que nécessaire), et le CoW signifiait encore plus d’allocations nouvelles.

Ils ont rétabli un recordsize plus raisonnable (souvent 16K ou 64K selon l’hyperviseur et les patterns invités), réduit la rétention des snapshots, et les pics ont largement disparu. La leçon n’était pas « ne jamais tuner ». C’était « ne jamais tuner sur une seule dimension ». CoW + recordsize + rétention des snapshots est un problème à trois corps, et la production trouve toujours l’orbite instable.

La vraie action du postmortem : toute « optimisation » doit avoir un test représentant la charge (mix d’écritures aléatoires, churn de snapshots et concurrence) et un plan de rollback. Personne n’a été interdit de tuner ; ils ont juste arrêté de le faire comme un rituel de minuit.

Mini‑récit C : Une pratique ennuyeuse mais correcte qui a sauvé la mise (scrubs + by-id + spares)

La panne la plus coûteuse que je n’ai pas eue a été évitée par un rappel calendrier. Une équipe gérait des miroirs ZFS pour un service de fichiers critique. Rien d’exotique : bons disques, charge modeste, croissance régulière. La pratique était ennuyeuse : scrubs mensuels, alertes sur les erreurs de checksum, et remplacement des disques par leurs IDs persistants plutôt que par /dev/sdX.

Un mois, un scrub a rapporté un petit nombre non nul d’octets réparés sur un membre de miroir. Pas de rapport utilisateur, pas de SMART criant, rien d’évident. L’alerte a quand même déclenché un ticket parce que la règle était simple : les réparations de checksum signifient que quelque chose a menti. Ils ont consulté les logs, vu des réinitialisations intermittentes de lien sur une baie particulière, ont reseaté le disque, remplacé un câble suspect, et ont échangé le disque pendant les heures ouvrables.

Deux semaines plus tard, un autre disque du même miroir a commencé à renvoyer des erreurs de lecture sévères. Si la corruption silencieuse précédente n’avait pas été trouvée et traitée, ils auraient pu être à un mauvais jour d’une perte de blocs irrécupérables. Au lieu de cela, ce fut un remplacement routinier sans drame.

Rien de spectaculaire dans ce sauvetage. Personne n’a « héros » une récupération à 3h du matin. Le système est resté ennuyeux parce qu’ils ont fait les choses ennuyeuses : scrubs, alertes pertinentes, et hygiène matérielle. En production, l’ennui est une fonctionnalité.

8) Erreurs courantes (symptômes spécifiques et correctifs)

Erreur 1 : Construire un énorme vdev RAIDZ et attendre beaucoup d’IOPS

Symptôme : Excellent débit séquentiel, latence I/O aléatoire terrible sous charge ; VM ou bases de données semblent « bloquées ».

Pourquoi : Un vdev RAIDZ se comporte comme une seule unité d’IOPS dans de nombreux patterns ; le travail de parité et le nombre de disques ne multiplient pas magiquement les IOPS aléatoires.

Correctif : Utilisez des miroirs pour les workloads IOPS‑intensifs, ou plusieurs vdevs RAIDZ (plus de vdevs = plus de parallélisme). Si la refonte n’est pas possible, isolez les charges, réduisez la pression sync, et soyez réaliste sur les IOPS.

Erreur 2 : Mettre `sync=disabled` pour « réparer la performance »

Symptôme : La performance semble incroyable ; plus tard, après une panne de courant ou crash, la base ou le système de fichiers VM est corrompu ou des transactions récentes manquent.

Pourquoi : Vous avez ordonné à ZFS de mentir aux applications sur la durabilité.

Correctif : Remettez sync=standard (par défaut) et traitez le vrai problème : ajoutez un SLOG miroir avec protection contre la perte d’alimentation si vous avez besoin d’écritures synchrones à faible latence.

Erreur 3 : Mauvais `ashift` à la création du pool

Symptôme : Performances d’écriture inexplicablement mauvaises ; petites écritures provoquent de grosses écritures sur le périphérique ; endurance SSD baisse plus vite que prévu.

Pourquoi : Le désalignement des secteurs provoque une amplification d’écriture. Vous ne pouvez pas changer ashift après création.

Correctif : Recréez le pool correctement (souvent ashift=12 ou 13 selon les périphériques). Si vous ne pouvez pas, vous vivez avec la taxe.

Erreur 4 : Laisser le pool tourner à chaud (trop plein)

Symptôme : Tout devient plus lent avec le temps ; scrubs/resilvers prennent plus de temps ; les opérations sur les métadonnées semblent lentes.

Pourquoi : L’allocateur a moins de choix ; la fragmentation et l’amplification d’écriture augmentent.

Correctif : Gardez une marge d’espace libre. Ajoutez de la capacité (nouveaux vdevs), réduisez la rétention, ou déplacez les données froides. Traitez 80% comme un seuil de planification, pas une loi stricte.

Erreur 5 : Accumuler des snapshots sans conscience du churn

Symptôme : « Nous avons supprimé des données mais l’espace n’est pas revenu », plus dérive de performance.

Pourquoi : Les snapshots gardent les anciens blocs référencés. Churn élevé + rétention longue = pression sur l’espace et la fragmentation.

Correctif : Auditez les snapshots, implémentez des politiques de rétention par dataset, et alignez la fréquence des snapshots avec les objectifs de récupération, pas l’intuition.

Erreur 6 : Mélanger des périphériques lents et rapides d’une manière qui amplifie le plus lent

Symptôme : Pics de latence aléatoire ; un disque montre une forte utilisation tandis que les autres sont inactifs.

Pourquoi : Les miroirs sont souvent limités par le membre le plus lent ; des vdevs hétérogènes compliquent la prévisibilité.

Correctif : Gardez les membres de vdev assortis. Si vous devez mélanger, faites‑le intentionnellement (par ex., vdev spécial pour les métadonnées) et surveillez attentivement.

Erreur 7 : Traiter les disques SMR comme des HDD normaux

Symptôme : Les resilvers et scrubs prennent une éternité ; les performances d’écriture s’effondrent sous charge soutenue.

Pourquoi : Le comportement d’écriture SMR peut être pénalisant pour les schémas de reconstruction de ZFS.

Correctif : Évitez les SMR pour les pools ZFS nécessitant des reconstructions prévisibles. Si vous êtes bloqué, réduisez la charge pendant le resilver et repensez la redondance.

9) Checklists / plan étape par étape

Checklist de conception (avant de créer le pool)

Classifiez la charge : majoritairement séquentielle (sauvegarde/média), majoritairement aléatoire (VM/DB), mixte (répertoires home), sync‑heavy (bases de données/NFS).
Choisissez le type de vdev selon les besoins d’IOPS : miroirs pour les IOPS ; RAIDZ pour capacité/débit avec moins d’attentes IOPS.
Décidez ashift en amont : supposez des secteurs 4K+ ; vérifiez, puis créez le pool. Considérez ceci comme irréversible.
Planifiez la marge : planification de capacité pour rester hors de la zone 90%.
Décidez la politique de snapshots : fréquence et rétention par dataset, pas une approche unique.
Décidez la stratégie sync : si vous avez des charges sync‑heavy, planifiez un SLOG (miroir, PLP) ou acceptez la latence.

Plan de déploiement (première semaine en production)

Créez des datasets par charge (VMs, DBs, home, backups) plutôt qu’un monolithe unique.
Définissez les propriétés de base : compression=lz4, atime=off où approprié, recordsize par charge.
Implémentez la surveillance : santé zpool status, résultats de scrub, erreurs de checksum, capacité et tendances de durée de scrub.
Planifiez les scrubs pendant les fenêtres à faible trafic, mais ne les considérez pas optionnels.
Testez le rollback de snapshot sur des données non critiques pour que l’équipe ait la mémoire musculaire.
Testez zfs send/receive pour la restauration, pas seulement la création de sauvegarde.

Checklist de changement (avant d’« optimiser »)

Énoncez l’hypothèse : quelle métrique s’améliore, et pourquoi.
Mesurez la baseline avec une concurrence et des patterns d’I/O représentatifs de la production.
Changez un seul réglage à la fois : recordsize, sync, vdev spécial, etc.
Définissez des critères de rollback et répétez les étapes de rollback.
Observez pendant au moins un cycle business si la charge est cyclique.

10) FAQ

Q1: ZFS est‑il « plus sûr » qu’ext4/XFS ?

R : ZFS fournit des checksums de bout en bout et l’auto‑réparation avec redondance. ext4/XFS s’appuient généralement sur la couche périphérique sous‑jacente pour l’intégrité. Si vous vous souciez de la détection et réparation des corruptions silencieuses, ZFS a un avantage réel.

Q2: Ai‑je besoin de RAM ECC pour ZFS ?

R : L’ECC est fortement recommandé pour tout système de stockage sérieux, ZFS ou non. ZFS détecte bien la corruption au niveau disque, mais il ne peut pas réparer des données abîmées en RAM avant qu’elles ne soient checksummées. Beaucoup tournent sans ECC ; moins dorment bien en le faisant.

Q3: ZFS a‑t‑il toujours besoin de « beaucoup de RAM » ?

R : ZFS utilisera volontiers la RAM pour l’ARC, et plus de RAM améliore souvent les lectures. Mais ce n’est pas une exigence forte pour la correction. La vraie question est si votre charge bénéficie du cache. Si le working set ne tient pas, la RAM aide moins, et ext4/XFS peut sembler similaire.

Q4: Dois‑je activer la déduplication ?

R : Habituellement non en production généraliste. La dédup est gourmande en RAM et peut créer des falaises de performance si sous‑dimensionnée. Si vous avez un cas d’usage ciblé et mesuré (beaucoup d’images VM identiques) et que vous l’avez testé, peut‑être. Sinon, utilisez d’abord la compression.

Q5: Quelle est la différence entre ZIL et SLOG ?

R : Le ZIL est le journal d’intention sur disque utilisé pour gérer de manière sûre les écritures synchrones. Un SLOG est un périphérique séparé où ZFS peut placer ce journal pour accélérer les écritures sync. Sans SLOG, le ZIL réside sur les périphériques principaux du pool.

Q6: Quand `sync=disabled` est‑il acceptable ?

R : Presque jamais pour quelque chose que vous regretteriez de perdre. Cela peut être acceptable pour des données temporaires jetables ou certains pipelines d’ingestion en lecture seule où l’application tolère déjà la perte. Si vous n’êtes pas absolument sûr, considérez‑le comme « dangereux ».

Q7: Les snapshots remplacent‑ils les sauvegardes ?

R : Non. Les snapshots vous aident à récupérer rapidement d’erreurs logiques sur le même système. Les sauvegardes protègent contre la perte du pool, la perte de site et les erreurs d’administration qui suppriment à la fois les données et les snapshots. Utilisez les snapshots comme une couche, pas comme un substitut.

Q8: Pourquoi mon pool ralentit‑il en se remplissant ?

R : À mesure que l’espace libre diminue, ZFS a moins de régions contiguës à allouer, ce qui peut augmenter la fragmentation et le travail sur les métadonnées. De plus, CoW signifie qu’il cherche constamment de nouveaux emplacements pour écrire. Gardez une marge et planifiez les extensions de capacité.

Q9: ext4/XFS ont aussi des checksums, non ?

R : Ils ont des checksums pour certaines structures de métadonnées (journaux, etc.) selon les fonctionnalités. ZFS checksummise les données et métadonnées de bout en bout et valide à la lecture. C’est un niveau de couverture différent.

Q10: Si ZFS est si bon, pourquoi tout le monde ne l’utilise‑t‑il pas partout ?

R : Parce que les compromis sont réels : empreinte mémoire, surface de réglage, comportement CoW, et expertise opérationnelle. De plus, certains environnements obtiennent déjà ces bénéfices ailleurs (fonctionnalités SAN, garanties du cloud), ce qui rend ext4/XFS plus simple et plus sûr.

Conclusion

ZFS est ce que vous choisissez lorsque vous voulez que la couche de stockage se comporte en adulte : il vérifie ce qu’il lit, il peut réparer ce qu’il trouve, il rend les snapshots routiniers, et il vous fournit des primitives propres pour la réplication. En pratique, il change les types de pannes que vous voyez : moins de corruptions mystérieuses, des limites de performance plus honnêtes, et plus de moments « on peut revenir en arrière ».

ext4 et XFS remportent encore de nombreuses journées. Ils l’emportent quand vous avez besoin de simplicité, quand votre histoire d’intégrité est gérée ailleurs, quand votre équipe veut moins de réglages, et quand le comportement d’écriture en place prévisible compte plus que les snapshots et les checksums de bout en bout. Le meilleur choix n’est pas celui avec le plus de fonctionnalités ; c’est celui qui rend votre production ennuyeuse de la manière dont votre entreprise a besoin.