ZFS vs btrfs : où btrfs est agréable et où il pose problème

Ma position : ce que je déploie où

Si vous avez besoin d’un comportement prévisible sous charge, de sémantiques de récupération ennuyeuses mais fiables, et que vous pouvez tolérer la vision « ZFS est une pile de stockage, pas seulement un système de fichiers » : choisissez ZFS.

Si vous voulez une intégration étroite avec Linux, des snapshots du système racine simples, des itérations rapides, et que vous êtes prêt à apprendre les
modes de défaillance de btrfs : btrfs est réellement agréable — en particulier pour les postes de travail, les machines de build, et certains services
mono-nœud avec de bonnes sauvegardes.

Si vous pensez « je ferai RAID5/6 btrfs parce que c’est intégré et pratique », ne le faites pas. Utilisez mdraid en dessous, ou ZFS, ou le RAID matériel si nécessaire
(en acceptant les compromis). btrfs RAID5/6 s’est amélioré au fil des ans mais comporte encore suffisamment de mises en garde pour le traiter comme un médicament expérimental :
uniquement avec consentement éclairé et un second avis.

Faits intéressants et contexte historique (ce qui explique les angles vifs d’aujourd’hui)

• ZFS a été lancé chez Sun Microsystems comme un gestionnaire de volumes intégré + système de fichiers, conçu pour mettre fin à la corruption silencieuse et aux soucis du « RAID write hole ».
• btrfs a été créé chez Oracle comme système de fichiers Linux nouvelle génération avec pool, snapshots et checksumming, visant des objectifs similaires mais dans l’écosystème Linux.
• ZFS sur Linux est devenu OpenZFS, un projet multiplateforme qui a standardisé les fonctionnalités et le comportement sur illumos, Linux, et plus.
• btrfs a été intégré au noyau Linux et a évolué en public, ce qui est excellent pour la disponibilité mais signifie aussi que vous héritez des versions du noyau + outils comme réalité opérationnelle.
• Copy-on-write est l’ingrédient commun, mais les transaction groups de ZFS et les B-trees et stratégies d’allocation de btrfs entraînent des schémas de fragmentation et de latence différents.
• ZFS a une forte réputation pour les sémantiques de scrub/resilver, y compris la « réparation par redondance » qui est simple lorsque les mirrors/RAIDZ sont correctement configurés.
• btrfs RAID1 n’est pas « un RAID1 classique sur deux disques » ; c’est « deux copies réparties sur les dispositifs » au niveau des chunks, et cette nuance compte pour la capacité et les attentes en cas de panne.
• La licence de ZFS (CDDL) l’a tenu hors du noyau Linux, ce qui impacte le packaging et les décisions d’intégration pour les entreprises.
• btrfs send/receive a mûri avec des workflows axés sur les snapshots (pensez : déploiements OS quasi immuables et rollback rapide), ce que certaines distributions apprécient pour le système racine.

Modèles mentaux qui évitent les mauvaises décisions

1) ZFS veut contrôler l’histoire du bloc

ZFS s’attend à voir les disques (ou partitions) et à gérer la redondance, les décisions de cache et l’intégrité de bout en bout. Vous pouvez le superposer
à un RAID matériel, mais vous aveuglez ZFS sur le comportement des disques individuels et vous vous compliquez la vie quand quelque chose tourne mal.
Les meilleures fonctionnalités de ZFS apparaissent quand ZFS a une visibilité réelle.

2) btrfs veut être « le système de fichiers Linux qui fait beaucoup »

btrfs est dans le noyau, s’intègre bien avec systemd, les outils des distributions et les workflows de snapshots du système racine. Il préfère aussi être traité
comme un système de fichiers d’abord. La gestion de volumes est puissante, mais ce n’est pas forcément l’endroit où vous voulez prendre des risques.

3) Les deux sont CoW ; les deux peuvent punir les réécritures aléatoires à grande échelle

Bases de données, images VM et charges intensives de logs peuvent déclencher amplification d’écriture et fragmentation sur tout système CoW. ZFS a des réglages
comme recordsize, logbias, des special vdevs, et une histoire ARC/L2ARC mature. btrfs a des choix de compression, des options de montage,
et la possibilité de désactiver CoW par fichier (chattr +C). Aucun ne vous donne un déjeuner gratuit.

Une idée paraphrasée de John Allspaw : la fiabilité vient de traiter les opérations comme un problème de conception, pas comme un combat de pompiers.

Où btrfs est agréable

Snapshots du système racine qui ne semblent pas relever d’un projet scientifique

btrfs est fantastique quand votre OS est un ensemble de subvolumes et que les snapshots font partie du quotidien. Revenir après une mauvaise mise à jour ?
Facile. Créer un environnement de test jetable en snapshotant @home ou un arbre de build ? Facile.

