La plupart des entrées d'une fenêtre de fusion vous disent ce qui vient d'arriver. Celle ci vous dit ce qui arrive bientôt. Les correctifs NVDIMM et DAX fusionnés pour Linux 7.3, rapportés le dimanche 23 août 2026, sont surtout des corrections et du remaniement préparant quelque chose qui n'a pas encore été soumis : FAMFS, le système de fichiers pour mémoire attachée au tissu que l'ingénieur Micron John Groves porte depuis début 2024. Il a traversé treize séries de relecture, il ne vise pas la fenêtre de fusion de 7.3, et Micron table sur une acceptation en amont courant 2026. Ce n'est pas non plus un système de fichiers généraliste, et c'est la partie qu'il faut comprendre.
The short answer
Les mises à jour NVDIMM et DAX fusionnées pour Linux 7.3 sont surtout des corrections et du remaniement qui préparent le terrain pour FAMFS, le système de fichiers de Micron pour la mémoire attachée au tissu, qui n'a pas encore été soumis en amont. FAMFS offre un accès par fichiers, au niveau de l'octet, à de très grandes réserves de mémoire partagée, et il permet à plusieurs hôtes de monter le même système de fichiers depuis la même mémoire, ce que les systèmes fs-dax existants ne font pas. Il est volontairement spécialisé et concerne surtout les serveurs CXL.
Lire le résumé d'une fenêtre de fusion et constater que le sous système DAX a passé un cycle à faire du ménage n'est pas d'ordinaire une information. Cela le devient quand on remarque pourquoi ce ménage a lieu.
Du travail de fond, pas une fonctionnalité
L'activité NVDIMM et DAX de Linux 7.3 se résume à des corrections, du remaniement de code et des améliorations générales. Le but annoncé est de préparer l'introduction de FAMFS, qui n'a pas été soumis pour inclusion.
Cet ordre des opérations est habituel pour un système de fichiers qui a besoin de quelque chose d'un sous système partagé. FAMFS repose sur DAX, le mécanisme qui permet à une projection d'atteindre la mémoire directement au lieu de passer par le cache de pages, et DAX a été écrit pour la mémoire persistante dans des machines mono hôte. Le pointer vers une réserve de mémoire que plusieurs hôtes voient simultanément fait remonter des hypothèses qui n'avaient jamais été fausses auparavant, simplement parce que personne ne lui avait posé ces questions.
L'ordre est donc : rendre DAX prêt, puis faire atterrir le système de fichiers. Faire l'inverse produit une fusion que les relecteurs ne peuvent pas évaluer, puisque la moitié des changements porteraient sur du code que le système de fichiers ne possède pas.
Ce que veut dire mémoire attachée au tissu
Débarrassée des sigles, la forme est simple. Un tissu CXL 2.0 ou 3.0 peut placer une réserve de mémoire vive derrière un commutateur et l'exposer à plusieurs hôtes, la cohérence et la connexion étant prises en charge par le protocole. Au lieu d'une mémoire appartenant à une machine, vous obtenez une mémoire appartenant à une baie.
Ce sont les volumes en jeu qui imposent de nouveaux logiciels. FAMFS est conçu autour de réserves où cent téraoctets ou plus est un chiffre courant, pas un cas extrême. À cette échelle, la vieille habitude de copier un jeu de données vers l'hôte qui en a besoin cesse d'être une inefficacité pour devenir le coût entier du travail.
Le manque, c'est que la mémoire partagée brute n'a pas de vocabulaire. C'est une plage d'adresses. Elle ne dit pas à un second hôte où commence un jeu de données, quelle est sa taille, à qui il appartient, ni si quelqu'un est en train d'y écrire. Chaque projet qui a atteint cette échelle a fini par reconstruire à la main la même couche manquante, mal, et de façon incompatible avec le projet suivant.
FAMFS fournit ce vocabulaire en utilisant celui que tout le monde parle déjà. Les régions deviennent des fichiers. Les fichiers ont des noms, des tailles et des propriétaires. Une application en projette un et travaille sur les octets.
La ligne qui le sépare d'ext4
L'affirmation qui compte est plus étroite qu'elle n'en a l'air, et il vaut la peine d'être précis.
L'accès direct à un stockage adossé à la mémoire n'a rien de neuf. ext4 et XFS gèrent fs-dax depuis des années, et projeter un fichier dans un processus sans cache de pages intermédiaire est un terrain bien balisé.
Ce qui est neuf, c'est que FAMFS permet à plusieurs hôtes de monter le même système de fichiers depuis la même mémoire, ce que les systèmes fs-dax existants ne font pas. Tout ce qui est difficile dans FAMFS découle de cette seule phrase. Un système de fichiers classique suppose qu'un seul noyau commande ses métadonnées. Allocation, horodatages et structure de répertoires sont modifiables sans risque parce que personne d'autre ne les modifie. Placez deux noyaux indépendants devant les mêmes octets et chacune de ces hypothèses demande un réexamen.
C'est aussi pourquoi le projet insiste sur son caractère spécialisé. Micron ne propose pas FAMFS comme système de fichiers généraliste, et lit le besoin comme un accès par fichiers, au niveau de l'octet, à de très grandes mémoires partagées et désagrégées. Un périmètre étroit est ce qui rend le problème difficile traitable : on peut dire non aux fonctionnalités qui imposeraient une coordination distribuée complète.
Pilote noyau, et treize séries
Deux détails de processus méritent d'être relevés car ils disent quelque chose du sérieux de l'affaire.
Le premier est la question FUSE. Micron a envisagé d'implémenter FAMFS en espace utilisateur via FUSE et a conclu qu'un pilote de système de fichiers noyau autonome était la meilleure approche, avec un engagement de maintenance et une demande client démontrée. L'argument tient mieux que dans sa version habituelle. FAMFS existe pour retirer les copies du chemin entre une application et une grande réserve de mémoire, donc placer un démon en espace utilisateur dans la gestion des fautes combat l'objectif du projet.
Le second est le nombre de relectures. Treize séries, c'est beaucoup, et cela se lit de deux façons selon le tempérament : une contribution qui peine à convaincre, ou une contribution que les relecteurs continuent de travailler. Puisque le sous système DAX est maintenant préparé spécifiquement pour la recevoir, c'est la seconde lecture que les faits soutiennent. Les mainteneurs du noyau ne remanient pas un sous système pour une série qu'ils comptent rejeter.
C'est une actualité de système de fichiers plus discrète que la fusion de FailFS plus tôt dans le même cycle, qui est arrivée complète et avec une chute. FAMFS n'a ni l'une ni l'autre, et comptera pourtant davantage pour qui achète du matériel à l'échelle de la baie.
Faut il s'en préoccuper dès maintenant
Si vous n'avez pas de mémoire attachée au tissu, cela ne change rien pour vous, ni aujourd'hui ni après la fusion. Il n'existe pas de version de FAMFS qui améliore un serveur ordinaire, et il ne concourt pas pour la place où vous exécutez actuellement ext4 ou XFS.
Si vous dimensionnez du matériel compatible CXL pour les prochaines années, cela vaut la peine de suivre le dossier, car le support logiciel est en général ce qui décide si un déploiement de mise en commun mémoire devient un produit ou reste un projet de recherche. Une interface de système de fichiers que plusieurs hôtes peuvent monter, c'est ce qui transforme une réserve partagée d'une ligne sur une fiche technique en quelque chose qu'une équipe applicative peut réellement viser.
Le calendrier réaliste est 2026 pour l'acceptation en amont, selon l'objectif de Micron, les noyaux des distributions suivant bien après. Le cycle 7.3 n'est pas celui où cela arrive. C'est celui où la route est goudronnée.
Sources et pour aller plus loin
- Linux 7.3 Makes Preparations Toward Upstreaming FAMFS File-System, Phoronix, 23 août 2026
- Micron Engineer Sends Out Linux Patches For New FAMFS File-System, Phoronix
- Famfs: a filesystem interface to shareable memory, LWN.net
- Introduce the famfs shared-memory file system, LWN.net
Questions fréquentes
Quel problème FAMFS résout il réellement ?
Nommer et partager une réserve de mémoire que plusieurs machines voient en même temps. Un tissu CXL peut exposer une grande réserve de mémoire vive à plusieurs hôtes à travers un commutateur, mais de la mémoire partagée brute n'a aucune structure : aucun moyen de dire que telle région contient tel jeu de données, aucun moyen pour un second hôte de le retrouver, ni permissions ni métadonnées. FAMFS pose une interface de système de fichiers par dessus, si bien que des régions de mémoire partagée deviennent des fichiers dax projetables en mémoire, avec des noms, des tailles et un propriétaire. Les applications atteignent alors les données avec mmap et une sémantique de fichier normale, au lieu d'inventer leur propre allocateur et leur propre annuaire, ce que tout le monde faisait auparavant.
En quoi est ce différent des systèmes de fichiers fs-dax existants comme ext4 ou XFS ?
Le partage. ext4 et XFS gèrent tous deux fs-dax, qui permet de projeter de la mémoire persistante directement dans un processus sans passer par le cache de pages, et cette partie n'a rien de neuf. Ce qu'ils ne gèrent pas, c'est que plusieurs hôtes montent le même système de fichiers depuis la même mémoire au même moment. C'est précisément la capacité qu'ajoute FAMFS, et c'est la raison pour laquelle il existe en tant que système de fichiers distinct plutôt que sous forme de correctif à un système établi. Dès que deux machines indépendantes partagent une réserve de mémoire, les hypothèses qu'un système de fichiers mono hôte fait sur qui peut modifier les métadonnées cessent de tenir.
Faut il du matériel CXL pour l'utiliser ?
CXL est la cible de déploiement évidente, mais FAMFS n'est pas spécifique à CXL dans sa conception. Une instance FAMFS peut être créée sur un périphérique /dev/pmem en mode fs-dax ou sur un périphérique /dev/dax en mode devdax, donc la mémoire sous jacente peut venir de plusieurs endroits. Si CXL domine la conversation, c'est parce qu'un tissu CXL 2.0 ou 3.0 est le moyen pratique d'obtenir une réserve de mémoire vive partagée entre hôtes à travers un commutateur, avec des protocoles de cohérence et de connexion déjà spécifiés. Sans un dispositif de ce genre, la mémoire attachée au tissu reste un exercice de laboratoire.
Pourquoi un pilote noyau plutôt que FUSE ?
Parce que le travail se joue sur le chemin de projection en mémoire, précisément là où un système de fichiers en espace utilisateur coûte le plus cher. Micron a évalué la voie FUSE et conclu qu'un pilote de système de fichiers noyau autonome était la meilleure approche, en s'engageant à le maintenir et en invoquant une demande client démontrée. L'argument passe mieux ici que d'habitude : tout l'intérêt de FAMFS est un accès direct au niveau de l'octet sans copie intermédiaire, donc faire transiter les opérations de métadonnées et la gestion des fautes par un démon en espace utilisateur va contre la raison même pour laquelle on le veut.
Quand pourrai je réellement l'utiliser ?
Pas sur 7.3. Le système de fichiers lui même n'a pas été soumis pour la fenêtre de fusion de 7.3, et ce qui a atterri est le travail de fond DAX et NVDIMM qui rendra une soumission ultérieure plus propre. Micron vise une acceptation en amont courant 2026, et treize séries de relecture suggèrent une contribution que les relecteurs prennent au sérieux plutôt qu'une contribution ignorée. Même après sa fusion, ce n'est pas quelque chose que vous déployez sur un serveur ordinaire : il lui faut de la mémoire attachée au tissu à viser. Voyez le comme une infrastructure qui arrive pour une classe de machines précise, pas comme un système de fichiers que vous choisirez entre ext4 et XFS.