ZFS vs btrfs : instantanés, RAID, récupération — lequel mord le moins ?

janvier 11, 2026 • février 3, 2026 • Lecture : 33 min • Views: 12

Cet article vous a aidé ?

Il existe un type particulier de page consultée à minuit qui vous apprend plus sur les systèmes de fichiers que n’importe quel benchmark : « pics de latence stockage », « VMs gelées », « fenêtre de sauvegarde manquée » et la sourde angoisse que vos instantanés soient devenus une décharge. ZFS et btrfs promettent tous deux des fonctionnalités modernes — CoW, instantanés, checksums, auto-réparation. En pratique, ce sont deux philosophies différentes de gestion de la douleur.

Ceci est une comparaison pour opérateurs : ce qui casse, comment ça casse, ce que vous pouvez automatiser en toute confiance, et ce que vous devriez répéter avant que la production ne vous l’impose à 3 h du matin. Nous parlerons des instantanés, du RAID, de la récupération, des performances et des habitudes opérationnelles ennuyeuses qui vous gardent employé.

La thèse : lequel mord le moins ?

Si votre priorité absolue est l’intégrité prévisible, des outils matures et une histoire de récupération la moins surprenante — en particulier pour les pools volumineux, la virtualisation lourde ou une longue rétention — ZFS mord moins. Il est opinionné, strict et généralement dans le vrai. Vous payez en appétit RAM, en complexité de tuning et parfois en politique de licence, mais vous obtenez un système de fichiers qui se comporte comme s’il s’attendait à être blâmé — et qui est venu avec des preuves.

Si votre priorité est l’intégration native au noyau, une disposition flexible de subvolumes et des workflows « instantanés partout » sous Linux — notamment sur des nœuds uniques et des distributions qui l’encapsulent proprement — btrfs peut mordere moins. Il est maintenant remarquablement capable, mais son histoire RAID (particulièrement le RAID parité) comporte des mises en garde qui ne sont pas théoriques. Ce n’est pas « mauvais », mais cela exige de savoir quelles fonctionnalités sont ennuyeusement stables et lesquelles sont encore un peu… aventureuses.

Mon biais de production, acquis à la dure : ZFS pour la redondance multi-disque sérieuse et les jeux de données longue durée. btrfs pour les systèmes racine, les instantanés OS pour postes/serveurs et les configurations miroir simples où l’intégration noyau-native et la commodité des outils comptent plus que la sophistication maximale du RAID.

Blague #1 : Un système de fichiers, c’est comme un parachute — si vous cherchez à savoir s’il marche, vous avez déjà fait des choix de vie intéressants.

Faits intéressants et contexte historique (les parties que l’on oublie)

ZFS est né chez Sun Microsystems comme une pile de stockage bout en bout : système de fichiers + gestionnaire de volumes + RAID + checksums, conçu pour éliminer la « corruption silencieuse » et les conjectures opérationnelles.
btrfs a commencé chez Oracle comme un système de fichiers CoW natif Linux avec instantanés et checksumming, visant à concurrencer les fonctionnalités de type ZFS tout en vivant dans le noyau.
Le RAIDZ de ZFS n’est pas un RAID-5/6 classique ; il est conçu pour éviter le « write hole » grâce au copy-on-write et aux groupes de transactions, réduisant toute une classe de corruptions partielles de stripe.
La réputation initiale de btrfs a été marquée par des problèmes de RAID5/6. Beaucoup d’équipes ont appris (douloureusement) à traiter le RAID parité de btrfs comme « à éviter, sauf si vous savez exactement à quoi vous vous engagez ».
Les deux systèmes checksumment les données, mais ZFS fait de l’intégrité la promesse centrale, tandis que btrfs fournit l’intégrité au sein d’un système de fichiers Linux qui doit aussi s’accommoder de l’écosystème noyau plus large.
Les scrubs ne sont pas des sauvegardes. Les deux scrubs (ZFS scrub et btrfs scrub) sont des processus de vérification d’intégrité ; ils ne peuvent réparer que s’il existe des données redondantes disponibles.
zfs send/receive est devenu la référence pour la réplication rapide et peu coûteuse au niveau blocs/enregistrements. btrfs send/receive existe aussi, et il est excellent — quand votre discipline de subvolumes/instantanés est propre.
La compression est devenue courante grâce aux systèmes CoW. ZFS a popularisé « activez-la, c’est souvent plus rapide » ; btrfs a rendu la compression accessible et native au noyau, avec un contrôle par subvolume.
« Instantanés » sont des astuces métadata, pas des disques magiques. Les deux systèmes peuvent créer des instantanés instantanément, mais une longue rétention sans élagage devient une dette opérationnelle avec intérêts.

Modèles mentaux : ce que croit chaque système de fichiers

ZFS : le système de stockage qui veut prendre le problème en entier

ZFS ne veut pas être « un système de fichiers posé sur le RAID de quelqu’un d’autre ». Il veut être le système de fichiers, le RAID, le gestionnaire de volumes et la couche d’intégrité. C’est pourquoi un pool ZFS (« zpool ») contient des vdevs, et ces vdevs définissent la redondance. Le système de fichiers (« dataset ») s’assoit au-dessus et hérite des propriétés. Une fois que vous avez intériorisé cela, ZFS cesse de paraître étrange et commence à ressembler à un adulte très strict.