Les distributions qui misent sur btrfs ne le font pas par nouveauté. Elles veulent des mises à jour presque atomiques et des rollbacks rapides sans greffer
un gestionnaire de volumes distinct. Dans le monde réel, « je peux revenir rapidement » est une fonctionnalité de disponibilité.

Send/receive simple pour de nombreux workflows

btrfs send/receive est une primitive de réplication pratique. Pour cibles de sauvegarde, environnements de labo, ou configurations « envoyer des snapshots vers une autre machine »,
c’est abordable et assez rapide. Vous pouvez l’intégrer à des timers, garder une rétention simple, et passer à autre chose.

Redimensionnement en ligne et gestion des dispositifs sans tout repenser

Ajouter un disque, retirer un disque, convertir des profils (par ex., single → RAID1), redimensionner des systèmes de fichiers en ligne — btrfs vous donne des outils pour
cela sans vous forcer à une couche LVM séparée. C’est pratique lorsque vous gérez des flottes de petits nœuds qui changent de forme.

Compression souvent « rentable »

La compression transparente (surtout zstd) est une superpuissance discrète. Elle peut réduire les écritures et prolonger l’endurance des SSD. Sur des charges mixtes,
c’est souvent un gain net. Sur des médias déjà compressés, c’est juste du CPU perdu — donc mesurez, n’allez pas à l’aveugle.

Les subvolumes sont utiles opérationnellement

Les subvolumes se comportent comme des systèmes de fichiers séparés pour les snapshots et quotas, tout en partageant le même pool. Cela facilite l’isolement des politiques de rétention :
garder des snapshots agressifs pour @, moins pour @var, et traiter les répertoires à fort churn séparément.

Blague n°1 : les subvolumes btrfs vous font sentir organisé — jusqu’à ce que vous réalisiez que votre politique de rétention des snapshots ressemble à une exposition de musée.

Où btrfs fait mal (et pourquoi)

Épuisement d’espace métadonnées : « No space left » alors que df indique que c’est correct

btrfs alloue l’espace en chunks pour les données et les métadonnées. Vous pouvez avoir beaucoup d’espace libre pour les données et être à l’arrêt parce que
les chunks de métadonnées sont pleins ou mal répartis sur les dispositifs. Les symptômes sont brutaux : les écritures échouent, les snapshots échouent, parfois
les suppressions échouent. On a l’impression d’une blague de mauvais goût.

La correction est généralement une combinaison de suppression de snapshots, d’exécution d’un balance ciblé, et parfois de conversion de profile de métadonnées.
La prévention passe par la surveillance de btrfs filesystem df et le maintien d’une marge de sécurité.

Balance : un outil de maintenance, pas un bouton magique « défragmenter ma vie »

Une balance réécrit des chunks. Cela peut être coûteux et peut dégrader les performances si vous la lancez au mauvais moment ou avec de mauvais filtres.
C’est parfois nécessaire pour corriger la distribution d’espace ou appliquer des changements de profile. Traitez la balance comme un instrument chirurgical, pas comme un balai.

Les sémantiques RAID peuvent surprendre les personnes formées au RAID de 2005

btrfs RAID1 est une réplication basée sur des chunks, pas nécessairement un miroir symétrique de « moitié de capacité » dans toutes les conditions de panne. RAID10 a
ses propres réalités de mise en page. Et RAID5/6 est la zone où il faut être extrêmement prudent : c’est là que les cas limites et les chemins de récupération deviennent compliqués
et où « ça a marché en test » peut se transformer en « pourquoi scrub trouve des erreurs irrécupérables ».

Fragmentation et amplification CoW : images VM et bases de données sont les victimes habituelles

CoW est excellent jusqu’à ce que vous réécriviez de gros fichiers en place encore et encore (images QCOW2, fichiers de base de données, spools de mail). btrfs peut
le gérer, mais il faut souvent désactiver CoW pour des chemins spécifiques, choisir les options de montage appropriées, et éviter de snapshotter aveuglément des fichiers à fort churn.

Les outils de récupération s’améliorent, mais peuvent toujours ressembler à de la spéléologie

Quand btrfs est sain, c’est agréable. Quand il ne l’est pas, vous passerez du temps avec btrfs check, des modes de secours, et des décisions très
prudentes sur l’opportunité de tenter une réparation hors ligne. Les outils existent, mais la courbe de confiance de l’opérateur est plus pentue.

Blague n°2 : « No space left on device » sur btrfs signifie parfois « il y a de l’espace, mais il est dans les métadonnées, et les métadonnées sont émotionnelles. »

Où ZFS l’emporte, franchement

Modèle d’intégrité prévisible : checksums, scrub, auto-réparation (quand la redondance existe)

