MeshXFS Forks XFS Into a 16-Node Clustered Filesystem With Code No Human Wrote or Reviewed

TL;DR

MeshXFS is a GPL-2.0 fork of Linux XFS that lets several machines mount the same block device read-write at once. Its author, Steve Shoecraft, says he set the goals and ran the tests but did not write, edit, or line-by-line review the code: Claude Opus, running in Claude Code, wrote a large share of it and consulted Claude Fable, GPT, Gemini and Astra on the hardest problems; the lock managers, fencing, journal recovery, on-disk envelope, userspace tools and test harnesses are all AI-written. The forked xfs/ tree grew from about 226k lines to about 314k. Release 0.90.130 landed on October 16, claims 17 configurations at 2 to 16 nodes, and publishes a defect queue with 123 open records. Phoronix covered it on October 17. Nobody outside the project has verified it yet.

What it is

A shared-disk clustered filesystem is the thing you reach for when several hosts need read-write access to one SAN LUN with coherent caches and crash consistency. Linux has two in mainline, OCFS2 and GFS2, and both lean on a cluster stack that lives outside the filesystem. MeshXFS puts all of it in one kernel module, mxfs.ko: locking, peer discovery, membership, heartbeat and fencing, with no daemon.

The data sits in a standard XFS v5 filesystem wrapped in a coordination envelope. mkfs.mxfs lays out a 4 KB MeshXFS superblock, a journal of about 64 MB, a disklock region of about 32 MB, and then the XFS data, with the XFS superblock shifted past the first three so the stock tools never mistake it for plain XFS. The README warns that xfs_repair and friends read the wrong sectors on a MeshXFS device and return garbage.

Two storage shapes are supported. Shared iSCSI LUNs over one path or a dm-multipath pair, and a two-node pair with no shared storage at all, where each host has a local disk replicated by DRBD dual-primary. NVMe, including NVMe-oF, is refused at mount because the fencing and lock commands are SCSI's.

Who wrote what

The README draws the line in one paragraph. Human-written: the upstream XFS source. AI-written: everything that makes it multinode, which means the distributed lock manager in dlm/, the overlay hooks in the XFS tree, the platform abstraction, the on-disk envelope, the tools, the test and benchmark harnesses, and every change to the forked XFS files since the fork. The project exists, in the author's words, "to find out whether AI could write a device driver this complex."

The repo shows the process as much as the result. There is a 2 MB CHANGELOG whose oldest entries, recovered from session notes, date to late April 2026 and read like a lab notebook: version 0.2.7 on April 25 fixed a concurrent-dd hang caused by holding a lock across a 120-second poll loop, and the "common lessons" section records that incremental builds once produced a stale module and burned an hour. There is a CLAUDE.md whose first section is titled "ABSOLUTE PROHIBITIONS" and whose three must-haves, dated September 30, are data integrity, then stability, then performance. One of its rules says a round-number timeout is proof you did not derive it, and that a timeout is a test failure even with zero errors. It also fixes the rig's baseline, native XFS rsyncing 700 MB in 3 to 4 seconds, and makes twice that the hard ceiling for any workload.

A file called success.md holds standing authorizations for an unattended loop, with lines marked APPROVED or PENDING. The commit line was PENDING as of July 17 with the note "i dont commit until its working." The GitHub history starts July 20. Three months of work before the first push is its own kind of code review.

How the locking works

Two lock managers are implemented and both ship. The default, net/mesh, is a conventional network DLM over TCP on port 7600 with lock mastership spread across members. The second, disk/caw, keeps the lock state in-band on the shared LUN and claims it with the SCSI COMPARE AND WRITE command (opcode 0x89), plus SCSI persistent reservations, so it needs no separate lock network.

Each node sends the target a block it expects to find and a block it wants to write, and the target performs the swap only if the current contents match the expectation. Picture a whiteboard that only lets you write your name in a box if the box still says what you saw a second ago, with the whiteboard doing the enforcing, so two people lunging for the same box cannot both win. The catch, which the README states plainly, is that the target has to implement the compare atomically. The Linux LIO target reports success without doing so, so on LIO you must use net/mesh; the disk/caw release was verified on SCST's vdisk_fileio only.

Membership and death work the same way on both managers. Peers find each other by UDP multicast, liveness is an on-disk heartbeat with per-node slot claiming and a 60-second lease, and a node that stops answering is fenced with SCSI persistent reservations before anyone touches its state. Each node owns a journal slice, so a survivor replays the dead node's journal and the cluster resumes.

The release bar and the public defect queue

The unusual part of this repo is how it handles bugs. The defect queue lives in data/defects.json and is read with tools/defects.py. Each record names what was observed, the evidence, the smallest cluster it reached and which configurations its evidence covers. A record nobody has classified counts against every configuration. A configuration is released only when the tool lists no open defect that reaches it and can corrupt or lose data, or crash, hang or shut down a node.