Dans le monde ZFS, l’unité primaire de risque est le vdev. Perdez un vdev, vous perdez le pool. Vous n’« ajoutez pas de disques à RAIDZ plus tard » sans planification. Vous concevez la largeur des vdevs et la redondance dès le départ (ou vous acceptez les options d’expansion existantes selon votre version et vos contraintes opérationnelles). ZFS récompense la patience et punit l’improvisation.

btrfs : le système de fichiers natif Linux qui veut être flexible

btrfs se place plus près de l’identité « système de fichiers d’abord », avec un support multi-périphérique intégré qui peut ressembler à du RAID. Il utilise les subvolumes et les instantanés comme primitives organisationnelles de première classe, ce qui le rend merveilleux pour les modèles de rollback OS. Il s’intègre aussi bien au noyau, ce qui compte pour les distributions, les chargeurs d’amorçage et la réalité « on met juste à jour la machine » dans les flottes.

La flexibilité de btrfs est réelle : vous pouvez ajouter des dispositifs, convertir les profils de données et réorganiser avec balance. Mais la flexibilité est à double tranchant. Si ZFS est strict et vous protège de vous-même, btrfs vous permet parfois de faire la chose dangereuse parce que c’est techniquement autorisé.

Instantanés & clones : puissance et pièges

Comment les instantanés se comportent réellement

Les instantanés ZFS et btrfs sont tous deux bon marché à créer et coûteux à conserver indéfiniment. Le coût n’est pas l’instantané lui-même ; ce sont les blocs anciens retenus. Si vous prenez un instantané d’un dataset puis que vous réécrivez une grande image VM tous les jours, vous vous êtes en fait inscrit pour une « histoire infinie » à moins de faire du pruning. Votre espace libre ne disparaîtra pas linéairement ; il s’évanouira par tranches gênantes, à des moments émotionnellement inopportuns.

Instantanés ZFS : prévisibles opérationnellement

Les instantanés ZFS sont stables, largement utilisés et intégrés aux workflows de réplication. Les clones sont des instantanés sur lesquels vous pouvez écrire. ZFS vous donne aussi des primitives propres comme les holds (pour empêcher la suppression), des propriétés de dataset pour la récursion, et des streams send/receive bien compris.

Le piège des instantanés ZFS n’est généralement pas la correction — c’est la capacité et la fragmentation. Un dataset chargé d’instantanés avec beaucoup de petites écritures aléatoires peut devenir désordonné. Pourtant, le « désordre » ressemble généralement à « performances dégradées et espace serré », pas à « métadata du système de fichiers en feu ».

Instantanés btrfs : fantastiques pour OS et discipline de subvolumes

Les instantanés btrfs brillent quand vous traitez les subvolumes comme des frontières : @ pour root, @home, peut-être @var ou @docker, et vous snapshottez ceux que vous voulez réellement restaurer. C’est là que btrfs donne l’impression de tricher : instantané instantané, rollback rapide, expérimentation facile.

Le piège des instantanés btrfs survient lorsque les gens snapshottent tout sans réfléchir aux répertoires churny (images VM, bases de données, containers). Les instantanés retiennent des extents, et les workloads à fort churn peuvent transformer votre « joli filet de sécurité de rollback » en une fuite d’espace au ralenti qui ne se révèle qu’au cours d’un incident.

RAID : ce qui est intégré, ce qui est implicite, ce qui est risqué

RAID ZFS : mirrors et RAIDZ à la façon ZFS

La redondance ZFS est définie au niveau du vdev : mirrors, RAIDZ1/2/3. Ajoutez des vdevs pour étendre. Remplacez des disques pour guérir. Scrub pour vérifier. Resilver pour reconstruire. Ce n’est pas « setter et oublier », mais c’est cohérent.

Vérité opérationnelle clé : l’IOPS dépend surtout du nombre de vdevs, surtout avec des mirrors. Un seul vdev RAIDZ large peut offrir un débit séquentiel impressionnant et sembler lent pour l’IO aléatoire comparé à plusieurs vdevs mirror. Le système de fichiers n’est pas lent ; votre géométrie l’est.

RAID btrfs : des profils, pas des arrays classiques

btrfs parle de profils : profile de données (single, DUP, RAID1, RAID10, RAID5/6) et profile de métadonnées (souvent RAID1 même si les données sont single). C’est puissant : vous pouvez prioriser la sécurité des métadonnées même sur une configuration mono-disque en utilisant DUP (sur un seul device, il stocke deux copies — utile contre certains patterns de bad-sector, pas un substitut à la redondance).

La grande mise en garde reste le RAID parité. Les profils de mirroring (RAID1/RAID10) sont largement utilisés et généralement fiables. Les profils de parité (RAID5/6) ont eu une longue histoire de cas limites et sont encore traités avec prudence dans beaucoup d’environnements de production. Si vous construisez « ceci doit survivre à des pannes bizarres », btrfs RAID1/10 est la voie la plus sûre.

Blague #2 : « RAID n’est pas une sauvegarde » est l’équivalent stockage de « ne touche pas la cuisinière » — tout le monde hoche la tête, puis quelqu’un touche la cuisinière quand même.

