4. ZFS — le système de fichiers qui se souvient de tout

La grande majorité des administrateurs Linux s'appuie historiquement sur ext4, xfs ou LVM pour gérer leurs disques. Ces solutions fonctionnent bien, mais elles partagent une faiblesse commune : elles font confiance aux données qu'elles lisent.

Si un disque retourne silencieusement des données corrompues — le "bit rot" — le système de fichiers ne s'en aperçoit pas. ZFS a été conçu précisément pour résoudre ce problème.

ZFS combine en un seul outil ce que LVM, mdadm et ext4 font séparément : la gestion des volumes, le RAID logiciel, les snapshots et le système de fichiers lui-même. Pas besoin de contrôleur RAID matériel coûteux : ZFS s'en charge en logiciel. Des checksums sur chaque bloc de données détectent toute corruption silencieuse ; en mode miroir ou RAIDZ, ZFS la corrige.

Pas de ZFS ni de Ceph sur des SSD grand public — c'est l'avertissement que répètent les contributeurs de Proxmox. ZFS et Ceph demandent au disque de garantir chaque écriture synchrone (sync). Un SSD grand public, sans protection contre la coupure de courant, ne peut le faire qu'en vidant son cache à chaque fois.

Les performances s'effondrent, et l'usure s'accélère au point de consommer la durée de vie du disque en quelques mois. Les SSD d'entreprise à condensateurs (PLP, power loss protection) acquittent ces écritures depuis leur cache protégé, sans ce coût.

Sans ce budget, une installation simple — ext4 et de bonnes sauvegardes — vaut mieux qu'un ZFS sur du matériel inadapté. En atelier, avec des disques virtuels, la question ne se pose pas ; elle se pose avant tout déploiement en production.

4.1 Vocabulaire ZFS et niveaux RAID

ZFS introduit son propre vocabulaire qu'il faut maîtriser avant de taper la première commande. Un vdev (virtual device) regroupe un ou plusieurs disques physiques avec une stratégie de redondance donnée.

Un zpool est constitué d'un ou plusieurs vdevs — c'est l'unité de stockage visible de l'extérieur. Si vous perdez un vdev entier, vous perdez tout le zpool : la résilience ne se fait jamais d'un vdev à l'autre, uniquement à l'intérieur d'un même vdev.

Un zpool peut ensuite héberger des datasets (systèmes de fichiers virtuels) et des zvols (volumes logiques en mode bloc). La taille d'un dataset peut être limitée par quota.

Niveau	Équivalent RAID classique	Tolérance de panne	Disques minimum
stripe	RAID 0	Aucune	1
mirror	RAID 1	1 disque par vdev	2
RAIDZ1	RAID 5	1 disque	3
RAIDZ2	RAID 6	2 disques	4
RAIDZ3	—	3 disques	5

En RAIDZ, la capacité utile est celle de N − 1 disques (RAIDZ1), N − 2 (RAIDZ2) ou N − 3 (RAIDZ3). Ainsi, 3 disques de 10 Go en RAIDZ1 donnent environ 20 Go utiles.

RAIDZ face au RAID 5 classique. Le RAID 5 connaît le write hole : une coupure en pleine écriture peut laisser données et parité incohérentes. RAIDZ écrit de façon atomique, grâce au copy-on-write (§4.2), et sa largeur de bande s'adapte à chaque écriture.

En cas de panne, il ne reconstruit que les blocs réellement utilisés, là où le RAID 5 reconstruit tout le disque. Et chaque bloc porte une somme de contrôle.

Un pool accepte aussi des vdev spécialisés, en plus des vdev de données :

vdev	Rôle
`spare`	Disque de rechange, prêt à remplacer un disque défaillant du pool
`cache`	L2ARC : un SSD qui prolonge le cache de lecture tenu en mémoire
`log`	SLOG : un SSD rapide qui reçoit le journal des écritures synchrones
`special`	Les métadonnées et les petits blocs, sur un support rapide