La renommée de ZFS vient du checksumming de bout en bout avec réparation automatique depuis la redondance. Scrub est de première classe. Quand un disque ment
ou qu’un câble foire, ZFS a plus de chances de vous dire clairement ce qui s’est passé et ce qu’il a fait.

Clarté opérationnelle : pools, vdevs et règles que l’on peut enseigner

ZFS vous force à penser en vdevs. Ça paraît contraignant jusqu’à ce que vous soyez de garde. Le modèle est cohérent : mirrors sont des mirrors, RAIDZ est RAIDZ,
et vous n’avez pas le droit de faire les choses à moitié. Cette rigidité évite beaucoup de catastrophes créatives.

ARC/L2ARC et SLOG sont matures et bien compris

Le caching ZFS n’est pas de la magie, mais il est cohérent. Le dimensionnement ARC, les special vdevs pour métadonnées/blocs petits, et les dispositifs de log d’intention séparés
ont beaucoup de folklore opérationnel derrière eux — ce qui veut dire que beaucoup de personnes ont déjà fait les erreurs pour vous.

La réplication est ennuyeuse dans le bon sens

zfs send/receive est éprouvé au combat. Les flux incrémentiels sont fiables. Les cas limites sont connus. Si vous construisez une stratégie de snapshots et de rétention,
elle a tendance à continuer de fonctionner jusqu’à ce que vous changiez quelque chose de majeur (comme recordsize ou stratégie de chiffrement) sans y penser.

Le compromis : ZFS est plus lourd et plus « orienté pile de stockage »

ZFS a un appétit mémoire, une histoire de packaging différente sur Linux, et une forte préférence pour gérer les disques lui-même. En retour, vous obtenez un système qui se comporte de façon prévisible quand vous le traitez correctement. ZFS ne récompense pas l’improvisation.

Optimisation des performances : les leviers qui comptent vraiment

L’adéquation à la charge prime sur les micro-optimisations

Commencez par le pattern d’accès. Gros écrits séquentiels ? Écritures aléatoires synchrones ? Millions de petits fichiers ? Images VM ? Le choix du système de fichiers
et ses réglages doivent correspondre à la réalité. Si vous ne connaissez pas la réalité, mesurez-la d’abord. Deviner, c’est optimiser la mauvaise couche.

Les réglages btrfs qui changent la donne

• Compression : compress=zstd est souvent gagnant ; testez le coût CPU. Pour des charges sensibles à la latence, envisagez compress=zstd:1.
• NOCOW pour fichiers à réécriture fréquente : poser chattr +C sur des répertoires pour images VM/bases (et assurez-vous qu’aucun snapshot ne dépend des sémantiques CoW là).
• Autodefrag : aide pour certaines charges petites et aléatoires ; peut nuire sur I/O séquentiel important. Utilisez avec parcimonie et validez.
• Mise en cache d’espace / free space tree : les noyaux modernes gèrent mieux cela ; des versions d’outils incompatibles peuvent encore créer des étrangetés après des mises à jour.

Les réglages ZFS qui changent la donne

• recordsize : accordez-le à la charge. Les gros fichiers veulent des recordsize plus grands ; les bases veulent souvent des blocs plus petits.
• compression : lz4 est le « par défaut sensé » ; parfois zstd vaut le coup si pris en charge et si le CPU est disponible.
• comportement sync : ne désactivez pas les écritures sync pour « aller vite » sauf si vous acceptez de perdre des données que vous pensiez sûres.
• special vdev : peut transformer les charges riches en métadonnées, mais c’est aussi un engagement de conception : le perdre peut compromettre le pool.

Note sur les SSD, TRIM et l’amplification d’écriture

Les deux piles ont besoin d’un comportement discard/TRIM sensé. Trop agressif peut nuire à la latence ; trop absent peut dégrader les performances à long terme.
Pour ZFS, le trim périodique et la qualité du firmware des dispositifs importent. Pour btrfs, la différence entre l’option de montage discard et un fstrim périodique
est un choix de tuning à mesurer sur votre matériel.

Tâches pratiques avec commandes, sorties et décisions (12+)

Voici des actions réelles d’opérateur : ce que vous lancez, ce que vous vous attendez à voir, et quelle décision prendre ensuite. Je vais mélanger ZFS et btrfs pour que vous
puissiez comparer la « forme » des opérations.

Task 1: btrfs health check at a glance

cr0x@server:~$ sudo btrfs filesystem show
Label: 'rootfs'  uuid: 6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
	Total devices 2 FS bytes used 412.31GiB
	devid    1 size 931.51GiB used 520.00GiB path /dev/nvme0n1p2
	devid    2 size 931.51GiB used 520.00GiB path /dev/nvme1n1p2

Ce que cela signifie : appareils, tailles et « used » au niveau de l’allocation de chunks, pas identique à df.