Récupération : ce que vous pouvez réparer, ce que vous ne pouvez pas

Récupération ZFS : scrubs, resilvers et l’art de ne pas paniquer

L’histoire de récupération ZFS est cohésive : détecter la corruption via les checksums, réparer grâce à la redondance, suivre les erreurs par périphérique et fournir des états de santé clairs. Quand ça part en vrille, c’est souvent d’une manière diagnostiquable : un disque renvoie des erreurs, un câble est intermittent, un contrôleur ment. ZFS vous le dira haut et fort.

L’avantage opérationnel le plus important : vous pouvez faire confiance au signal. Si ZFS dit qu’il a réparé X octets et qu’un device est en faute, vous pouvez agir avec une grande confiance. Cette confiance vaut beaucoup quand vous jonglez avec des parties prenantes et que l’horloge crie.

Récupération btrfs : bons outils, plus de nuance et « connais ton mode »

btrfs dispose d’un ensemble solide d’outils de récupération : scrub, device stats, utilitaires check/repair, et la possibilité de monter en lecture seule et de sauver des données. Mais la charge pour l’opérateur est plus élevée parce que les résultats peuvent dépendre davantage des fonctionnalités utilisées (profils, compression, quotas, instantanés) et du type de défaillance (corruption mono-device vs multi-device vs dommage metadata).

btrfs peut être extrêmement fiable dans les configurations bien rodées (mono-device, RAID1/10, discipline d’instantanés). Il devient moins « prévisible et ennuyeux » à mesure que vous poussez vers le RAID parité et les opérations de conversion complexes sous pression.

Performance : latence, débit et les guerres du cache

Performance ZFS : ARC, recordsize, sync et le mythe SLOG

ZFS est souvent accusé d’être « gourmand en RAM ». Plus précisément : ZFS utilisera volontiers la mémoire pour l’ARC (adaptive replacement cache) parce que le cache rend tout meilleur jusqu’à ce que ça ne le soit plus. Sur Linux, vous devez comprendre l’interaction entre ARC et le page cache du noyau, et vous devriez fixer des limites raisonnables sur les systèmes contraints en mémoire.

Pour les bases de données et la virtualisation, le tuning ZFS tourne souvent autour de quelques leviers pratiques :

recordsize : grand pour le séquentiel (sauvegardes), plus petit pour l’aléatoire (VMs, DBs).
compression : améliore souvent le débit effectif et la latence.
sync : ne « l’optimisez » pas à moins d’aimer expliquer des pertes de données.
SLOG : aide les écritures sync uniquement pour certains workloads ; ce n’est pas une potion universelle de vitesse.

Performance btrfs : CoW, compression et réalités de la fragmentation

btrfs peut être rapide, surtout avec la compression et NVMe. Mais le CoW a des conséquences pour les workloads qui réécrivent de gros fichiers en place (images de disque VM, certaines bases de données). btrfs propose des moyens d’atténuer (comme désactiver CoW sur des fichiers/répertoires spécifiques via chattr +C), mais c’est un compromis : vous renoncez à certains bénéfices CoW.

Le « balance » de btrfs est à la fois une capacité et un piège : il peut réorganiser les données vers un nouveau profil ou améliorer la distribution, mais il génère beaucoup d’IO et peut amplifier la douleur si vous le lancez sans précaution sur des systèmes occupés.

Tâches pratiques avec commandes (et ce que signifient les sorties)

La manière la plus rapide d’apprendre ces systèmes est de faire de vraies choses : créer des pools, snapshotter, scrub, simuler des pannes et pratiquer des chemins de récupération. Ci-dessous des tâches que vous pouvez exécuter sur des systèmes de test. Les commandes supposent Linux avec les outils ZFS installés (OpenZFS) et btrfs-progs pour btrfs.

Task 1 (ZFS): Create a mirrored pool and verify layout

cr0x@server:~$ sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/ata-diskA /dev/disk/by-id/ata-diskB
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-diskA                ONLINE       0     0     0
            ata-diskB                ONLINE       0     0     0

errors: No known data errors

Interprétation : mirror-0 est votre unité de redondance. Si vous perdez un disque, le pool reste en ligne. Si vous perdez le vdev mirror (les deux disques), le pool est perdu.

Task 2 (ZFS): Create datasets with sane properties for VMs and backups

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off tank/vm
cr0x@server:~$ sudo zfs set recordsize=16K tank/vm
cr0x@server:~$ sudo zfs create -o compression=zstd -o recordsize=1M tank/backup
cr0x@server:~$ sudo zfs get -o name,property,value compression,recordsize,atime tank/vm tank/backup
NAME         PROPERTY    VALUE
tank/vm      compression zstd
tank/vm      recordsize  16K
tank/vm      atime       off
tank/backup  compression zstd
tank/backup  recordsize  1M
tank/backup  atime       on

Interprétation : Vous faites correspondre recordsize aux patterns IO. VMs : de petits records réduisent l’amplification read-modify-write. Sauvegardes : de grands records boostent l’efficience séquentielle.

Task 3 (ZFS): Take a recursive snapshot and list it

