MeshXFS transforme XFS en système de fichiers clusterisé écrit intégralement par une IA
Le 17 octobre 2026, Phoronix relate la sortie de MeshXFS, un système de fichiers clusterisé POSIX sous GPL-2.0 dont aucune ligne n’a été écrite par un humain : Claude Opus a adapté XFS en y ajoutant verrouillage distribué, fencing et reprise après crash. Pour les équipes stockage, c’est moins un concurrent de Ceph qu’un changement de méthode à observer : l’humain fixe les invariants, l’IA écrit et teste le code.
17 octobre 2026. Michael Larabel relate sur Phoronix la sortie de MeshXFS, un système de fichiers clusterisé POSIX sous licence GPL-2.0. Aucun humain n’a écrit une seule ligne de son code : l’arbre XFS forké est passé d’environ 226 000 à 314 000 lignes, toutes produites par une IA. Chaque version passe une suite d’une trentaine de scénarios sur de vrais clusters multi-nœuds. Pourquoi c’est important : pour la première fois, un système de fichiers distribué — verrouillage, fencing, reprise après crash — sort sans qu’un développeur en ait rédigé ni relu le code.
Claude Opus a adapté XFS, pas réinventé un format
MeshXFS ne part pas de zéro. Le projet, lancé par Steve Shoecraft, s’appuie sur le code XFS amont, écrit par les développeurs historiques de XFS. « Tout ce qui transforme XFS en un système de fichiers que de nombreuses machines peuvent monter en lecture-écriture simultanée a été écrit par une IA », explique-t-il.
Claude Opus, fonctionnant comme agent autonome dans Claude Code, a réalisé l’essentiel du travail, en consultant Claude Fable, GPT, Gemini et Astra sur les problèmes les plus délicats : conception du protocole de verrous, courses de reprise, correction du fencing. L’IA a également écrit et exécuté les tests, diagnostiqué les échecs et corrigé les défauts qu’elle détectait.
La phrase clé du projet est la question qui l’a fondé : « une IA peut-elle écrire un pilote de système de fichiers noyau, et pas un simple, mais un système clusterisé avec verrouillage distribué, accès concurrent depuis de nombreux nœuds, fencing et reprise après crash ? » La réponse, selon Shoecraft, est désormais oui : MeshXFS est « un système de fichiers clusterisé POSIX, publié, open source (GPL-2.0) ».
Ce que l’IA a écrit concrètement
Le détail du périmètre couvert par l’IA est précis, et c’est lui qui donne la mesure de l’expérience :
- Deux gestionnaires de verrous distribués : l’un sur le réseau, l’autre qui conserve l’état des verrous sur le disque partagé lui-même via SCSI COMPARE AND WRITE, sans aucun réseau de verrous.
- La cohérence de cache entre nœuds, le fencing par réservations persistantes SCSI et la reprise de journal pilotée par les nœuds survivants.
- L’enveloppe sur disque autour de XFS ainsi que les outils utilisateur — mkfs, fsck, resize.
- Chaque modification du code XFS forké depuis le fork, ce qui explique la croissance de l’arbre xfs/ d’environ 226 000 à 314 000 lignes.
- Les harnais de test, l’automatisation des bancs de test et la validation des versions.
Le point qui distingue MeshXFS d’un simple générateur de code : l’IA n’a pas seulement produit le pilote, elle a produit la preuve qu’il fonctionne. Chaque release passe une suite d’une trentaine de scénarios exécutés sur de vrais clusters multi-nœuds, à travers des situations réelles variées.
La barre fixée par l’humain
Le rôle de Steve Shoecraft s’est limité à trois contraintes, qu’il formule ainsi : « l’intégrité des données d’abord, ne jamais faire planter l’hôte, et rester dans un temps d’exécution inférieur à deux fois celui de XFS natif sur le même stockage ». Il précise n’avoir « ni écrit, ni édité, ni relu le code ».
C’est le basculement que le projet illustre. Dans un développement classique, l’humain écrit le code et la machine l’exécute. Ici, l’humain écrit les invariants de sécurité — ce qui n’a pas le droit d’arriver — et l’IA produit le code, puis les tests qui vérifient que ces invariants tiennent. La compétence critique se déplace de la rédaction vers la spécification : formuler des propriétés vérifiables, plutôt que relire ligne à ligne un pilote noyau.
Cette évolution n’est pas isolée. Linus Torvalds a lui-même confié à Claude Code une refonte du cache de pages du noyau, une expérience que nous avons documentée dans notre analyse sur Torvalds et Claude Code. MeshXFS va un cran plus loin : il ne s’agit plus d’assister un mainteneur humain, mais de produire un sous-système entier sans relecture humaine.
Face à Ceph, GlusterFS et OCFS2
Le premier réflexe est de comparer MeshXFS aux systèmes établis : Ceph (objet, bloc et fichier via CephFS), GlusterFS, OCFS2 ou GFS2. La comparaison tourne vite court, et elle n’est pas à l’avantage du nouveau venu. Ces systèmes cumulent des années de relecture humaine, des correctifs de production et un écosystème complet — sauvegarde, snapshots, supervision, support commercial.
MeshXFS n’a rien de tout cela. Aucune distribution ne l’embarque, aucun éditeur ne le supporte, et sa validation se résume pour l’instant à une trentaine de scénarios sur des clusters réels — un début, pas une preuve de maturité. Le diriger vers des données de production aujourd’hui serait une décision de laboratoire, pas d’ingénierie.
L’intérêt n’est donc pas le produit, mais la méthode. La question que pose MeshXFS n’est pas « Ceph est-il menacé ? » mais « jusqu’où va la part de l’IA dans le code de stockage, et que reste-t-il à l’humain ? ». La réponse tient en une phrase : il reste la spécification des invariants et le budget de performance — précisément les deux choses qu’un SRE sait formuler et qu’une IA ne peut pas inventer seule.
Une trajectoire qui dépasse le stockage
MeshXFS s’inscrit dans un mouvement plus large que le seul stockage. Linus Torvalds a confié à Claude Code une refonte du cache de pages du noyau, les développeurs du noyau débattent de l’étiquette « assisted-by » pour les contributions assistées par IA, et Debian a voté une résolution encadrant l’usage de l’IA générative dans ses contributions. Le point commun : l’IA cesse d’être un assistant de complétion et devient un producteur de code système, dont la sortie doit être jugée sur ses propriétés vérifiées plutôt que sur sa provenance.
C’est un changement de posture pour les équipes d’infrastructure. Là où l’on relisait le code pour y trouver des bugs, on devra de plus en plus spécifier ce qui constitue un bug, et laisser la machine écrire les tests qui le détectent. MeshXFS est le cas limite de cette bascule : personne n’a relu le code, et c’est pourtant la discipline de spécification de son auteur qui fait tenir la promesse d’intégrité.
Pour un auditeur ou un RSSI, le corollaire est direct : la question de la provenance du code ne suffit plus. Ce qui compte, c’est la qualité des propriétés que l’on a su exprimer et faire vérifier. Un code écrit par un humain mais sans test est, à cette aune, plus risqué qu’un code écrit par une IA mais adossé à une suite de scénarios de reprise et d’intégrité.
Verdict
Si vous cherchez un remplaçant de production pour Ceph, GlusterFS ou OCFS2, passez votre chemin pour l’instant : MeshXFS est une expérience publiée sous GPL-2.0, pas un produit éprouvé sur des années de charge réelle. Si vous évaluez la place de l’IA dans votre chaîne de stockage, c’est un objet d’étude précieux — et un signal. La bonne question n’est plus « puis-je faire confiance au code écrit par une IA ? », mais « suis-je capable d’exprimer mes invariants de sûreté assez précisément pour qu’une IA puisse écrire les tests qui les vérifient ? ». Un SRE qui sait spécifier l’intégrité, la tolérance aux pannes et le budget de performance possède désormais un levier que le simple relecteur de code n’a plus.