Décision : si « used » approche la taille du dispositif, vous êtes saturé en chunks ; planifiez balance/libération d’espace avant de faire des changements.

Task 2: btrfs data vs metadata usage (the classic trap detector)

cr0x@server:~$ sudo btrfs filesystem df /
Data, RAID1: total=480.00GiB, used=402.10GiB
Metadata, RAID1: total=16.00GiB, used=15.72GiB
System, RAID1: total=32.00MiB, used=16.00KiB

Ce que cela signifie : les métadonnées sont presque pleines. C’est ainsi que vous obtenez « ENOSPC » avec de l’espace libre pour les données.

Décision : arrêtez le churn des snapshots, supprimez les anciens snapshots, puis lancez une balance ciblée pour les métadonnées (pas une balance complète).

Task 3: targeted btrfs balance for metadata pressure

cr0x@server:~$ sudo btrfs balance start -musage=50 /
Done, had to relocate 12 out of 32 chunks

Ce que cela signifie : il a relocalisé des chunks de métadonnées qui étaient moins de 50% utilisés, consolidant et libérant de l’espace.

Décision : revérifiez btrfs filesystem df. Si c’est encore serré, répétez avec un seuil un peu plus élevé ou adressez le nombre de snapshots et le churn des petits fichiers.

Task 4: btrfs scrub status and what “corrected” implies

cr0x@server:~$ sudo btrfs scrub status /
UUID:             6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
Scrub started:    Sat Dec 21 02:11:03 2025
Status:           finished
Duration:         0:32:44
Total to scrub:   410.23GiB
Rate:             213.45MiB/s
Error summary:    read=0, csum=2, verify=0, corrected=2, uncorrectable=0

Ce que cela signifie : les checksums ont mismaché deux fois et la redondance a réparé.

Décision : considérez les erreurs corrigées comme un signal matériel. Vérifiez SMART, le câblage/backplane et les logs du noyau ; ne vous contentez pas de célébrer.

Task 5: btrfs device stats (persistent counters)

cr0x@server:~$ sudo btrfs device stats /
[/dev/nvme0n1p2].write_io_errs   0
[/dev/nvme0n1p2].read_io_errs    0
[/dev/nvme0n1p2].flush_io_errs   0
[/dev/nvme0n1p2].corruption_errs 2
[/dev/nvme0n1p2].generation_errs 0
[/dev/nvme1n1p2].write_io_errs   0
[/dev/nvme1n1p2].read_io_errs    0
[/dev/nvme1n1p2].flush_io_errs   0
[/dev/nvme1n1p2].corruption_errs 0
[/dev/nvme1n1p2].generation_errs 0

Ce que cela signifie : des erreurs de corruption sont survenues sur un chemin de dispositif.

Décision : lancez des tests SMART étendus et inspectez dmesg pour des resets NVMe ; planifiez un remplacement proactif si cela se reproduit.

Task 6: Disable CoW for a directory holding VM images (btrfs)

cr0x@server:~$ sudo mkdir -p /var/lib/libvirt/images
cr0x@server:~$ sudo chattr +C /var/lib/libvirt/images
cr0x@server:~$ lsattr -d /var/lib/libvirt/images
---------------C------ /var/lib/libvirt/images

Ce que cela signifie : les nouveaux fichiers créés dans ce répertoire seront NOCOW, réduisant la fragmentation pour les images à réécritures fréquentes.

Décision : faites cela avant de créer les gros fichiers d’image ; les fichiers existants ne seront pas réécrits automatiquement. Aussi :
ne snapshottez pas ces images en supposant l’efficacité CoW.

Task 7: btrfs list subvolumes and decide snapshot retention

cr0x@server:~$ sudo btrfs subvolume list -t /
ID 256 gen 19234 top level 5 path @
ID 257 gen 19233 top level 5 path @home
ID 890 gen 19110 top level 256 path .snapshots/2025-12-01
ID 891 gen 19140 top level 256 path .snapshots/2025-12-02
ID 892 gen 19170 top level 256 path .snapshots/2025-12-03

Ce que cela signifie : les snapshots s’accumulent vite ; chacun épingle des extents et peut augmenter la pression sur les métadonnées.

Décision : définissez une rétention défendable (quotidien pendant 7–14 jours, hebdomadaire plusieurs semaines), puis appliquez-la.

Task 8: ZFS pool health and error triage

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear'.
  scan: scrub repaired 0B in 0 days 00:41:12 with 0 errors on Sat Dec 21 03:02:11 2025
config:

	NAME                         STATE     READ WRITE CKSUM
	tank                         ONLINE       0     0     0
	  mirror-0                   ONLINE       0     0     0
	    ata-SAMSUNG_SSD1         ONLINE       0     0     1
	    ata-SAMSUNG_SSD2         ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
/tank/vmstore/qemu/win10.qcow2

