Chris Mason, qui a lancé Btrfs chez Oracle en 2007, a envoyé le jeudi 27 août 2026 un correctif d'une ligne dans le fichier MAINTAINERS qui le fait passer de co-mainteneur à relecteur désigné, en précisant que son dernier jour chez Meta était le vendredi 28 août. Si vous exploitez Btrfs en production, cela ne change rien au système de fichiers : David Sterba, chez SUSE, assure le travail réel de maintenance depuis des années et reste inscrit comme mainteneur. Ce qui change, c'est une adresse électronique et une entrée MAINTAINERS enfin exacte. Mason indique que ses contributions au noyau continuent et que l'engagement de Meta ne bouge pas.
The short answer
Chris Mason a envoyé le jeudi 27 août 2026 un correctif d'une ligne sur la liste linux-btrfs, qui le fait passer de co-mainteneur à relecteur désigné et remplace son adresse fb.com par une adresse kernel.org. Il a quitté Meta le vendredi 28 août. David Sterba, chez SUSE, qui assure la maintenance réelle de Btrfs depuis des années, reste le mainteneur inscrit. Mason indique que son travail sur le noyau continue et que l'engagement de Meta envers le noyau et Btrfs ne change pas. Pour qui exploite ce système de fichiers, c'est une mise à jour d'écriture, pas un changement de cap.
Celui qui a écrit la première ligne de Btrfs s'est retiré de sa liste de mainteneurs cette semaine, et le système de fichiers ne s'en est pas aperçu. C'est la version saine de cette histoire.
Ce que le correctif fait réellement
Le changement tient en deux lignes dans un fichier. Dans le bloc BTRFS FILE SYSTEM du fichier MAINTAINERS du noyau, l'entrée M pour Chris Mason à une adresse fb.com disparaît, et une entrée R pour Chris Mason à mason@kernel.org apparaît. La ligne M de David Sterba chez suse.com n'est pas touchée, pas plus que la liste de diffusion, le champ d'état ou l'adresse de la documentation.
Cette seule lettre porte toute l'histoire. M signifie mainteneur : la personne qui applique les correctifs, entretient l'arbre, envoie la demande d'intégration à Linus, et doit répondre quand quelque chose casse dans le sous système. R signifie relecteur désigné : get_maintainer.pl continue de la mettre en copie de chaque correctif touchant le sous système, sa relecture compte toujours, mais rien ne fusionne par elle.
Son message de commit est direct sur la raison : Sterba fait le travail de maintenance depuis des années, et devoir mettre l'adresse à jour offrait une bonne occasion de rendre le fichier plus exact. C'est toute la justification, et elle est honnête.
L'adresse est le déclencheur, pas le sujet
Mason a publié la série le jeudi 27 août à 19h31 UTC, avec un court message d'accompagnement précisant que son dernier jour chez Meta était le vendredi 28 août et que ses adresses meta.com et fb.com allaient bientôt cesser de fonctionner. Quiconque a quitté une entreprise dont l'adresse figurait dans un fichier amont connaît cette corvée.
Il ajoute deux choses à lire attentivement. D'abord, que l'engagement de Meta envers le noyau et Btrfs ne change pas. Ensuite, que ses propres contributions au noyau continuent. Il ne dit pas où il va.
Les deux affirmations sont crédibles au vu des faits. Meta exploite Btrfs sur un parc de production très large, ce qui explique précisément qu'elle ait constitué une équipe noyau autour, et ce parc se moque de qui a démissionné. Les autres ingénieurs noyau de l'entreprise apparaissent à chaque fenêtre de fusion, y compris pour la refonte des entrées sorties directes et de fsync arrivée dans Linux 7.3.
Ce que cela signifie si vous exploitez Btrfs
Rien sur le plan opérationnel, et il vaut mieux dire pourquoi précisément plutôt que de se contenter de rassurer.
Le risque de maintenance dans un sous système du noyau est réel, mais il se mesure à qui fusionne les correctifs, qui prépare les rétroportages stables et qui répond aux rapports de régression. Sur Btrfs, ce sont Sterba et l'équipe stockage de SUSE depuis des années, avec les ingénieurs de Meta comme groupe contributeur majeur. Rien de tout cela n'a changé cette semaine. Ce qui a changé, c'est que le fichier MAINTAINERS décrit maintenant cette organisation avec exactitude au lieu de décrire celle d'il y a une décennie.
La leçon vraiment utile ici porte sur les entrées MAINTAINERS périmées en général. Le noyau en est plein, et elles comptent parce que get_maintainer.pl est l'outil par lequel un contributeur débutant décide à qui écrire. Une entrée qui pointe vers une adresse d'entreprise morte coûte silencieusement des cycles de relecture à tout le monde en aval. Mason a corrigé la sienne. La plupart des gens ne le font jamais.
Une longue course, toujours en cours
Mason a lancé Btrfs en 2007 chez Oracle, à une époque où Linux n'avait aucun système de fichiers à copie sur écriture avec instantanés et sommes de contrôle dans l'arbre principal. Il a fallu des années pour qu'il devienne digne de confiance, et sa réputation de cette période le suit encore, parfois injustement. Il est aujourd'hui le choix par défaut de plusieurs distributions, il soutient de grands parcs chez Meta et ailleurs, et il continue d'absorber du travail sérieux de performance version après version, depuis la correction de régressions dans le fixup worker jusqu'à la conversion vers iomap.
Mason a aussi passé ces dernières années sur la relecture de code assistée par IA pour le noyau, sujet dont la communauté débat longuement, pendant que Debian tranchait cette semaine sa propre politique sur l'IA générative. Où il atterrit ensuite reste inconnu. Qu'il demeure relecteur du système de fichiers qu'il a créé, sous une adresse kernel.org plutôt qu'une adresse d'entreprise, est une issue raisonnable pour tout le monde.
Sources et pour aller plus loin
- PATCH 0/1 Update my MAINTAINERS entry, Chris Mason, linux-btrfs, 27 août 2026
- PATCH MAINTAINERS: update Chris Mason's email address, linux-btrfs
- Chris Mason Steps Down As Btrfs Co-Maintainer, Departing Meta, Phoronix, 28 août 2026
- Documentation Btrfs, btrfs.readthedocs.io
Questions fréquentes
Faut il s'inquiéter d'exploiter Btrfs en production après ce changement ?
Non, et la raison est que ce changement officialise une situation vieille de plusieurs années au lieu d'en créer une nouvelle. David Sterba, chez SUSE, est le mainteneur principal effectif de Btrfs depuis longtemps : il gère les demandes d'intégration, les rétroportages stables et la relecture quotidienne, et il reste inscrit comme mainteneur. Chris Mason passe sur la ligne de relecteur désigné, ce qui signifie en langage noyau qu'il reste copié sur les correctifs et continue de les relire. Le rythme des commits, la cadence de la branche stable et l'investissement de SUSE comme de Meta dans le système de fichiers sont exactement là où ils étaient la semaine dernière.
Quelle est la différence réelle entre une ligne M et une ligne R dans MAINTAINERS ?
Dans le fichier MAINTAINERS du noyau, M désigne le mainteneur, celui qui prend les correctifs, les fusionne, envoie la demande d'intégration en amont et doit répondre de son sous système. R désigne un relecteur désigné, quelqu'un que get_maintainer.pl met automatiquement en copie et dont l'avis compte, mais qui n'a la charge de fusionner quoi que ce soit. Concrètement, pour un contributeur, les correctifs envoyés à linux-btrfs atteignent toujours Mason, mais la personne dont dépend une fusion est Sterba. Le changement est plus modeste que le titre ne le laisse croire.
Pourquoi ce changement maintenant plutôt qu'à un moment plus propre ?
À cause du courrier électronique, prosaïquement. Le correctif de Mason remplace l'adresse fb.com de son entrée par mason@kernel.org, puisque ses adresses Meta et Facebook cessent de fonctionner maintenant qu'il a quitté l'entreprise. Devoir toucher à cette ligne est précisément ce qui l'a poussé à la rendre conforme à la réalité, et son message de commit le dit : Sterba fait le travail de maintenance depuis des années et le fichier devrait le refléter. Les entrées MAINTAINERS du noyau se démodent en permanence, et les moments où on les corrige sont en général des occasions banales comme celle ci.
Meta arrête t il d'investir dans Btrfs ?
Mason a répondu directement dans son message et indiqué que l'engagement de Meta envers le noyau et envers Btrfs ne change pas. Cela mérite d'être pris au sérieux pour une raison pratique : Meta exploite Btrfs à très grande échelle sur son propre parc, ce qui explique que l'entreprise ait constitué une équipe noyau autour du sujet. On n'abandonne pas un système de fichiers dont dépend son infrastructure de production parce qu'un ingénieur est parti. Meta dispose par ailleurs d'une équipe noyau conséquente au delà de Mason, et ses contributions amont sont visibles à chaque version.
Où va Chris Mason ensuite ?
Il ne l'a pas dit. Son message couvre le changement d'adresse, la ligne de maintenance et ses remerciements à Sterba et aux développeurs de Btrfs, et s'arrête là. Ce qu'il a précisé, c'est que ses propres contributions au noyau continueront, et c'est la partie qui compte pour qui suit le sous système. À côté de Btrfs, il a passé ces dernières années à travailler sur la relecture de code assistée par IA pour le noyau Linux, si bien que son prochain poste touchera peut être davantage ce domaine que le stockage. Tant qu'il n'annonce rien, tout le reste relève de la spéculation.