Dans le contexte de l'atelier, les VMs imbriquées disposent de disques supplémentaires (/dev/sdc, /dev/sdd). Un pool miroir sur ces deux disques est l'exercice de référence pour s'entraîner.

4.2 Le Copy-on-Write : pourquoi ZFS ne corrompt jamais un fichier en cours d'écriture

Le Copy-on-Write (CoW) est le mécanisme qui rend les snapshots ZFS quasi-instantanés et garantit l'intégrité des données à tout moment. Avec le CoW, toute modification d'un fichier écrit les données modifiées à côté du fichier original, jamais par-dessus.

Imaginons un fichier constitué de blocs A, B, C et D. La plupart des systèmes de fichiers classiques écriraient les nouvelles données par-dessus le bloc C, sur place.

Avec le Copy-on-Write, ZFS copie les nouvelles données dans une nouvelle zone. Une fois la copie terminée, il met à jour les métadonnées du fichier pour pointer vers cette nouvelle zone. Le bloc C original est libéré ultérieurement par un processus en tâche de fond.

Il ne peut donc jamais exister d'état où les données sont à moitié écrites dans le fichier. Celui-ci est toujours soit dans son ancienne version complète, soit dans la nouvelle version complète. Une coupure de courant en plein milieu d'une écriture ne corrompt jamais un fichier ZFS — au pire, l'écriture n'a simplement pas eu lieu.

Un arbre de sommes de contrôle. ZFS range ses blocs dans un arbre de Merkle : chaque bloc contient la somme de contrôle des blocs qu'il désigne. Au sommet, l'uberblock décrit l'état complet du pool.

Une écriture se termine en remplaçant cet uberblock d'un coup. C'est pourquoi un pool ZFS n'a jamais besoin de fsck après une coupure : il repart du dernier uberblock valide.

Conséquence directe pour les snapshots : un snapshot ZFS ne fait que figer un pointeur vers l'état des métadonnées à cet instant. Tant que rien n'est modifié, le snapshot ne consomme aucun espace disque supplémentaire.

Revenons à la définition de base : un système de fichiers range des données sur des disques et tient le registre de ce qui est où. ZFS fait en plus le travail du RAID et des volumes. Son vocabulaire, du disque au bloc :

Terme	Ce que c'est	Dans le laboratoire
Disque	Un disque physique	`sdc` et `sdd`
vdev	Un groupe de disques avec sa redondance (miroir, RAIDZ)	`mirror-0`
zpool	L'espace de stockage, fait d'un ou plusieurs vdev ; si un vdev entier tombe, tout le pool est perdu	`datapool`
Dataset	Un système de fichiers dans le pool, avec ses propriétés (quota, compression)	`datapool/vms`
zvol	Un volume en mode bloc, pour le disque d'une VM	Les disques des VM sur le stockage ZFS (§4.5)
Copy-on-write	Une donnée modifiée s'écrit ailleurs ; le pointeur bascule une fois l'écriture finie	Une coupure ne laisse jamais un fichier à moitié écrit
Snapshot	Un état figé, instantané, qui ne coûte que les blocs modifiés ensuite	`datapool/vms@avant-migration` (§4.4)
Checksum	Une somme de contrôle par bloc, vérifiée à chaque lecture et par le scrub	`zpool status` : colonne `CKSUM`

Avec le copy-on-write, les pointeurs désignent toujours soit l'ancien bloc, soit le nouveau, jamais un bloc à moitié écrit. C'est pourquoi les snapshots sont instantanés, et une coupure de courant sans danger pour la cohérence.

Où voir ZFS sur votre nœud :

Notion	Où la voir
Le pool, ses vdev et ses disques	Nœud → Disks → ZFS ; `zpool status` (état `ONLINE`, `mirror-0`, `sdc`, `sdd`)
Les datasets et l'espace	`zfs list`
Les snapshots	`zfs list -t snapshot`
Le stockage Proxmox posé dessus	Datacenter → Storage : type `ZFS` ; `/etc/pve/storage.cfg` : `zfspool`