Ce que cela signifie : ZFS a détecté une erreur de checksum liée à un chemin de fichier. C’est de l’or pour la réponse à incident.

Décision : restaurez/réparez le fichier affecté depuis la sauvegarde ; lancez SMART sur le disque avec incrément CKSUM ; envisagez un remplacement.

Task 9: ZFS dataset properties that commonly explain performance

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

Ce que cela signifie : ces réglages expliquent souvent la différence entre « correct » et « pourquoi mes VM saccadent ».

Décision : pour les images VM, envisagez un recordsize plus petit et éventuellement logbias=throughput selon le pattern de sync ; changez seulement après mesure.

Task 10: ZFS ARC pressure check

cr0x@server:~$ sudo arcstat -f time,read,miss,arcsz,c
    time  read  miss   arcsz      c
03:12:01   842    71   19.2G   24.0G
03:12:02   901    88   19.2G   24.0G
03:12:03   877    92   19.2G   24.0G

Ce que cela signifie : taille ARC (~19G) vs cible (~24G), miss en hausse. Si les misses sont élevés sous charge stable, vous manquez peut-être de RAM.

Décision : ajoutez de la RAM ou ajustez la charge/les paramètres des datasets ; n’ajoutez pas L2ARC sans comprendre le working set.

Task 11: ZFS scrub and what to do with results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Sat Dec 21 03:20:10 2025
	12.3G scanned at 1.02G/s, 1.4G issued at 118M/s, 480G total
	0B repaired, 0.29% done, 1:17:44 to go
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : le scrub progresse ; les lignes « repaired » et « errors » sont clés pour l’intégrité.

Décision : si vous voyez des réparations ou des erreurs CKSUM, corrélez avec SMART et planifiez le remplacement du dispositif ; si c’est propre, montez dans la pile.

Task 12: btrfs: detect whether free space is fragmented across chunks

cr0x@server:~$ sudo btrfs filesystem usage -T /
Overall:
    Device size:                   1.82TiB
    Device allocated:              1.04TiB
    Device unallocated:          816.00GiB
    Device missing:                  0.00B
    Used:                        824.20GiB
    Free (estimated):            496.10GiB      (min: 248.05GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:               512.00MiB      (used: 0.00B)

Ce que cela signifie : « Free (estimated) » vs « min » montre l’incertitude due à l’allocation en chunks ; « min » est le nombre conservateur.

Décision : dimensionnez votre marge de sécurité en utilisant « min », pas l’estimation optimiste, surtout avant de grosses opérations de snapshot.

Task 13: ZFS: identify which dataset is consuming space and snapshots

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots -S used
NAME                USED  AVAIL  REFER  USEDBYSNAPSHOTS
tank                3.21T  5.07T   192K            0B
tank/vmstore        1.84T  5.07T  1.02T          820G
tank/backups        1.12T  5.07T  1.10T          18G
tank/home           256G  5.07T   241G          15G

Ce que cela signifie : des snapshots épinglent 820G dans tank/vmstore.

Décision : ajustez la rétention des snapshots ou excluez les datasets VM à fort churn des politiques agressives ; considérez la fréquence de réplication séparément.

Task 14: btrfs: replace a failing device (conceptual “do it before it dies” move)

cr0x@server:~$ sudo btrfs replace start /dev/nvme1n1p2 /dev/nvme2n1p2 /
Started on Sat Dec 21 03:40:11 2025, estimated time: 2:10:00
cr0x@server:~$ sudo btrfs replace status /
Status: finished

Ce que cela signifie : btrfs a copié les données vers le dispositif de remplacement en ligne.

Décision : après la fin, vérifiez que scrub est propre, puis retirez proprement l’ancien dispositif s’il est encore présent.

Playbook de diagnostic rapide : trouvez le goulot avant de « tuner » quoi que ce soit

Première étape : décidez s’il s’agit de capacité/métadonnées, d’intégrité ou de latence

• Si les écritures échouent (ENOSPC) mais que df semble correct : suspectez un épuisement des métadonnées btrfs ou un épinglage par des snapshots.
• Si les applications voient de la corruption ou des erreurs de checksum : suspectez le dispositif, le contrôleur, le câblage, le firmware, ou le comportement en cas de perte d’alimentation.
• Si la latence picote mais que le débit est correct : suspectez des écritures sync, de la fragmentation, ou des misses de cache.

Deuxième étape : vérifiez la vérité propre à la couche de stockage

Pour btrfs : btrfs filesystem df, btrfs filesystem usage -T, btrfs scrub status et les logs du noyau.
Pour ZFS : zpool status -v, zpool iostat -v 1 et les propriétés des datasets.

Troisième étape : isolez si vous êtes limité par le CPU, la RAM ou les dispositifs

• Iowait élevé + faible utilisation disque : souvent de l’ordonnancement, des firmwares, des problèmes de contrôleur, ou de la latence sync.
• CPU élevé dans kswapd ou pression mémoire : dimensionnement ARC ZFS ou pénurie générale de RAM.
• Un dispositif saturé : allocation/balance btrfs inégale, ou un goulot d’étranglement de conception ZFS vdev (un disque lent empoisonne la latence d’un mirror/RAIDZ).

Quatrième étape : ne tunez qu’après

Le tuning sans diagnostic transforme une situation récupérable en week-end gâché. Établissez la contrainte, modifiez une variable, puis mesurez de nouveau.

Erreurs courantes : symptôme → cause principale → correction

1) « No space left on device » alors qu’il reste des centaines de GiB

