Btrfs reçoit son plus gros lot de performance depuis des années, et le chiffre principal est que les entrées sorties directes atteignent désormais environ 95 % du maximum théorique au lieu d'environ 50 %. David Sterba, de SUSE, a envoyé les nouveautés du système de fichiers pour la fenêtre de fusion de Linux 7.3 le mercredi 19 août 2026. Quatre changements distincts apportent des gains de deux à cinq fois, et une modification discrète de configuration entame la retraite du cache d'espace libre en version un. Si vous faites tourner Btrfs sous une base de données, sur du disque rotatif, ou sur toute application qui appelle fsync en boucle, au moins un de ces points apparaîtra dans vos propres mesures.
The short answer
David Sterba, de SUSE, a envoyé les nouveautés Btrfs pour la fenêtre de fusion de Linux 7.3 le mercredi 19 août 2026. Un tampon de rebond iomap fait passer les entrées sorties directes d'environ 50 % du maximum théorique à environ 95 %. Remplacer un XArray par une liste LRU locale pour les tampons d'extents inhibés apporte environ trois fois. Supprimer un délai d'un jiffy en mode non SSD apporte environ cinq fois sur le débit de journalisation. Sauter la détection de trous pendant un fsync complet en apporte environ cinq de plus. Le cache d'espace libre en version un est désormais désactivé par défaut.
Une demande de fusion de système de fichiers se lit d'ordinaire comme une liste de correctifs avec un ou deux pour cent au bout. Celle ci contient quatre multiplicateurs, et aucun ne vient d'un nouveau format sur disque.
Ce qui a été fusionné
David Sterba, de SUSE, a envoyé les nouveautés Btrfs pour la fenêtre de fusion de Linux 7.3 le mercredi 19 août 2026. Quatre changements de performance se détachent, et ils sont indépendants les uns des autres.
Le premier concerne le chemin d'entrées sorties directes. Btrfs utilise maintenant un tampon de rebond iomap plutôt que de retomber sur des entrées sorties tamponnées dans les situations où ce repli était auparavant obligatoire. La demande de fusion chiffre l'ancien comportement : un compromis entre correction et vitesse qui plafonnait le débit à environ 50 % du maximum théorique, contre environ 95 % désormais. C'est presque un doublement, et c'est le changement le plus susceptible d'apparaître sur une courbe de production.
Le deuxième remplace un XArray par une liste LRU locale pour le suivi des tampons d'extents inhibés. Sterba annonce environ trois fois. Il s'agit de comptabilité de métadonnées plutôt que d'un motif d'accès particulier, c'est donc le plus largement applicable des quatre.
Le troisième supprime un délai inutile d'un jiffy qui s'appliquait en mode non SSD lorsque plusieurs tâches de journalisation tournaient en même temps. La latence baisse et le débit grimpe d'environ cinq fois sur la charge d'exemple citée. Un jiffy vaut un tic d'horloge noyau, soit quatre millisecondes sur un noyau à 250 Hz et une milliseconde sur un noyau à 1000 Hz. C'est peu, jusqu'à ce que vous le multipliiez par chaque tâche de journalisation en file.
Le quatrième ajoute une détection de saut de trous pendant un fsync complet, pour les fichiers sans trous mais porteurs d'un grand nombre d'extents. Cela représente environ cinq fois de plus, et la forme de fichier décrite est extrêmement courante : les journaux en ajout, et les fichiers de base de données réécrits sur place assez souvent pour se fragmenter en de nombreux extents sans jamais devenir creux.
À côté de cela, la demande porte des améliorations de verrouillage sur diverses opérations, les corrections de bugs habituelles et du travail de qualité de code.
La ligne discrète sur l'espace libre v1
Sous les chiffres de performance se cache un changement de configuration à lire deux fois. Le code du cache d'espace libre v1 est maintenant désactivé par défaut, au profit de l'arbre d'espace libre qui est la recommandation depuis des années.
Rien n'est supprimé et aucun système de fichiers ne cesse de se monter. Ce qui change, c'est la posture par défaut. Btrfs affiche depuis un moment un avertissement de dépréciation dans le journal système quand il détecte la v1, et éteindre le code par défaut est l'étape qui précède habituellement la suppression. Les distributions qui compilent leur propre noyau décideront chacune si elles le réactivent, et la plupart ne s'en donneront pas la peine longtemps.
La conséquence pratique, c'est que cette version invite à faire l'audit. Affichez le superbloc avec btrfs inspect-internal dump-super -f sur le périphérique et cherchez FREE_SPACE_TREE parmi les drapeaux compat_ro. S'il y est, vous êtes en v2 et il n'y a rien à faire. S'il est absent, le système de fichiers est encore en v1, et la migration tient en deux étapes : monter une fois avec l'option space_cache=v2 pour que l'arbre d'espace libre soit construit, puis lancer btrfs check --clear-space-cache v1 système de fichiers démonté pour effacer l'ancien cache.
Aucune des deux étapes n'est exotique, aucune n'est risquée, mais la seconde parcourt tout le système de fichiers : elle appartient donc à une fenêtre de maintenance plutôt qu'à un mardi après midi. Le faire maintenant, à votre calendrier, est nettement plus agréable que de le faire plus tard parce qu'une mise à jour de noyau aura posé la question à votre place.
Lire les multiplicateurs honnêtement
Quatre chiffres entre trois et cinq fois dans une même demande de fusion, c'est inhabituel, et il vaut la peine de préciser ce qu'ils ne sont pas. Aucun n'affirme que Btrfs est globalement cinq fois plus rapide. Chacun se rattache à un chemin de code précis, et trois des quatre se rattachent à une forme de charge précise.
Si vos volumes Btrfs hébergent des images de conteneurs lues en séquentiel, le travail sur les entrées sorties directes ne vous touchera pas. S'ils se trouvent sous PostgreSQL avec O_DIRECT activé, il vous touchera beaucoup. Si votre stockage est rotatif et que Btrfs ne le signale pas comme solide, la suppression du délai de journalisation est celle à surveiller. Si votre application appelle fsync sur un fichier très étendu à chaque validation, le quatrième changement est le vôtre.
Cette précision est un atout plutôt qu'une réserve. Elle vous permet de prédire lequel vous concerne avant d'installer quoi que ce soit, et elle indique que la bonne réaction consiste à mesurer le seul chemin qui correspond à votre charge, plutôt qu'à lancer un banc d'essai générique et à en lire la moyenne.
Deux éléments cadrent le calendrier. Linux 7.2 est sorti à la mi août 2026 avec l'ordonnancement conscient du cache parmi ses nouveautés phares, donc 7.3 débute son cycle et la version stable est à environ deux mois. La même fenêtre de fusion a déjà été chargée côté systèmes de fichiers, avec FailFS intégré et deux systèmes de fichiers des années 1990 abandonnés. Btrfs lui même enchaîne visiblement le travail de correction, notamment le fixup worker rétabli pendant les versions candidates de 7.2, ce qui indique raisonnablement que ces gains arrivent sur une base de code réellement entretenue.
Quoi faire cette semaine
Rien d'urgent, et deux points à mettre sur une liste.
Vérifiez la version du cache d'espace libre sur chaque système de fichiers Btrfs que vous exploitez, car cet audit coûte une commande par périphérique et la réponse ne devient que plus coûteuse à traiter plus tard. Et si vous avez une charge qui correspond à l'un des quatre chemins modifiés, prenez une mesure de référence maintenant, pendant que vous êtes encore en 7.2, pour que la comparaison d'octobre porte sur un relevé et non sur un souvenir.
Sources et pour aller plus loin
- Btrfs Ready With More Performance Improvements For Linux 7.3, Phoronix, 19 août 2026
- BTRFS gets a substantial performance improvement in Linux 7.3, Aptivi, 19 août 2026
- Changements par version de noyau, documentation officielle Btrfs
- btrfs(5), options de montage dont space_cache=v2, documentation officielle Btrfs
Questions fréquentes
Qu'est ce qui a changé exactement dans le chemin d'entrées sorties directes ?
Btrfs utilise désormais un tampon de rebond iomap pour les entrées sorties directes, au lieu de retomber sur des entrées sorties tamponnées dans les cas où il devait le faire auparavant. Ce repli était une décision de correction et non un oubli, mais il coûtait cher. La demande de fusion décrit l'ancien comportement comme atteignant environ 50 % du maximum théorique, contre environ 95 % pour le nouveau chemin. En pratique cela revient presque à doubler les charges qui ouvrent leurs fichiers avec O_DIRECT, autrement dit les bases de données, les images de machines virtuelles et toute application qui gère son propre cache et ne veut pas du cache de pages sur son chemin. La garantie de correction ne change pas. Seul le mécanisme qui la préserve a changé.
Lesquels de ces gains vais je réellement constater ?
Cela dépend de votre charge de travail. L'amélioration des entrées sorties directes concerne les lecteurs et écrivains O_DIRECT, donc les bases de données et le stockage des hyperviseurs. Le gain de cinq fois sur le débit de journalisation vient de la suppression d'un délai inutile d'un jiffy en mode non SSD lorsque plusieurs tâches de journalisation tournent en même temps, il concerne donc les disques rotatifs et les grappes que Btrfs ne considère pas comme du solide. Le gain de cinq fois sur le fsync complet concerne les fichiers sans trous mais porteurs d'un grand nombre d'extents, forme très fréquente pour les journaux en ajout et pour les fichiers de base de données réécrits sur place de nombreuses fois. Le gain de trois fois sur les tampons d'extents est plus général, car il touche le suivi des métadonnées plutôt qu'un motif d'accès précis.
Qu'arrive t il au cache d'espace libre en version un ?
Le code du cache d'espace libre v1 est désormais désactivé par défaut dans la configuration du noyau, au profit de l'arbre d'espace libre, qui est la version deux et la recommandation depuis des années. Rien n'est encore supprimé et rien ne casse à la mise à jour, mais la direction est sans ambiguïté. La version un affichait déjà un avertissement de dépréciation dans le journal système quand elle était détectée, et désactiver le code par défaut est l'étape qui précède habituellement la suppression. Si vous avez encore des systèmes de fichiers en v1, c'est la version qui invite à les migrer, à votre rythme plutôt qu'à celui du noyau.
Comment savoir quel cache d'espace libre utilise un système de fichiers ?
Lancez btrfs inspect-internal dump-super -f sur le périphérique bloc et regardez les drapeaux compat_ro. Si FREE_SPACE_TREE y figure, le système de fichiers est déjà en v2 et vous n'avez rien à faire. Sinon, il est encore en v1. Pour migrer, montez une fois le système de fichiers avec l'option space_cache=v2, ce qui construit l'arbre d'espace libre, puis effacez l'ancien cache avec btrfs check --clear-space-cache v1 pendant que le système de fichiers est démonté. Faites l'étape de vérification dans une fenêtre de maintenance plutôt qu'en pleine production, car elle parcourt tout le système de fichiers.
Quand Linux 7.3 sera t il disponible pour moi ?
Linux 7.2 est sorti à la mi août 2026, donc 7.3 débute sa fenêtre de fusion et une version stable arrive dans deux mois environ au rythme habituel. Ensuite, l'attente dépend entièrement de votre distribution. Une distribution en publication continue l'aura en quelques semaines. Une distribution d'entreprise sur un noyau à long terme rétroportera de façon sélective ou pas du tout, ce qui, pour du travail de performance sur système de fichiers, signifie généralement pas du tout. Si ces chiffres comptent pour vous sur le plan commercial, le plan honnête consiste à mesurer votre propre charge sur une version candidate plutôt qu'à attendre en espérant.