MeshXFS : un système de fichiers en cluster écrit par l'IA, bâti sur XFS

MeshXFS est un nouveau système de fichiers open source qui permet à plusieurs serveurs Linux de partager un même disque en même temps. Il a été créé en modifiant XFS à l'aide d'agents de programmation IA, a rapporté Phoronix le 17 octobre 2026. Le dépôt du projet indique qu'aucun humain n'a écrit, modifié à la main ni relu ligne par ligne son code de clustering. Cela en fait l'un des tests les plus nets à ce jour du code écrit par l'IA dans un domaine où un bug peut détruire des données.

XFS est un système de fichiers éprouvé, livré avec le noyau Linux. Un volume XFS normal ne peut être monté que par une seule machine à la fois. Un système de fichiers en cluster permet à plusieurs machines de monter le même disque partagé et d'y écrire ensemble, ce qui est courant dans les clusters de virtualisation.

Comment le code a été écrit

Claude Opus, fonctionnant comme agent de programmation autonome dans Claude Code d'Anthropic, « a écrit une grande partie » du code, selon la page GitHub du projet. Claude Fable, GPT, Gemini et Astra ont été consultés sur les problèmes les plus difficiles. Le dépôt est maintenu par Stephen P. Shoecraft. Il décrit le rôle humain comme consistant à diriger le travail, à fixer les exigences et à tester.

« Aucun humain n'a écrit, modifié à la main ni relu ligne par ligne le code de clustering », indique le dépôt. Phoronix rapporte que les agents d'IA ont aussi écrit et exécuté les tests.

Le changement est important. L'arborescence xfs/ du projet est passée d'environ 226 000 lignes à environ 314 000, selon Phoronix comme selon le dépôt. MeshXFS est un fork du code XFS de l'arbre de développement de Linux 6.19, et il est distribué sous la version 2 de la GNU General Public License.

Phoronix cite les objectifs du projet : « l'intégrité des données d'abord, ne jamais faire planter l'hôte, et ne pas dépasser le double du temps que prend XFS natif sur le même stockage ».

Comment MeshXFS fonctionne en cluster

Plusieurs machines qui écrivent sur un même disque ont besoin de règles pour éviter de s'écraser mutuellement. MeshXFS utilise pour cela quelques briques standard, selon Phoronix et le dépôt :

• Gestionnaires de verrous. L'un fonctionne par le réseau, entre les nœuds. L'autre conserve l'état des verrous sur le disque partagé lui-même, grâce à une commande de stockage appelée SCSI COMPARE AND WRITE.
• Isolation (fencing). Quand un nœud ne répond plus, les autres le coupent du disque pour qu'il ne puisse pas corrompre les données. MeshXFS le fait avec les réservations persistantes SCSI.
• Récupération. Chaque nœud dispose de sa propre portion du journal, le registre des modifications en attente. Un nœud survivant isole un nœud mort, rejoue son journal et poursuit le travail.

Le dépôt laisse 120 secondes aux autres nœuds pour déclarer un nœud mort, et 180 secondes pour l'avoir isolé.

Ce qui est publié, et ce qui ne l'est pas

La dernière version est la 0.90.130, intitulée « Stronger Recovery, Broader Platform Support » (récupération renforcée, prise en charge élargie des plateformes). Le dépôt est précis sur ses limites :

Domaine	Statut dans le dépôt
Tailles de cluster	Publié pour 2, 4, 8 et 16 nœuds ; 32 nœuds implémentés mais non publiés
Liaisons de stockage	iSCSI vérifié ; Fibre Channel et SAS non vérifiés
NVMe et NVMe-oF	Non pris en charge, car l'isolation et les verrous reposent sur des commandes SCSI
Baies de stockage	« Aucune version n'a été vérifiée sur une baie de stockage »
Défauts ouverts	123 fiches ; 69 touchent une configuration publiée
Paquets	Module DKMS pour Proxmox VE 9, RHEL 9, Ubuntu 24.04 et 26.04, Debian 12 et 13

Chaque version passe une suite de tests d'environ 30 lignes par configuration, sur de vrais clusters multinœuds, rapporte Phoronix. Le dépôt affiche aussi deux avertissements bien visibles : « Utilisez les outils MeshXFS, jamais les outils XFS standard » et « Vous utilisez la 0.90.37 ou une version antérieure ? Mettez à jour. »

Le projet arrive un jour après que les développeurs du noyau Linux ont décidé d'abandonner la balise IA Assisted-by dans les commits. MeshXFS est un projet distinct, hors du noyau. Mais il soulève la même question : quel niveau de relecture exige le code écrit par l'IA ?

Ce que cela signifie pour les développeurs

• N'y mettez pas encore de données de production. Le projet liste 69 défauts ouverts qui touchent des configurations publiées, et indique qu'aucune version n'a été vérifiée sur une baie de stockage. Traitez-le comme un projet de laboratoire.
• Testez-le si vous exploitez des clusters à stockage partagé. Si vous utilisez Proxmox ou une autre pile de virtualisation sur un stockage iSCSI, un essai en laboratoire montrera comment il bascule en cas de panne. Coupez l'alimentation d'un nœud et chronométrez la durée de l'isolation, à comparer aux 180 secondes annoncées.
• Vérifiez d'abord votre protocole de stockage. NVMe et NVMe-oF ne sont pas pris en charge du tout. Fibre Channel et SAS ne sont pas testés.
• N'utilisez jamais les outils de réparation XFS standard dessus. Le projet prévient que les outils XFS standard lisent les mauvais emplacements sur un disque MeshXFS. Utilisez les outils propres au projet.
• Prenez la liste des défauts comme modèle. Publier les défauts ouverts par gravité et par configuration est une bonne habitude pour tout projet, écrit par l'IA ou non. Cela indique aux utilisateurs exactement ce qui est revendiqué.