Symptôme : la création de snapshot échoue, les écritures échouent, les suppressions échouent de façon intermittente.

Cause principale : chunks de métadonnées btrfs pleins ; l’espace libre est piégé dans des chunks de données ou mal réparti sur les dispositifs.

Correction : supprimez des snapshots, stoppez le churn, lancez btrfs balance start -musage=50 (ou similaire), et surveillez btrfs filesystem df. Gardez de la marge.

2) « Scrub corrected errors » est ignoré

Symptôme : erreurs de checksum corrigées occasionnellement pendant le scrub ; le système semble sinon correct.

Cause principale : instabilité du dispositif ou du chemin : NVMe instable, câblage, HBA, backplane ou bugs firmware.

Correction : traitez les erreurs corrigées comme un avertissement précoce. Lancez des tests SMART, vérifiez dmesg, envisagez un remplacement proactif.

3) performance btrfs dégrade après une période riche en snapshots

Symptôme : latence d’écriture aléatoire en hausse, opérations métadonnées lentes, temps de commit augmentés.

Cause principale : fragmentation + extents épinglés par de nombreux snapshots, plus frais de métadonnées.

Correction : réduisez la rétention des snapshots ; isolez les données à fort churn dans des répertoires NOCOW ou des subvolumes séparés non snapshotés fréquemment.

4) ZFS « optimisé » en désactivant sync, puis perte de données après événement d’alimentation

Symptôme : la charge est rapide ; après crash/panne de courant, base de données ou image VM corrompue.

Cause principale : sync=disabled (ou application s’appuyant sur fsync) a cassé les hypothèses de durabilité.

Correction : définissez sync=standard (ou always si nécessaire), utilisez un SLOG approprié si la latence sync est le problème.

5) Hypothèse « btrfs RAID1 signifie que je peux perdre n’importe quel disque à tout moment »

Symptôme : la perte d’un dispositif provoque des données manquantes ou un montage échoué dans certaines configurations/profile.

Cause principale : mauvaise compréhension de la réplication basée sur chunks et de l’allocation ; mélanger des tailles de dispositifs ou conditions proches du plein réduit la flexibilité.

Correction : validez les scénarios de panne, gardez de l’espace libre, utilisez des dispositifs homogènes si possible, et testez les workflows de remplacement/retrait en avance.

6) Pool ZFS conçu avec un seul grand vdev RAIDZ pour I/O alétoire

Symptôme : IOPS lecture/écriture aléatoires catastrophiques par rapport aux attentes.

Cause principale : le vdev est l’unité d’IOPS ; un grand vdev RAIDZ a des IOPS limités comparé à plusieurs mirrors.

Correction : pour des charges IOPS-intensives, préférez des vdevs en miroir (mirrors en bande) ou plus de vdevs ; n’attendez pas de la largeur RAIDZ qu’elle crée des IOPS.

Trois mini-récits d’entreprise (anonymisés, plausibles et douloureusement familiers)

Récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a migré des agents de build vers btrfs parce que les snapshots facilitaient le nettoyage. Chaque build s’exécutait dans un snapshot jetable,
puis revenait. L’équipe adorait. Le stockage restait propre. Les déploiements se sont accélérés.

Puis le cluster de build a commencé à échouer avec « No space left on device ». df -h montrait des centaines de gigaoctets libres. L’on-call a supposé un problème d’overlay de conteneur
et a redémarré plein d’agents, ce qui n’a servi strictement à rien.

La mauvaise hypothèse : « l’espace libre est de l’espace libre ». Sur btrfs, l’allocation des métadonnées peut être votre véritable limite. Ils avaient un grand nombre de petits fichiers,
plus une rétention de snapshots agressive « au cas où », et les chunks metadata RAID1 étaient saturés.

La correction n’a pas été héroïque. Ils ont supprimé d’anciens snapshots, lancé une balance ciblée pour les métadonnées, et réduit la fréquence des snapshots. Ils ont aussi séparé les caches d’artifacts
de build dans un subvolume qui n’était pas snapshotté du tout. Le cluster est redevenu ennuyeux.