cr0x@server:~$ sudo zfs snapshot -r tank@pre-upgrade
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation | head
NAME                    USED  REFER  CREATION
tank@pre-upgrade          0B   128K  Tue Dec 24 00:10 2025
tank/backup@pre-upgrade   0B    96K  Tue Dec 24 00:10 2025
tank/vm@pre-upgrade       0B   256K  Tue Dec 24 00:10 2025

Interprétation : La colonne USED de l’instantané augmente à mesure que le système live diverge. Ne l’ignorez pas ; c’est « l’espace que vous ne pouvez pas récupérer tant que vous n’avez pas supprimé les instantanés ».

Task 4 (ZFS): Send an incremental snapshot to another pool (replication)

cr0x@server:~$ sudo zfs snapshot tank/vm@replica-001
cr0x@server:~$ sudo zfs send -w tank/vm@replica-001 | sudo zfs receive -u backup-pool/vm
cr0x@server:~$ sudo zfs snapshot tank/vm@replica-002
cr0x@server:~$ sudo zfs send -w -i tank/vm@replica-001 tank/vm@replica-002 | sudo zfs receive -u backup-pool/vm

Interprétation : Le premier envoi est complet ; le second est incrémental. -w envoie un stream brut en préservant les propriétés et (lorsque supporté) les caractéristiques de chiffrement.

Task 5 (ZFS): Scrub and read the results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 00:14:02 2025
        2.31G scanned at 410M/s, 812M issued at 144M/s, 120G total
        0B repaired, 0.66% done, 0:13:50 to go
config:

        NAME         STATE     READ WRITE CKSUM
        tank         ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            diskA    ONLINE       0     0     0
            diskB    ONLINE       0     0     0

errors: No known data errors

Interprétation : Les scrubs vérifient les données contre les checksums. Si une réparation a lieu, ZFS vous dira exactement combien et quel device est suspect.

Task 6 (ZFS): Simulate a disk failure and replace it

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-diskB
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-diskA                ONLINE       0     0     0
            ata-diskB                OFFLINE      0     0     0

errors: No known data errors
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-diskB /dev/disk/by-id/ata-diskC
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 00:20:11 2025
        8.02G scanned, 1.94G issued, 120G total
        1.93G resilvered, 1.62% done, 0:18:10 to go

Interprétation : Le « resilver » est la reconstruction. Dans les mirrors c’est simple ; dans RAIDZ c’est plus complexe. Surveillez les resilvers lents — cela indique souvent une contention IO cachée ou un deuxième disque malade.

Task 7 (btrfs): Create a filesystem on a single device and mount it

cr0x@server:~$ sudo mkfs.btrfs -L data /dev/nvme0n1p3
btrfs-progs v6.6
Label:              data
UUID:               4b1a0c7e-1d2a-4a6f-9e3c-2e3a3a4e6b2f
Node size:          16384
Sector size:        4096
Filesystem size:    400.00GiB
Block group profiles:
  Data:             single
  Metadata:         DUP
  System:           DUP
cr0x@server:~$ sudo mount -o compress=zstd,space_cache=v2 /dev/nvme0n1p3 /mnt/data
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, single: total=1.00GiB, used=256.00MiB
Metadata, DUP: total=1.00GiB, used=112.00MiB
System, DUP: total=8.00MiB, used=16.00KiB

Interprétation : Metadata DUP sur un disque unique est un renfort pragmatique d’intégrité. Ce n’est pas une redondance contre la mort du disque, mais cela peut aider contre certaines corruptions localisées.

Task 8 (btrfs): Create subvolumes and snapshot them (OS-style layout)

cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@
Create subvolume '/mnt/data/@'
cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@home
Create subvolume '/mnt/data/@home'
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-pre-upgrade
Create a readonly snapshot of '/mnt/data/@' in '/mnt/data/@-snap-pre-upgrade'
cr0x@server:~$ sudo btrfs subvolume list /mnt/data | head
ID 256 gen 12 top level 5 path @
ID 257 gen 13 top level 5 path @home
ID 258 gen 14 top level 5 path @-snap-pre-upgrade

Interprétation : Les instantanés en lecture seule sont plus sûrs pour le rollback et le send/receive. Traitez les frontières de subvolume comme des frontières de rayon d’impact.

Task 9 (btrfs): Use send/receive for incremental replication

cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-001
cr0x@server:~$ sudo btrfs send /mnt/data/@-snap-001 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-001
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-002
cr0x@server:~$ sudo btrfs send -p /mnt/data/@-snap-001 /mnt/data/@-snap-002 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-002

Interprétation : L’option -p parent snapshot permet les envois incrémentaux. Si vous supprimez le snapshot parent prématurément, votre chaîne se brise et vous aurez besoin d’un nouveau envoi complet.

Task 10 (btrfs): Scrub and read device stats

cr0x@server:~$ sudo btrfs scrub start -Bd /mnt/data
Starting scrub on devid 1
Scrub device /dev/nvme0n1p3 (id 1) done
Scrub started:    Tue Dec 24 00:35:12 2025
Status:           finished
Duration:         0:01:07
Total to scrub:   18.00GiB
Rate:             274.62MiB/s
Error summary:    read=0 write=0 csum=0 verify=0 no_csum=0 csum_discards=0 super=0 malloc=0 uncorrectable=0 corrected=0
cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/nvme0n1p3].write_io_errs   0
[/dev/nvme0n1p3].read_io_errs    0
[/dev/nvme0n1p3].flush_io_errs   0
[/dev/nvme0n1p3].corruption_errs 0
[/dev/nvme0n1p3].generation_errs 0

