Suppression du code Bcachefs du noyau : ce que cela signifie pour l’avenir du système de fichiers

Bcachefs sort du noyau Linux 6.18 et emporte 117 000 lignes de code. La décision de Linus Torvalds clôt dix ans de va-et-vient entre patches, tests et désaccords. Pour les admins, la question est simple : continuer la route en module externe ou revenir aux classiques Ext4, XFS et ZFS ?

Le timing est tout sauf anodin. Les paquets DKMS viennent d’atterrir dans les dépôts de Debian, Fedora et Ubuntu, évitant ainsi un lundi noir aux utilisateurs productifs. Reste à comprendre ce que ce retrait raconte sur la gouvernance du kernel et, surtout, sur l’avenir des systèmes de fichiers.

Retrait brutal de Bcachefs du noyau Linux 6.18 : les raisons réelles

Tout part d’un conflit de style de code et de communication entre Kent Overstreet et la core team. Linus Torvalds a toléré l’intégration dans la 6.7 « pour voir », puis gelé les contributions dès la 6.17. La fenêtre de merge suivante a confirmé la sentence : suppression pure et simple.

L’argument officiel : « réduire la confusion » puisque le module DKMS est prêt. Officieusement, il s’agit de rappeler qu’aucun projet ne passe au-dessus du process collaboratif, fût-il prometteur. En prime, le noyau gagne 350 ko sur l’ISO, un clin d’œil à ceux qui jurent encore par un boot minimaliste.

Impact immédiat sur Red Hat, Canonical et les dérivées

Red Hat n’avait jamais activé Bcachefs par défaut, préférant la prudence héritée de RHEL. Canonical en parlait pour son installateur « Ubuntu Pro », mais misait déjà sur ZFS pour le chiffrement natif. Côté Fedora, les nightly spins incluaient Bcachefs depuis mars ; la Fedora 40 passera donc en module DKMS, comme Debian Sid contemporains.

Le risque ? Un upgrade kernel qui oublie de recompiler le module sur un serveur de prod. Les mainteneurs conseillent de verrouiller la version ou d’outiller Ansible pour valider la présence du .ko après chaque reboot. Une gymnastique que certains n’ont pas goûtée depuis l’époque des drivers Nvidia 96xx.

Alternatives éprouvées : Ext4, XFS et ZFS tiennent la barre

En 2025, Ext4 reste le choix par défaut pour 80 % des installations serveur, selon l’enquête StackShare. Sa solidité et son faible overhead CPU le rendent indétrônable pour les workloads conteneurisés. XFS, lui, rafle les déploiements à très gros fichiers grâce à son allocation contiguë redoutable.

ZFS conserve l’avantage des snapshots et de la déduplication en ligne, même si la licence CDDL bride toujours son intégration mainline. Les benchmarks récents sur Ryzen 9000 montrent un écart de seulement 3 % en lecture séquentielle vis-à-vis de Bcachefs, un delta négligeable face au confort du support officiel.

Faut-il migrer ou rester sur Bcachefs en module DKMS ?

Les clusters qui tournent déjà sous Bcachefs ne sont pas condamnés. Le module DKMS compile en 40 s sur un vCPU, et la compatibilité remonte au kernel 5.15 LTS. Toutefois, chaque upgrade majeur deviendra un checkpoint manuel : test de restauration, rebuild du raid, validation des checksums.

La tentation de revenir à Ext4 est forte pour les petites équipes. Pourtant, abandonner CoW et checksums multiplie les writes amplifiés et l’usure SSD. Le compromis plausible : convertir les volumes critiques en ZFS tout en gardant Bcachefs pour les caches d’objets éphémères, là où sa compression LZ4 brille encore.

Ce feuilleton révèle la culture du noyau Linux

Depuis 30 ans, le kernel évolue au rythme d’un patchset toutes les neuf secondes. Linus Torvalds l’a rappelé : la porte est ouverte à tout code, mais le débat reste public et parfois musclé. Bcachefs n’est ni le premier ni le dernier à goûter à cette sélection naturelle ; rappelez-vous Reiser4 ou Tux3.

La communauté voit dans cette éviction un signal clair : nombre et qualité de tests priment sur la brillance d’un design. Les maintainers de subsystèmes s’en félicitent, car le backlog de bugs storage diminue déjà. Ironiquement, le buzz autour de la suppression offre à Bcachefs une visibilité que son commit initial n’avait jamais eue.

Vers un retour un jour ?

Kent Overstreet n’a pas dit son dernier mot. Il travaille sur un « bcachefs-next » aligné sur les conventions de style et de test du kernel. S’il parvient à rallier une task-force de reviewers, la porte de la 6.20 pourrait se rouvrir.

En attendant, les administrateurs doivent choisir : garder un œil sur les releases DKMS ou solidifier leurs volumes avec les trois piliers historiques. Dans un monde où chaque milliseconde d’I/O compte, la décision ne se prend pas à la légère, mais l’odyssée du stockage libre continue, patch après patch.

Source: linuxnews.de