La leçon : btrfs est amical jusqu’à ce que vous le traitiez comme ext4 avec des super-pouvoirs. Ce n’est pas le cas. Surveillez les métadonnées comme une ressource de premier ordre, parce que c’en est une.

Récit 2 : L’optimisation qui a mal tourné

Une société du secteur finance utilisait ZFS pour le stockage VM. Quelqu’un a remarqué la latence d’écriture sync et a proposé la solution classique : « temporairement » mettre
sync=disabled sur le dataset VM. Les graphes se sont améliorés immédiatement. Des high-fives ont été échangés. Un ticket a été créé pour « revoir ça plus tard. »
Le ticket a vécu longtemps dans le backlog.

Quelques semaines plus tard, un incident d’alimentation s’est produit — rien de dramatique, juste un reboot de PDU qui a duré plus longtemps que prévu. Plusieurs VMs sont revenues
avec systèmes de fichiers corrompus. Une base de données a démarré mais présentait des incohérences silencieuses qui sont apparues sous forme d’erreurs applicatives, ce qui est le pire :
l’apparence d’un bug logiciel.

Après incident, ils ont découvert que le stockage avait été configuré pour mentir. Les applications faisaient le bon travail (fsync), et la couche de stockage haussait les épaules.

Le travail correctif a été coûteux : restauration depuis des sauvegardes, validation des données, et reconstruire la confiance. La vraie solution de performance a été ennuyeuse :
un petit dispositif SLOG fiable pour les datasets sync-intensifs, et le tuning de recordsize pour les workloads VM. La latence s’est améliorée sans jouer la durabilité.

La leçon : les « gains » de performance qui changent les sémantiques de durabilité ne sont pas des optimisations. Ce sont des paris. Les systèmes de production se souviennent de vos paris.

Récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise du domaine santé exploitait un cluster de stockage ZFS avec une routine stricte : scrubs hebdomadaires, alertes sur tout incrément de checksum,
et une politique « les erreurs corrigées exigent un ticket ». Les gens roulaient des yeux parce que la plupart des semaines rien ne se passait.

Un scrub a signalé un petit nombre d’erreurs corrigées sur un disque d’un mirror vdev. Le système est resté en ligne ; les utilisateurs n’ont rien remarqué.
L’on-call a ouvert le ticket requis et planifié une fenêtre de maintenance pour remplacer le disque.

Pendant le remplacement, ils ont trouvé que le disque avait des attributs SMART limites et des resets de lien intermittents dans les logs. Il n’était pas mort, juste
peu fiable. Une semaine plus tard, un disque du même modèle dans un autre châssis a lâché complètement. Parce qu’ils avaient remplacé le disque « avertisseur » tôt,
ils ont évité un scénario de double panne qui aurait pu mener à une longue restauration.

Entre-temps, leurs sauvegardes et réplications étaient vérifiées mensuellement avec des drills de restauration. Quand la direction demandait pourquoi toutes ces procédures « ennuyeuses »,
la réponse était simple : le jour où vous en aurez besoin, vous n’aurez pas la possibilité de négocier.

La leçon : scrubs, alertes et politiques de remplacement disciplinées sont ennuyeux. L’ennui est le son de l’uptime.

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

Choisir entre ZFS et btrfs (checklist de décision)

1. Définissez le domaine de défaillance : nœud unique, ou multi-nœud avec réplication ? Si nœud unique et conséquence élevée : penchez ZFS.
2. Définissez la charge : images VM, bases de données, ou CI à petits fichiers ? Planifiez le comportement CoW explicitement.
3. Décidez de la redondance : mirrors/RAIDZ vs profiles btrfs vs mdraid sous btrfs. Évitez btrfs RAID5/6 en environnements critiques.
4. Définissez la politique de snapshots : rétention, fréquence, et où les snapshots sont interdits (bases/VM sans plan).
5. Planifiez la surveillance : résultats de scrub, erreurs de checksum, usage des métadonnées (btrfs), santé des pools (ZFS), SMART partout.
6. Entraînez les workflows de remplacement : remplacez un disque en test. Chronométrez. Documentez. Rendez-le ennuyeux.

Baseline opérationnelle btrfs (hebdomadaire/mensuel)

1. Scrub hebdomadaire (étalé entre hôtes).
2. Vérification hebdomadaire : btrfs filesystem df et btrfs filesystem usage -T pour la pression des métadonnées.
3. Rétention de snapshots appliquée avec un plafond dur.
4. Trimestriel : testez le workflow btrfs replace en staging.

Baseline opérationnelle ZFS (hebdomadaire/mensuel)

1. Scrubs réguliers (souvent mensuels pour grands pools, hebdomadaires pour matériel plus sujet aux pannes).
2. Alerte sur tout incrément CKSUM dans zpool status et toute « erreur permanente » avec chemins de fichiers.
3. Snapshots + réplication avec drills de restauration périodiques.
4. Politique de capacité : ne pas faire chauffer les pools ; garder de la marge pour le resilver et la fragmentation.