Interprétation : Le scrub vérifie les checksums et tente de réparer lorsque la redondance existe. Les device stats vous aident à identifier un périphérique flaky avant qu’il ne tombe complètement.

Task 11 (btrfs): Convert to RAID1 with a second device (mirror-like behavior)

cr0x@server:~$ sudo btrfs device add /dev/nvme1n1p3 /mnt/data
cr0x@server:~$ sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/data
Done, had to relocate 12 out of 12 chunks
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, RAID1: total=16.00GiB, used=12.00GiB
Metadata, RAID1: total=2.00GiB, used=512.00MiB
System, RAID1: total=32.00MiB, used=64.00KiB

Interprétation : btrfs utilise des profils et des chunks. Après conversion, vos données et métadonnées sont dupliquées entre les devices. L’opération balance est le prix de cette flexibilité — planifiez capacité et fenêtres de maintenance.

Task 12 (btrfs): Disable CoW for a VM directory (with trade-offs)

cr0x@server:~$ sudo mkdir -p /mnt/data/vmimages
cr0x@server:~$ sudo chattr +C /mnt/data/vmimages
cr0x@server:~$ lsattr -d /mnt/data/vmimages
---------------C------ /mnt/data/vmimages

Interprétation : Les nouveaux fichiers créés dans ce répertoire seront NOCOW, réduisant souvent la fragmentation et améliorant les patterns d’écritures VM. Compromis : vous réduisez les garanties basées CoW pour ces fichiers (et le comportement de checksumming peut être affecté selon le noyau/fonctionnalités).

Task 13 (ZFS): Check ARC behavior and memory pressure (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|hit|miss)'
size                            4    17179869184
c_max                           4    25769803776
hit                             4    1402382231
miss                            4    32988312

Interprétation : La taille ARC et hit/miss vous donnent un signal rapide : êtes-vous en pénurie de cache ou ça va ? Si la machine swappe, il faut s’occuper des limites ARC, mais ne faites pas de réaction excessive — identifiez les vrais consommateurs mémoire.

Task 14 (ZFS): Identify what’s eating space (snapshots vs live data)

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots,usedbydataset -r tank
NAME        USED  AVAIL  REFER  USEDBYSNAPSHOTS  USEDBYDATASET
tank        420G   1.2T   128K              0B          128K
tank/vm     300G   1.2T   250G            80G          250G
tank/backup 120G   1.2T   110G            10G          110G

Interprétation : Si USEDBYSNAPSHOTS est important, la suppression d’anciens instantanés est le levier. Si USEDBYDATASET est important, vos données live ont augmenté et vous avez besoin de capacité ou d’une politique de pruning.

Playbook de diagnostic rapide (trouvez le goulet avant qu’il ne vous trouve)

Voici le flux « que vérifier en premier, en second, en troisième » que j’utilise quand le stockage « semble lent » et que le dashboard de monitoring accuse tout le monde.

1) Établir : s’agit-il d’un disque, CPU, pression mémoire, ou d’un locataire bruyant ?

cr0x@server:~$ uptime
 00:41:03 up 12 days,  4:22,  2 users,  load average: 18.12, 17.90, 16.55
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            128G         92G         3.1G        2.2G         33G         29G
Swap:             0B          0B          0B
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  3      0 3211232 120000 28000000    0    0  1200  3400 9000 22000 25 15 30 30  0

Interprétation : Un wa élevé suggère de l’attente IO. Une charge élevée avec un IO wait faible suggère une contention CPU. La pression mémoire apparaît comme une diminution de la mémoire disponible et un éventuel swap (si activé).

2) Vérifier la santé du filesystem/pool d’abord ; la performance ensuite

Parce que les pools dégradés ressemblent souvent à une « lenteur aléatoire ».

cr0x@server:~$ sudo zpool status
cr0x@server:~$ sudo btrfs device stats /mountpoint
cr0x@server:~$ dmesg | tail -n 50

Interprétation : Toute erreur read/write/cksum, reset ou timeout change votre plan : vous ne tunez pas ; vous faites du triage matériel.

3) Identifier les plus gros consommateurs IO (par processus et par device)

cr0x@server:~$ iostat -xz 1 5
cr0x@server:~$ pidstat -d 1 5

Interprétation : Cherchez les devices à forte utilisation avec await qui augmente, et les processus générant des écritures disproportionnées. C’est là que vous trouverez « la tâche de backup » qui fait par accident de l’IO aléatoire sur votre pool VM.

4) Pour ZFS : vérifiez ARC et le comportement des écritures sync

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|mru_size|mfus|hits|miss)'
cr0x@server:~$ sudo zfs get -o name,property,value sync,logbias,primarycache,recordsize -r tank/vm

Interprétation : Si vous voyez des écritures sync lourdes et aucune voie de latence adéquate (ou une voie saturée), le système « semblera bloqué » sous certains workloads même si le débit semble correct.

5) Pour btrfs : vérifier si balance/scrub est en cours et les patterns de fragmentation

