MeshXFS is a new open-source file system that lets several Linux servers share one disk at the same time. It was built by modifying XFS with AI coding agents, Phoronix reported on October 17, 2026. The project's repository says no human wrote, hand-edited or reviewed its clustering code line by line. That makes it one of the clearest tests yet of AI-written code in a place where a bug can destroy data.
XFS is a mature file system that ships in the Linux kernel. A normal XFS volume can be mounted by only one machine at a time. A clustered file system lets several machines mount the same shared disk and write to it together, which is common in virtualization clusters.
How the code was written
Claude Opus, running as an autonomous coding agent in Anthropic's Claude Code, "wrote a large share" of the code, according to the project's GitHub page. Claude Fable, GPT, Gemini and Astra were consulted on the hardest problems. The repository is maintained by Stephen P. Shoecraft, and it describes the human role as directing the work, setting requirements and testing.
"No human wrote, hand-edited, or line-by-line reviewed the clustering code," the repository says. Phoronix reports that the AI agents also wrote and ran the tests.
The change is large. The project's xfs/ tree has grown from about 226,000 lines to about 314,000, according to both Phoronix and the repository. MeshXFS is a fork of the XFS code in the Linux 6.19 development tree, and it is licensed under version 2 of the GNU General Public License.
Phoronix quotes the project's goals as "data integrity first, never crash the host, and stay within twice the time native XFS takes on the same storage."
How MeshXFS clusters
Several machines writing to one disk need rules to avoid overwriting each other. MeshXFS uses a few standard pieces for that, according to Phoronix and the repository:
- Lock managers. One works over the network between nodes. The other keeps lock state on the shared disk itself, using a storage command called SCSI COMPARE AND WRITE.
- Fencing. When a node stops responding, the others cut it off from the disk so it cannot corrupt data. MeshXFS does this with SCSI persistent reservations.
- Recovery. Each node has its own slice of the journal, the log of pending changes. A surviving node fences a dead one, replays its journal and carries on.
The repository gives the others 120 seconds to declare a node dead and 180 seconds to have fenced it.
What is released, and what is not
The latest version is 0.90.130, titled "Stronger Recovery, Broader Platform Support." The repository is specific about its limits:
| Area | Status in the repository |
|---|---|
| Cluster sizes | Released at 2, 4, 8 and 16 nodes; 32 nodes implemented but not released |
| Storage links | iSCSI verified; Fibre Channel and SAS not verified |
| NVMe and NVMe-oF | Not supported, because fencing and locks rely on SCSI commands |
| Storage arrays | "No release has been verified on a storage array" |
| Open defects | 123 records; 69 reach a released configuration |
| Packages | DKMS module for Proxmox VE 9, RHEL 9, Ubuntu 24.04 and 26.04, Debian 12 and 13 |
Each release runs a test suite of about 30 rows per configuration, on real multi-node clusters, Phoronix reports. The repository also carries two prominent warnings: "Use the MeshXFS tools, never the stock XFS tools," and "Running 0.90.37 or earlier? Upgrade."
The project lands a day after Linux kernel developers moved to drop the AI Assisted-by tag from commits. MeshXFS is a separate project outside the kernel, but it raises the same question of how much review AI-written code needs.
What this means for developers
- Do not put production data on it yet. The project lists 69 open defects that reach released setups and says no release has been verified on a storage array. Treat it as a lab project.
- Test it if you run shared-storage clusters. If you use Proxmox or another virtualization stack on iSCSI storage, a lab trial will show how it fails over. Pull the power on a node and time how long fencing takes against the stated 180 seconds.
- Check your storage protocol first. NVMe and NVMe-oF are not supported at all. Fibre Channel and SAS are untested.
- Never run the standard XFS repair tools on it. The project warns that stock XFS tools read the wrong places on a MeshXFS disk. Use the project's own tools.
- Read the defect list as a model. Publishing open defects by severity and configuration is a useful habit for any project, AI-written or not. It tells users exactly what is claimed.
This article was first published on Tech AI Wire.
Also available in
Deutsch · 日本語 · Français · Español · Português
Related on Tech AI Wire
Sources
- MeshXFS: AI Adapts XFS Into A Clustered File-System - Phoronix
- sshoecraft/meshxfs - GitHub
Top comments (2)
The agents writing AND running the tests is the part that gets me. Same model grading its own homework in a place where a bug eats data. Curious if anyone outside that loop has thrown real failover chaos at it yet, that's the only review I'd trust here
Agreed. Independent chaos testing is what really proves reliability, especially when data integrity is at stake.