FAQ

1) btrfs est-il « prêt pour la production » ?

Pour de nombreux usages, oui : disque unique, RAID1/10, systèmes racine, workflows centrés snapshots, et cibles de sauvegarde. Mais « prêt pour la production »
dépend de si votre équipe comprend le comportement des métadonnées, la balance, et les limitations du profile RAID choisi.

2) ZFS est-il toujours plus sûr que btrfs ?

ZFS a une plus longue réputation pour l’intégrité et la récupération prévisible, surtout avec redondance. Mais la sécurité dépend aussi du matériel,
de la surveillance, de la discipline opérationnelle, et de ne pas « optimiser » la durabilité.

3) Dois-je utiliser btrfs RAID5/6 ?

Si vous avez besoin de fiabilité ennuyeuse, évitez-le. Utilisez RAIDZ ZFS, ou mdraid (5/6) avec un système de fichiers plus simple, ou redessinez avec des mirrors.
La commodité n’est pas une fonctionnalité pendant une reconstruction.

4) Pourquoi btrfs affiche-t-il des estimations d’espace libre avec « min » ?

Parce que l’allocation en chunks et les profiles affectent la quantité d’espace réellement utilisable pour de nouvelles allocations. La valeur « min » conservatrice
est celle à laquelle vous devez vous fier pour la planification de sécurité.

5) ZFS peut-il être utilisé comme système racine sur Linux ?

Oui, mais cela dépend du support de la distribution, de l’intégration initramfs et du packaging. Opérationnellement, c’est faisable, mais btrfs semble généralement
plus natif pour les workflows de snapshots racine sous Linux.

6) Quelle est la façon la plus rapide d’améliorer les performances VM sur btrfs ?

Placez les images VM dans des répertoires NOCOW (définis avant la création des fichiers), évitez de les snapshotter agressivement, et validez avec des métriques de latence.
Vérifiez aussi la compression et autodefrag ; ils peuvent aider ou nuire selon les patterns d’accès.

7) Quelle est la façon la plus rapide d’améliorer les performances VM sur ZFS ?

Utilisez des mirrors pour les IOPS, réglez les propriétés du dataset de façon appropriée (recordsize, compression), gardez le comportement sync correct, et ajoutez un SLOG
seulement si vous avez une latence d’écriture sync réelle et un dispositif fiable.

8) Ai-je encore besoin de sauvegardes si j’ai des snapshots ?

Oui. Les snapshots ne sont pas des sauvegardes ; ils vivent dans le même domaine de défaillance. ZFS et btrfs rendent la réplication par snapshots faisable — utilisez-la,
et vérifiez les restaurations.

9) Combien d’espace libre dois-je garder ?

Plus que ce que vous voulez. Pour btrfs, de la marge réduit les crises de métadonnées et rend la balance/relocation possibles. Pour ZFS, de la marge améliore les performances
et la sécurité du resilver. Faire tourner « à fond » transforme les tâches de maintenance en incidents.

10) Lequel est plus facile à exploiter avec une petite équipe ?

Si l’équipe est Linux-first et veut des snapshots racine et des outils simples : btrfs peut être plus facile. Si l’équipe veut un modèle strict et des sémantiques de récupération prévisibles :
ZFS tend à réduire les surprises, au prix d’apprendre son vocabulaire.

Étapes suivantes (conclusion pratique)

Choisissez ZFS lorsque vous voulez que la pile de stockage se comporte comme un adulte : signaux d’échec clairs, valeurs par défaut d’intégrité fortes, et une conception qui
impose une bonne architecture. Choisissez btrfs lorsque vous voulez des workflows de snapshots natifs Linux, des subvolumes flexibles, et que vous êtes prêt à surveiller
les métadonnées et à traiter balance/scrub comme un entretien de routine.

Ensuite faites le travail peu glamour :

• Notez votre politique de rétention des snapshots. Appliquez-la automatiquement.
• Planifiez des scrubs. Alertez sur les erreurs corrigées. Traitez-les comme de la fumée matérielle.
• Entraînez le remplacement de disque sur une machine non critique. Chronométrez. Documentez.
• Pour les points douloureux CoW (VM, bases), faites un plan explicite : répertoires NOCOW sur btrfs, tuning de dataset et conception de vdev sur ZFS.
• Faites un drill de restauration. Si vous ne pouvez pas restaurer, vous n’avez pas de sauvegarde — vous avez un vœu.

Le stockage est l’endroit où l’optimisme vient prendre sa retraite. Configurez-le pour qu’il soit ennuyeux, et il vous rendra la pareille en vous permettant de dormir.