Btrfs a supprimé son fixup worker de copie sur écriture pendant la fenêtre de fusion de Linux 7.2, au motif que la couche de gestion mémoire du noyau rendait ce mécanisme inutile. Le raisonnement était faux, et le symptôme est le pire qui soit : une perte de données silencieuse, sans erreur remontée et sans rien d'exploitable dans les journaux. David Sterba, mainteneur chez SUSE, a envoyé le 6 août 2026 une demande d'intégration restaurant plus de 600 lignes de cette infrastructure, et Linus Torvalds l'a prise pour la 7.2-rc7. Si vous faites tourner une version candidate de la 7.2 sur du btrfs, voici l'information de la semaine. La 7.2 stable est attendue plus tard en août.
The short answer
Btrfs a supprimé son fixup worker de copie sur écriture pendant la fenêtre de fusion de Linux 7.2, convaincu que la couche de gestion mémoire du noyau avait éliminé les conditions qu'il protégeait. Ce n'était pas le cas, et le résultat fut une perte de données silencieuse. David Sterba, mainteneur chez SUSE, a envoyé le 6 août 2026 une demande d'intégration restaurant cette infrastructure, désormais dans Git pour la 7.2-rc7. La 7.2 stable est attendue ce mois ci. Seules les versions candidates de la 7.2 étaient concernées : les noyaux publiés et de distribution n'ont jamais été exposés.
Il existe un type de rapport de bug qui fait taire les développeurs de systèmes de fichiers, et ce n'est pas celui où la machine s'arrête brutalement. Un plantage est bruyant, reproductible et daté. Le mauvais rapport, c'est celui où tout a semblé fonctionner et où les données ne sont pas là.
C'est ce que Btrfs a découvert dans les versions candidates de Linux 7.2, et la correction est arrivée cette semaine. David Sterba, de SUSE, a envoyé le 6 août une demande d'intégration restaurant l'infrastructure de fixup worker en copie sur écriture supprimée quelques semaines plus tôt. Linus Torvalds l'a acceptée, et elle est dans Git pour la 7.2-rc7.
Ce que le worker protégeait
Btrfs n'écrase jamais les données sur place. Une modification est écrite à un nouvel emplacement et les métadonnées sont mises à jour pour pointer dessus, ce qui rend les instantanés peu coûteux et les sommes de contrôle utiles.
Cette conception impose une contrainte. Avant qu'une page ne soit écrite, le système de fichiers doit savoir qu'elle arrive, car il lui faut d'abord réserver de l'espace et créer une extent ordonnée. Sur le chemin normal, tout va bien, puisque c'est lui qui marque la page sale.
Le fixup worker traite le chemin anormal : une page qui arrive déjà sale, sans que btrfs ait été prévenu. Sterba le décrit comme un mécanisme de détection des pages et folios marqués sales à l'insu du système de fichiers et nécessitant une correction de copie sur écriture. Lorsqu'il en trouve une, il effectue la préparation manquante après coup pour que la page soit écrite correctement.
Une suppression raisonnable, et fausse
Pendant la fenêtre de fusion de la 7.2, le mécanisme a été retiré. Le raisonnement : la couche de gestion mémoire avait suffisamment changé pour que les conditions produisant ces pages sales inattendues ne se produisent plus, ce qui ferait du fixup worker du code inatteignable.
Supprimer du code réellement mort est un bon travail, et 600 lignes méritent d'être supprimées. Le raisonnement n'a simplement pas survécu au contact des systèmes en production. Les conditions surviennent toujours. Le filet retiré, la demande d'intégration énonce la conséquence sans détour : la conséquence de ne pas le faire est une perte de données silencieuse.
Silencieuse est le mot qui compte
La plupart des problèmes de système de fichiers se signalent. Une écriture échoue et retourne une erreur. Une erreur d'entrée sortie remonte à l'application. Quelque chose apparaît dans dmesg. Un scrub signale une somme de contrôle incohérente et nomme le fichier.
Rien de tout cela ici. La donnée n'est pas écrite, et le système continue. Un scrub ultérieur n'aide pas, puisqu'il compare les données stockées aux sommes de contrôle stockées, et que les deux décrivent ce qui est réellement arrivé sur le disque. Il n'existe aucune trace de ce qui aurait dû s'y trouver et n'y est pas.
C'est pourquoi le changement est passé en rc7 malgré sa taille. Il n'y a aucune ligne de journal qu'un administrateur puisse rechercher, aucune règle de supervision qui l'attrape, aucun moyen d'auditer une machine après coup et d'en être sûr. La seule défense fiable est une copie sur un autre système de fichiers.
Qui était dans la fenêtre
Uniquement les personnes faisant tourner des versions candidates de Linux 7.2 sur btrfs, approximativement de la rc1 à la rc6. Aucun noyau stable publié n'a embarqué la suppression. Si vous êtes en 7.1, sur un noyau à support long terme ou sur celui de votre distribution, vous n'avez jamais été exposé et il n'y a rien à faire.
Faire atterrir plus de 600 lignes de code fonctionnel en rc7 n'est pas la façon dont un cycle est censé se terminer. Sterba note qu'environ la moitié relève du débogage et du support plutôt que de la logique principale, ce qui réduit le risque, et Torvalds l'a prise malgré tout. L'arbitrage opposait un gros changement tardif à la livraison d'un noyau stable qui perd des données sans le dire, et ce n'est pas un arbitrage serré.
Ce que nous en retenons
Le correctif lui même ne demande rien à la plupart des lecteurs. L'habitude qu'il défend vaut davantage.
Les versions candidates servent précisément à trouver ce genre de chose, et quelqu'un l'a trouvée : le processus a fonctionné. Ce que l'épisode illustre, c'est pourquoi le code de système de fichiers est le mauvais endroit où être en avance. La plupart des casses de pré publication sont bruyantes, si bien que le marché implicite d'une version candidate est que vous remarquerez le problème et reviendrez en arrière. La perte silencieuse annule ce marché. Vous ne remarquez rien, vous ne revenez donc pas en arrière, et la sauvegarde que vous n'avez pas vérifiée est la seule copie qui compte encore.
Si vous testez des noyaux sur de vraies données, et il y a de bonnes raisons de le faire, gardez la sauvegarde sur un système de fichiers que le noyau testé n'a jamais monté, et restaurez la de temps en temps pour vérifier qu'elle fonctionne. Ce conseil est ancien et ennuyeux, et c'est exactement pour ce mode de défaillance qu'il a été écrit.
Sources et pour aller plus loin
- Linux 7.2-rc7 restaure l'infrastructure fixup worker de Btrfs pour traiter des pertes de données silencieuses, Phoronix, 6 août 2026
- Demande d'intégration restaurant l'infrastructure fixup worker, David Sterba, liste de diffusion noyau
- Correctifs Btrfs complémentaires envoyés pour la même version candidate
- Changements Btrfs par version de noyau, documentation officielle
Questions fréquentes
Que fait réellement le fixup worker ?
Il traite un cas qui ne devrait pas se produire mais qui se produit. Btrfs est un système de fichiers en copie sur écriture : il n'écrase jamais les données sur place, il écrit la nouvelle version ailleurs puis met à jour les métadonnées qui pointent dessus. Pour que cela fonctionne, le système de fichiers doit connaître chaque page qui va être écrite, car il lui faut réserver de l'espace et préparer une extent ordonnée avant l'écriture différée. Le fixup worker existe pour les pages marquées sales sans que le système de fichiers en ait été informé. David Sterba le décrit comme un mécanisme de détection des pages et folios marqués sales à l'insu du système de fichiers et nécessitant une correction de copie sur écriture. Quand il en trouve une, il effectue la préparation après coup pour que la page soit écrite correctement au lieu d'être perdue. C'est un filet de sécurité sur un chemin que le système de fichiers ne contrôle pas.
Pourquoi avoir supprimé ce mécanisme ?
Parce que les conditions qui créent ces pages sales inattendues étaient réputées disparues. La couche de gestion mémoire a beaucoup évolué au fil des années, et le raisonnement pendant la fenêtre de fusion 7.2 était qu'elle empêchait désormais les pages d'arriver dans cet état jusqu'à btrfs, ce qui aurait fait du fixup worker du poids mort. Supprimer du code réellement inatteignable est une bonne pratique, et 600 lignes représentent une vraie simplification. Le problème est que la conviction n'a pas tenu en pratique. Les conditions surviennent toujours, et une fois le filet retiré, ces pages n'avaient plus nulle part où aller. C'est un schéma classique du travail noyau : un morceau de code défensif survit à l'explication qui l'avait motivé, quelqu'un en déduit que la cause est corrigée, et la suppression démontre le contraire.
Étais-je concerné, et comment le savoir ?
Vous n'étiez exposé que si vous faisiez tourner une version candidate de Linux 7.2, en gros de la rc1 à la rc6, sur un système de fichiers btrfs. Aucun noyau stable publié n'a jamais été livré sans le fixup worker : quiconque est en 7.1, sur un noyau à support long terme ou sur un noyau de distribution n'est jamais entré dans la fenêtre. La seconde partie de la question est plus inconfortable. Perte silencieuse signifie exactement cela : aucune erreur d'écriture, aucune erreur d'entrée sortie remontée à l'application, aucun message dans dmesg, et un système de fichiers qui continue de passer un scrub puisque les sommes de contrôle correspondent à ce qui a effectivement été écrit. Il n'y a aucune ligne de journal à rechercher après coup. Si vous avez fait tourner une rc 7.2 sur des données qui comptent, la réponse honnête est que la vérification se fait contre une sauvegarde, pas contre le système de fichiers lui même.
Est il normal de restaurer 600 lignes aussi tard dans un cycle ?
C'est inhabituel, et c'est justement ce qu'il faut y lire. Un cycle de versions candidates est censé se resserrer vers des correctifs de plus en plus petits et sûrs à l'approche de la version finale, et la rc7 est le dernier arrêt avant celle ci. Faire atterrir plus de 600 lignes de code fonctionnel à ce stade est l'inverse de la trajectoire normale, et Linus Torvalds l'a tout de même acceptée. Sterba précise qu'environ la moitié du code restauré relève du débogage et du support plutôt que du chemin principal, ce qui abaisse un peu le risque, mais la taille reste notable. La raison de ce passage en force est que l'alternative consistait à livrer un noyau stable qui perd des données sans le dire. Entre un gros changement tardif et un bug de correction silencieux dans un système de fichiers, le gros changement tardif est le plus sûr des deux.
Que faut il en tirer pour sa politique de noyaux ?
Le correctif lui même ne demande rien à qui utilise des noyaux publiés : la 7.2 sortira avec le worker en place. La leçon générale est celle qu'il faut garder. Les versions candidates servent à tester, et tester veut dire du matériel que vous pouvez perdre, pas le système de fichiers qui héberge des données irremplaçables. Les bugs de système de fichiers forment une catégorie particulièrement mauvaise pour l'adoption précoce parce qu'ils peuvent être silencieux, ce qui annule l'hypothèse habituelle selon laquelle vous remarquerez le problème et reviendrez en arrière. Si vous faites malgré tout tourner des noyaux de pré publication sur de vraies données, et beaucoup ont de bonnes raisons de le faire, la protection concrète est une sauvegarde sur un système de fichiers que le noyau testé n'a jamais monté, plus la discipline de vérifier les restaurations au lieu de les supposer.