cr0x@server:~$ sudo btrfs balance status /mountpoint
cr0x@server:~$ sudo btrfs scrub status /mountpoint
cr0x@server:~$ sudo btrfs filesystem usage /mountpoint | head -n 30

Interprétation : Un balance lancé pendant les heures de pointe peut expliquer une « taxe IO soudaine ». Surveillez aussi l’utilisation des métadonnées ; une pincée metadata peut produire des blocages bizarres.

Erreurs fréquentes (symptômes & corrections)

Mistake 1: Treating snapshots like backups

Symptôme : « Nous avons des instantanés, pourquoi ne pouvons-nous pas restaurer après la perte du pool ? » suivi d’un long silence.

Correction : Les instantanés protègent contre les erreurs logiques (rm -rf, mauvaises mises à niveau) sur le même stockage. Les sauvegardes nécessitent un média indépendant ou un système distant. Utilisez zfs send/receive ou btrfs send/receive vers un autre hôte/pool, ou un système de sauvegarde séparé. Testez les restaurations, pas seulement les envois.

Mistake 2: ZFS pool designed as one huge RAIDZ vdev for VM workloads

Symptôme : Excellents benchmarks séquentiels, latence VM catastrophique, plaintes « IOPS maudit ».

Correction : Pour l’IO aléatoire, utilisez plusieurs vdevs mirror ou plusieurs vdevs RAIDZ pour augmenter le parallélisme. Réglez aussi un recordsize approprié (par ex. 16K) pour les datasets VM et activez la compression.

Mistake 3: btrfs parity RAID used as if it’s as boring as mdadm RAID6

Symptôme : Comportement inattendu lors d’une défaillance device/rebuild, états d’erreur confus, récupération qui ressemble à de l’archéologie.

Correction : Préférez btrfs RAID1/10 pour la fiabilité multi-device en production à moins d’avoir des procédures testées pour les modes parité. Si la parité est nécessaire, envisagez mdadm en dessous avec un simple profil btrfs dessus — ou choisissez ZFS RAIDZ.

Mistake 4: Running btrfs balance casually on busy production

Symptôme : Pics de latence IO, timeouts applicatifs, « rien n’a changé » sauf « quelqu’un a lancé la maintenance ».

Correction : Utilisez un balance filtré (-dusage= / -musage=) et planifiez-le. Surveillez. Traitez balance comme un job de migration de stockage, pas comme un script de nettoyage.

Mistake 5: “Optimizing” ZFS sync settings to make benchmarks pretty

Symptôme : Le workload est ultra-rapide — jusqu’à un événement d’alimentation ou un crash, puis l’intégrité des données devient une réunion.

Correction : Conservez sync=standard sauf si vous comprenez parfaitement les attentes de durabilité de l’application. Si vous avez besoin d’un sync plus rapide, envisagez des SLOG avec protection contre les pertes de puissance, et validez les améliorations de latence avec des workloads réels.

Mistake 6: Ignoring scrubs because “the pool is online”

Symptôme : Le premier scrub en un an trouve des erreurs ; maintenant vous déboguez une histoire de corruption au lieu de la prévenir.

Correction : Planifiez des scrubs : mensuel est courant pour les gros pools ; plus souvent pour des disques grand public ou environnements durs. Analysez les résultats. Remplacez le matériel flaky tôt.

Mistake 7: Snapshot sprawl without retention policy

Symptôme : « L’espace a disparu », les suppressions ne libèrent pas d’espace, les backups échouent par manque d’espace, performances dégradées.

Correction : Appliquez une rétention d’instantanés (horaire/quotidien/hebdo) et prune automatique. Suivez l’espace utilisé par les instantanés (ZFS : usedbysnapshots ; btrfs : usage par subvolume et qgroups si utilisés).

Listes de contrôle / plan pas à pas

Checklist A: Choosing between ZFS and btrfs (production decision)

Définissez le modèle de défaillance : disque unique ? double disque ? le contrôleur ment ? bit rot ? erreur opérateur ? rayon d’action ransomware ?
Définissez le workload : VMs, bases de données, stockage d’objets, sauvegardes, répertoires développeurs, root OS.
Décidez l’approche de redondance : mirror/RAIDZ ZFS vs btrfs RAID1/10 (ou mdadm + btrfs).
Décidez la stratégie d’instantanés : quels datasets/subvolumes ont des instantanés ; rétention ; chaîne de réplication ; protection suppression.
Planifiez l’observabilité : horaires de scrub, alertes sur erreurs device, prévision de capacité, alarmes de croissance d’instantanés.
Répétez la récupération : remplacer un disque ; rollback d’un instantané ; restaurer un dataset répliqué sur un hôte propre.

Checklist B: ZFS deployment plan (boring, correct, repeatable)

Choisir la géométrie vdev : mirrors pour IOPS/latence ; RAIDZ2 pour capacité + résilience ; évitez un vdev large héroïque pour des workloads mixtes.
Définir ashift correctement (généralement 12) à la création du pool ; vous ne voulez pas « découvrir » la réalité de la taille de secteur plus tard.
Définir des datasets par workload ; régler recordsize, compression, atime.
Mettre en place la politique d’instantanés et la réplication ; vérifier les envois incrémentaux.
Planifier des scrubs et alerter sur les changements de zpool status et les erreurs checksum.
Documenter la procédure de remplacement disque et garder de la capacité de secours pour les resilvers.

