Depuis dix ans, le débat filesystem avancé sur Linux se joue à deux : ZFS d'un côté, porté hors arbre par OpenZFS, Btrfs de l'autre, intégré au noyau et poussé par SUSE et Facebook. Entre les deux, bcachefs avance depuis 2015 sans faire de bruit, malgré des ambitions techniques qui n'ont rien d'anecdotique : checksums de bout en bout, copy-on-write, snapshots, compression transparente, et un mécanisme de tiering natif entre SSD et disques mécaniques hérité directement de bcache, le projet précédent de son auteur Kent Overstreet.
On ne le déploie pas en prod chez nous aujourd'hui, et la raison n'est pas technique. Le projet a traversé en 2025 une crise politique avec la direction du noyau Linux qui l'a fait sortir de l'arbre principal, un épisode qu'il faut comprendre avant d'envisager quoi que ce soit dessus.
Ce qu'il pique à ZFS et à Btrfs
bcachefs n'invente pas un nouveau paradigme de stockage. Il reprend ce qui a fait ses preuves ailleurs et tente de corriger les angles morts des deux modèles existants.
De ZFS, il reprend le principe du checksum sur chaque bloc de données et de métadonnées, vérifié à chaque lecture, avec autoréparation possible dès qu'une copie saine existe ailleurs sur le pool. Comme sur ZFS sous Linux, l'intégrité n'est pas une option qu'on active après coup : elle fait partie du format sur disque dès la création du filesystem. Le copy-on-write suit la même logique que ZFS : on n'écrase jamais un bloc en place, on écrit ailleurs et on met à jour les pointeurs, ce qui élimine par construction la fenêtre de corruption au moment d'un crash pendant une écriture.
De Btrfs, bcachefs reprend l'organisation en B-tree pour indexer les extents et une gestion des snapshots par référence à l'écriture, moins lourde à l'usage que les datasets ZFS pour qui veut cloner rapidement un volume sans dupliquer les données. Comme Btrfs, il gère nativement le multi-device sans passer par une couche RAID logicielle séparée : on donne plusieurs disques au format, et le filesystem répartit lui-même la réplication et la répartition de charge selon les groupes de disques déclarés.
Le point commun aux deux modèles qu'il ne reproduit pas à l'identique, c'est la maturité. ZFS a quinze ans de production intensive derrière lui, Btrfs a eu ses années difficiles avant de devenir fiable sur des charges définies (SUSE l'utilise en racine système depuis longtemps, avec des garde-fous précis sur les modes RAID 5 et 6 à éviter). Le comparatif Btrfs contre ZFS en 2026 détaille ces arbitrages de maturité, qui restent le vrai critère de choix en production, bien avant les fonctionnalités listées sur le papier.
Le vrai argument différenciant : le tiering natif
Ce qui distingue bcachefs, ce n'est pas le triptyque checksum/COW/snapshot, disponible ailleurs. C'est l'héritage direct de bcache : la capacité à traiter un pool de disques hétérogène, SSD rapide et HDD volumineux, comme un seul espace de stockage cohérent, avec migration automatique des données entre les deux niveaux selon leur température d'accès.
Sous bcache, il fallait empiler une couche de cache logicielle sous un filesystem classique (ext4, XFS), avec toute la complexité de gestion d'un device bcache séparé du volume final. bcachefs intègre ce mécanisme nativement dans le format sur disque, via quatre cibles configurables : foreground_target pour l'écriture initiale, background_target pour la destination finale à froid, promote_target pour la mise en cache à la lecture, et metadata_target pour isoler les métadonnées sur le support le plus rapide.
En pratique, un pool SSD plus HDD en écriture différée se déclare directement au format :
bcachefs format \
--label=ssd.ssd1 /dev/nvme0n1 \
--label=hdd.hdd1 /dev/sda \
--foreground_target=ssd \
--promote_target=ssd \
--background_target=hdd
Les écritures atterrissent d'abord sur le NVMe, encaissant la latence d'écriture au niveau du SSD. Un thread de rebalance interne migre ensuite les données vers le HDD en arrière-plan, dès que la charge le permet. Une lecture sur une donnée déjà repoussée sur le HDD déclenche sa promotion automatique vers le SSD si elle redevient chaude. Combiné à un tuning NVMe correctement dimensionné côté SSD, ce mécanisme rend un pool hybride viable pour des charges où une partie des données est active et le reste dort, sans script de tiering maison ni couche LVM cache à opérer séparément. C'est un vrai gain d'exploitation face à un montage ZFS avec un special vdev ou un L2ARC, qui accélèrent la lecture des métadonnées et de certains blocs mais ne migrent pas les données elles-mêmes entre niveaux de la même façon. Le tuning ZFS poussé à l'extrême montre d'ailleurs à quel point il faut multiplier les réglages annexes pour approcher ce comportement sur une pile ZFS classique.
L'état réel dans le noyau : la partie qu'on ne peut pas enjoliver
C'est le point qui change tout pour une décision de production, et il a bougé plusieurs fois en dix-huit mois.
En août 2025, le statut de bcachefs dans le MAINTAINERS du noyau est passé de « Supported » à « Externally maintained », signe d'une tension déjà installée entre Linus Torvalds et Kent Overstreet sur le rythme et la nature des patches soumis en cours de cycle. La bascule s'est confirmée en septembre 2025 : un patch nommé journal_rewind, jugé être une fonctionnalité et non un correctif, a été soumis tard dans une fenêtre de merge, ce que les règles de développement du noyau interdisent explicitement passé ce stade. Torvalds a retiré l'intégralité du code bcachefs de l'arbre principal à partir de la version 6.18, avec ce commentaire sans ambiguïté relayé par la presse technique : le code in-tree devenait obsolète face au nouveau mode de diffusion, autant le supprimer pour éviter toute confusion de version (LWN.net, Phoronix).
Depuis, bcachefs se distribue en module DKMS : le code source est recompilé automatiquement contre le noyau en cours à chaque mise à jour, au lieu d'être livré précompilé dans le noyau lui-même. NixOS et Arch Linux l'ont intégré à leurs dépôts officiels sous cette forme, Debian et Ubuntu passent par des paquets externes (bcachefs-kernel-dkms). Côté ops, ce changement de statut n'est pas cosmétique : un module DKMS qui ne recompile pas proprement après une montée de version de noyau, c'est un serveur qui ne redémarre plus sur son filesystem racine tant qu'on n'a pas réparé la chaîne de build. C'est une classe de risque opérationnel que ZFS connaît déjà bien via zfs-dkms, avec quinze ans de recul en plus pour l'anticiper.
En juin 2026, Kent Overstreet a publié la version 1.38.6, présentée par le projet lui-même comme une « performance release » marquant la sortie du statut expérimental (The Register). C'est une déclaration du mainteneur principal, pas un constat indépendant confirmé par un historique de production à grande échelle : à retenir comme un jalon annoncé, pas comme une preuve de maturité équivalente à ZFS ou Btrfs. Aucune donnée publique solide ne permet aujourd'hui de comparer son taux d'incidents en production à celui des deux filesystems établis.
Le verdict côté ops
On ne le met pas en prod aujourd'hui, et ce n'est pas un jugement définitif sur la technique.
Le triptyque checksum, COW, snapshot est solide sur le papier et cohérent avec ce que ZFS et Btrfs ont validé depuis des années. Le tiering natif SSD vers HDD est réellement le meilleur argument du projet : c'est la seule fonctionnalité qu'aucun des deux concurrents n'offre nativement avec cette simplicité de configuration. Mais la dépendance à DKMS ajoute un maillon de fragilité à chaque montée de noyau, sur un projet qui vient tout juste de sortir d'une crise de gouvernance publique avec le mainteneur du noyau lui-même. Ce n'est pas le genre de terrain sur lequel on pose des données de production sans un filet de restauration testé et une politique de gel de version stricte.
La règle qu'on applique : bcachefs reste un candidat de laboratoire, à suivre release après release, pas un candidat de production tant que son cycle DKMS n'a pas encaissé plusieurs cycles de montée de noyau sans incident documenté. Pour un pool hybride SSD/HDD en production aujourd'hui, ZFS avec special vdev et L2ARC correctement dimensionnés, ou une séparation applicative claire entre tiers de stockage, restent le choix qui ne demande pas de parier sur la stabilité d'une chaîne de compilation externe à chaque redémarrage.
Choisir la bonne pile de stockage pour un pool hybride, arbitrer entre maturité et fonctionnalités, et exploiter le résultat dans la durée avec une politique de sauvegarde et de restauration testée : c'est le travail qu'on fait au quotidien sur les infrastructures qu'on opère dans le DC Fullsave de Toulouse et le site TDF de Bordeaux. Si votre stratégie de stockage repose encore sur des choix pris par défaut plutôt que sur un arbitrage documenté, on peut auditer votre pile actuelle et la mettre au niveau.
Sources
- Bcachefs removed from the mainline kernel (LWN.net) : récit détaillé du retrait du code bcachefs de l'arbre principal à partir du noyau 6.18 et du passage au DKMS.
- Linus Torvalds Removes The Bcachefs Code From The Linux Kernel (Phoronix) : couverture de la décision de Torvalds et du contexte du conflit sur le patch journal_rewind.
- Caching, targets, data placement (bcachefs.org) : documentation officielle des cibles foreground_target, background_target et promote_target pour le tiering.
- Bcachefs exits experimental status in new performance release (The Register) : annonce de la version 1.38.6 par Kent Overstreet et sortie déclarée du statut expérimental.