A defect leaves the queue two ways: disproved by direct evidence, or fixed and verified, where "verified" means the cause was shown by an instrument in the running kernel, the change was made at that cause, and a test that meets the cause passes. The README says "could not reproduce" closes nothing. For crashes and races the test is also run on a control build, and if the build without the fix does not fail the way the defect did, the test proves nothing about the change.

That bar is why the release matrix is odd-shaped. Version 0.90.130 claims 2, 4, 8 and 16 nodes for both lock managers on single-path and multipath iSCSI, plus the two-node DRBD pair, for 17 configurations. Nothing between 17 and 64 nodes is claimed, because from 17 nodes up there are open defects that can lose data or hang a node. Multipath was first claimed in 0.90.51, withdrawn when later releases found defects reaching it, and claimed again in 0.90.124 and 0.90.130 after fixes. The upgrade section says 0.90.36 and earlier can lose data and 0.90.37 has crash and wedge races. All of it sits on the first screen of the README.

What the testing covers, and what it does not

Each release runs a suite of about 31 rows on multi-node clusters: coherency, POSIX behavior, lock contention, membership change, node crash and fencing, network partition, kernel health, soak, a clean fsck, and pace against native XFS on the same storage. Multipath configurations add eight or nine path-fault rows run under load on every node. Each row keeps its last eleven runs, and a genuine failure anywhere in that window blocks a PASS.

Then comes the section titled "What this does not cover," which is the part to read before you put a VM datastore on it. Every shared-storage node is a KVM guest on one host, and the shared LUNs are iSCSI LUNs served from that same host; no release has been verified on a storage array. The one exception is the DRBD pair, verified on two physical Proxmox VE 9 hosts. The soak row is 30 seconds unless asked for longer, and no multi-hour soak is part of the sequence. Fibre Channel and SAS are unverified. The README also admits that the first time two nodes were killed at once under load, the run found defects every single-death row had passed over.

Performance numbers are the author's own and come from the rig. On the physical DRBD pair, one AlmaLinux install takes 1.4 to 1.9 times as long as on a local disk, and plain XFS on the same DRBD takes about three-quarters of MeshXFS's time. A lone sequential writer gets about three-quarters of XFS's speed. The lock-tuning work in 0.90.117 and 0.90.118 cut abandoned lock answers from 84 to 17, the longest queue wait from 39 to 13 seconds, and the longest allocation walk from 46 to 8.5 seconds. The README lists the remaining one-second stall on VM writes as an open record. The one Hacker News comment on the launch said the benchmarks fail and are slow, and pointed at the bench/ directory, whose README still carries a May sample where a cross-node rsync was killed at nine minutes for a job native XFS finishes in seconds.

Why a builder should care

Strip away the filesystem and this is a case study in running a coding agent on something a human cannot review line by line. The author's answer to "who checks the code" was to make the agent prove every fix with an instrument in the running kernel, run a control arm for races, derive every timeout from native XFS, and keep the defect queue public so the claims can be checked against the records. That is a verification regime, and it is the part of the repo worth copying even if you never mount an mxfs volume.

The limits are on display too. Three months of work before a first push, a 2 MB changelog, a cross-model consult for lock-protocol design, and the result still carries 69 open records on shipped configurations and runs behind native XFS on the one physical rig. The author's framing was "could AI write a device driver this complex," and the README answers yes with a long list of asterisks. Mainline XFS maintainers have not weighed in, and nobody expects them to merge a 314k-line fork over the weekend.

The packages are DKMS builds for Proxmox VE 9, RHEL 9, Ubuntu 24.04 and 26.04, and Debian 12 and 13, each tied to a listed kernel, and any other kernel is untested even on the same distribution. Shared storage must have a power-loss-protected write cache, and the module refuses a clustered mount without the target_cache_protected=1 flag. Put it on a lab LUN, not on the datastore you like.

Key Takeaways

• MeshXFS is a GPL-2.0 XFS fork that lets up to 16 nodes mount one LUN read-write, with locking, fencing and recovery inside a single kernel module and no userspace cluster daemon.
• The author says no human wrote, edited or line-by-line reviewed the clustering code. Claude Opus in Claude Code wrote most of it, consulting Claude Fable, GPT, Gemini and Astra on lock protocols, recovery races and fencing.
• The xfs/ tree grew from about 226k to about 314k lines, and every change to the forked files is AI-written.
• Release 0.90.130 claims 17 configurations. The public defect queue holds 123 open records, 69 of which reach released configurations and are classified as slowness rather than data loss, crash or hang.
• Testing runs on KVM guests sharing iSCSI LUNs from one host, with a 30-second soak and no storage array; only the two-node DRBD pair ran on physical hosts, where plain XFS was faster.
• The verification regime (instrumented root cause, control builds for races, timeouts derived from native XFS, a public defect bar) is the transferable lesson for anyone letting an agent write code they cannot review.

Sources: MeshXFS repository and README, MeshXFS 0.90.130 release notes, MeshXFS CHANGELOG, MeshXFS CLAUDE.md, MeshXFS bench/ README, Phoronix: MeshXFS: AI Adapts XFS Into A Clustered File-System, Hacker News thread.