Checklist C: btrfs deployment plan (safe lanes first)

Décidez si c’est mono-disque, RAID1 ou RAID10. Traitez le RAID parité comme un projet spécial, pas comme un défaut.
Utilisez les subvolumes comme frontières ; snapshottez ceux que vous pouvez raisonnablement restaurer.
Activez la compression (zstd est un choix courant) et les options de montage de façon cohérente.
Planifiez les opérations de balance : filtrées, programmées, surveillées.
Scrubez périodiquement ; surveillez device stats ; enquêtez tôt sur les erreurs IO.
Testez les restaurations send/receive ; conservez les snapshots parents jusqu’à ce que les enfants soient répliqués en sécurité.

Trois micro-histoires du monde d’entreprise (plausibles, techniquement exactes et douloureuses)

Mini-story 1: The incident caused by a wrong assumption

Ils avaient une configuration propre : btrfs sur une paire de SSD, instantanés chaque heure, et un joli dashboard indiquant « snapshot count : healthy ». Un ingénieur junior posa la question évidente — « On sauvegarde hors-hôte ? » — et on lui répondit d’un geste par « les instantanés sont à peu près des sauvegardes ; on peut tout rollbacker ». Cette phrase est l’équivalent stockage de laisser les clés dans la voiture parce qu’on a une assurance.

L’incident n’était pas dramatique au début. Un bug de firmware sur un SSD commença à générer des erreurs de lecture intermittentes, puis escalada jusqu’à ce que le disque disparaisse du bus. Le système continua de tourner ; la redondance couvrit la défaillance immédiate. L’équipe remplaça le disque. Puis une semaine plus tard, le second SSD montra un comportement similaire — même lot, même firmware, timing différent. Soudainement la machine tomba et le système de fichiers était indisponible.

La réunion inconfortable ne portait pas sur la panne. Les disques tombent ; c’est pourquoi on fait du mirror. La réunion portait sur la découverte que leur « plan de sauvegarde » vivait sur le même châssis. Les instantanés étaient impeccables et inutiles. Le chemin de restauration se réduisait à « espérer que le fournisseur récupère la NAND », ce qui n’est pas un plan mais une prière avec bon de commande.

Ce qui changea après fut délicieusement ennuyeux : réplication hors-hôte via send/receive vers un système séparé, plus des tests de restauration mensuels. L’équipe cessa de discuter si les instantanés sont des sauvegardes, parce qu’ils avaient une invitation calendrier prouvant que la restauration fonctionnait.

Mini-story 2: The optimization that backfired

Un cluster de virtualisation fut migré vers ZFS sur Linux parce que l’équipe voulait des instantanés propres et de la réplication. Les tests initiaux montrèrent des performances décentes. Puis quelqu’un remarqua que les workloads sync-heavy étaient « un peu lents », et un passionné performance proposa une « amélioration » : désactiver les sémantiques sync sur le dataset VM. Les graphs devinrent splendides.

Pendant un temps tout le monde fut content. La latence baissa, le débit monta, et l’équipe stockage avait l’air de magiciens. Le seul dissident était la personne qui demandait sans cesse « Que pense la base de données que fsync signifie ? » Personne n’aime cette personne jusqu’à ce qu’elle ait raison.

Puis survint un événement d’alimentation non planifié — rien d’exotique, juste un incident d’installations et un UPS qui fit son meilleur rôle d’objet décoratif. Plusieurs VMs démarrèrent, mais un sous-ensemble eut un état applicatif corrompu. Une base se remit. Une autre non. La cause racine n’était pas mystérieuse : le dataset était configuré de sorte que des écritures reconnues pouvaient s’évaporer au crash. ZFS fit exactement ce qu’on lui avait dit. Ce n’était pas le système de fichiers qui les mordait ; c’était la configuration.

Le postmortem fut classique : restauration depuis des répliques, puis retour à des réglages sync sûrs, puis ajout d’un chemin sync basse-latence là où c’était nécessaire. Ils apprirent aussi une leçon utile et douloureuse : les benchmarks ne sont pas des tests de durabilité. Si vous changez les sémantiques, vous changez le contrat — pas seulement la vitesse.

Mini-story 3: The boring but correct practice that saved the day

Une équipe utilisait ZFS pour un service de fichiers que tout le monde avait oublié jusqu’à sa panne — ce qui est le compliment le plus élevé qu’on puisse faire au stockage. Ils avaient deux habitudes agaçantes old-school : des scrubs mensuels et des revues routinières des alertes santé du pool. Pas « quand on a le temps », mais réellement programmés, avec un runbook on-call.

Pendant un scrub, ZFS signala un petit nombre d’erreurs checksum sur un disque unique. Les performances semblaient normales ; les utilisateurs ne se plaignaient pas. La tentation fut d’ignorer. Mais les checksums ne mentent pas pour le plaisir, et ZFS n’est pas enclin à la mélodrame. Ils vérifièrent les stats SMART, trouvèrent un nombre croissant de secteurs réalloués, et remplacèrent le disque pendant les heures ouvrables.

Des semaines plus tard, un autre disque du même châssis échoua soudainement. S’ils n’avaient pas remplacé proactivement le premier disque, la seconde panne se serait produite pendant une fenêtre dégradée. Au lieu de cela, le pool haussa les épaules et continua. Le ticket d’incident fut une non-événement : « Disque défaillant ; remplacé ; resilver ; pas de perte de données. »

Ceci est la vérité secrète du stockage fiable : l’histoire de récupération héroïque est rarement un signe d’excellence. La meilleure histoire de stockage est celle que personne ne raconte parce que rien d’intéressant ne s’est passé.

FAQ

1) Is ZFS “safer” than btrfs?

Dans beaucoup de configurations de production, ZFS offre une histoire d’intégrité et de récupération plus prévisible, surtout avec des setups multi-disques RAIDZ/mirror. btrfs peut aussi être très sûr — particulièrement en mono-disque ou RAID1/10 avec des opérations disciplinées — mais son profil de risque dépend davantage des fonctionnalités que vous utilisez.

2) Can I use btrfs like ZFS with snapshots and replication?

Oui : les snapshots de subvolume btrfs plus btrfs send/receive peuvent fournir un workflow de réplication efficace. La contrepartie est la discipline opérationnelle : vous devez gérer les chaînes d’instantanés parents et la rétention soigneusement, et tester les restaurations régulièrement.

3) What’s the practical difference between ZFS RAIDZ and btrfs RAID profiles?

Le RAIDZ ZFS fait partie d’un design de pool unifié où la redondance est définie par les vdevs et est centrale à l’identité du pool. btrfs utilise des profils par chunk pour les données et métadonnées que vous pouvez convertir via balance. ZFS est plus rigide mais plus déterministe ; btrfs est plus flexible mais exige plus de choix opérationnels prudents.

4) Are scrubs mandatory?

Si vous tenez à l’intégrité, oui. Les scrubs sont la façon de trouver des erreurs latentes tant que la redondance existe encore. Sans scrubs, vous découvrez la corruption seulement lors de la lecture des données affectées — souvent pendant des restaurations ou audits, ce qui est le pire moment pour apprendre.

5) When should I use compression?

Souvent par défaut sur les deux systèmes de fichiers, en particulier avec zstd. La compression améliore fréquemment les performances car moins d’octets frappent le disque. Les exceptions sont les médias déjà compressés et les systèmes contraints en CPU ; même dans ces cas, testez plutôt que supposer.

6) Do I need ECC RAM for ZFS?

ECC est fortement recommandé pour tout système de stockage sérieux, quel que soit le système de fichiers. ZFS bénéficie d’ECC car il est agressif sur le caching et l’intégrité. Mais « pas d’ECC » ne signifie pas automatiquement « n’utilisez pas ZFS » ; cela signifie comprendre votre risque et surveiller plus étroitement.

7) Why do my deletions not free space when I have snapshots?

Parce que les instantanés retiennent des références aux anciens blocs. Supprimer des fichiers les retire de la vue live, mais les blocs restent référencés par les instantanés. Sur ZFS, inspectez usedbysnapshots. Sur btrfs, inspectez l’usage des snapshots/subvolumes et envisagez les quotas (qgroups) si vous avez besoin d’une application stricte.

8) Should I put ZFS on hardware RAID?

Généralement non. ZFS veut un accès direct aux disques pour gérer correctement la redondance et le reporting d’erreurs. Si vous devez utiliser un contrôleur RAID, configurez-le en mode HBA/JBOD si possible. Le « double RAID » aboutit souvent à une pire visibilité de panne et à des récupérations plus confuses.

9) What’s the simplest safe btrfs multi-disk setup?

btrfs RAID1 pour données et métadonnées sur deux devices est une baseline courante et relativement ennuyeuse. RAID10 est aussi solide quand vous avez quatre appareils ou plus et voulez de meilleures performances et caractéristiques de résilience.

10) What’s the simplest safe ZFS setup?

Des mirrors. Un pool de vdevs mirror évolue de façon prévisible pour l’IO aléatoire et garde la récupération simple. RAIDZ2 est aussi courant quand l’efficacité de capacité compte, mais concevez-le soigneusement pour le workload et le risque de rebuild.

Conclusion

Si vous voulez le système de fichiers qui se comporte le plus systématiquement comme un SRE discipliné — traquant les checksums, pointant le disque coupable, faisant de la réplication une habitude de première classe — ZFS est le pari le plus sûr, en particulier pour les pools multi-disques et la rétention longue. Ce n’est pas sans effort, mais c’est cohérent, et la cohérence est la moitié de la fiabilité.

Si vous voulez l’intégration noyau-native, des workflows d’instantanés élégants par subvolume et un système de fichiers excellent pour le rollback au niveau OS et raisonnablement sûr en stockage miroir, btrfs est un choix solide — à condition de rester sur les voies bien éclairées (mono/RAID1/RAID10) et de traiter les opérations de maintenance comme de vrais événements de production.

Dans tous les cas, le système de fichiers ne vous sauve pas de l’absence de pratique. Lancez des scrubs. Testez les restaurations. Gardez les politiques d’instantanés ennuyeuses. Et souvenez-vous : le meilleur système de stockage est celui qui transforme les désastres en tickets de maintenance de routine.