MeshXFS: A Clustered XFS for Proxmox, Written by an AI Agent Loop

On 16 October 2026 the first public release of MeshXFS appeared on GitHub: a filesystem that exposes the XFS layout on one shared block device to several Proxmox nodes at once, with a lock manager of its own. Author Stephen P. Shoecraft describes the project as the work of an AI agent loop. The idea lands on a spot every Proxmox installation knows: without shared storage there is no live migration, and shared storage is the most expensive part of the whole setup. We followed the project for a week and asked two questions. What does the way it is made tell us, and would it fit an estate like ours?

What the project is

MeshXFS is a fork of the XFS from Linux 6.19 with its own lock layer. One node holds locks on ranges of metadata, the other nodes request them through a distributor that runs over TCP, over SCSI commands on the shared disk, or over DRBD status. The delivery is a DKMS package: it builds the kernel module mxfs.ko and brings mkfs.mxfs, chk_mxfs, resize_mxfs and mxfs_admin along. The licence is GPL-2.0-only, the file is in the repository and carries the author's name. The disk layout itself does not change.

The repository has existed since 20 July 2026 and counts 96 commits from exactly one contributor, with 42 stars and no pull request ever opened. Between 23 September and 16 October there are 19 published releases, the latest being v0.90.130. Part of the construction site is visible in the repository: an agent context directory, a 25 kB CLAUDE.md, a 157 kB run script and a 76 kB status file are all part of the development branch.

Two statements from the README belong in any assessment. The first: no release has been verified on a storage array, the tests run on QEMU-KVM. The second narrows the hardware evidence in the same section: the only real hardware test on record is a two-node setup over DRBD on two physical Proxmox 9 hosts, as of version 0.90.107. That drbd attach method is built for DRBD 8.4 and ends at two nodes.

The release page slows you down

v0.90.130 went out on 16 October at 12:37 UTC. On 20 October at 00:33 UTC the author overwrote the text of that page with a warning: testing of the next release had found three defects in configurations that this release claims to cover. The wording is explicit about running MeshXFS on test data only, keeping backups, and checking the volume with chk_mxfs -v while it is unmounted on every node.

The three defects are not edge notes. One shuts the filesystem down after a node is fenced and rejoins. One produces, in an eight-node setup with path multipathing, a filename that two directory entries own while the link count stays at one. A third shuts the filesystem down about 16 seconds after a frozen peer stops answering during a create. The last two sit outside the configuration the project measures against: the benchmark runs two nodes with multipath and roughly 40,000 files.

The timing is the finding. At 09:48 UTC on 20 October the repository still carried a note pinning version 0.90.131 for testing. By 00:33 UTC the same day, that note pointed at 0.90.130 and the page was one advisory richer. Unreleased builds are therefore produced and withdrawn again before anyone can install them.

The defect file on the main branch

The main branch carries data/defects.json, a machine-readable list of every known defect with severity, affected configurations and mechanism. We read the file on 20 October: 129 entries, of which 46 are critical, 42 major, 27 high, 9 minor and 5 medium. Nine were opened on 20 October, six of them critical.

Three of those six critical entries name version 0.90.131, the unpublished build, so they are regressions found during current work and an argument for the check loop that caught them. The other three carry no version boundary and therefore apply to any configuration: two describe a failed mount that never returns, one notes uninitialised replay work being queued during a slow mount. That class is not unfamiliar to us. On our own storage fix list, the top item is still the switch from on-no-quorum io-error to suspend-io, which is the same category: what a cluster does when a peer goes away.

The project's performance numbers sit next to this: 997 percent on random reads and 356 percent on sequential writes against native XFS. They come from the project itself, measured on QEMU-KVM, four nodes, no array, with a thirty second run as the longest step. Beating XFS on a virtual disk is no surprise, because XFS on shared storage was never built for that access pattern.

The Linux Foundation supplied the counterweight on the very same day. Its study on generative AI in open source development, presented on 20 October, puts 25 percent of incoming pull requests across open source projects at low quality, rising to 31 percent at large projects, and lets the maintainers themselves estimate those shares. MeshXFS sits outside that count: there are no incoming requests there to classify as slop. The bottleneck is the absence of outside contributions. A reviewer from outside is missing because the process does not provide for one.

Does it fit our clusters

The interesting question was never speed against XFS on a virtual disk, but whether the thing fits our environment. On 20 October we read the storage list of one of our six nodes through the Proxmox API: a local directory, not shared, two DRBD resources for guest OS and SQL disks, plus three backup servers as stores. There is no NFS, no CIFS and no SAN target. Replication runs over LINSTOR with DRBD in protocol C on two bonded 100-gigabit links; the estate is close to 60 TiB raw, of which roughly 30 TiB is usable after the mirror half and the safety margin, with about 12.5 TiB allocated.

This is where MeshXFS parts ways with us. It needs a block store that several nodes see at the same time. We do not have that path, and adding it would mean a second storage setup beside the existing one, not an extension of it. The drbd attach type would be the route that comes closest to our world: it requires DRBD 8.4 and stops at two nodes, and our estate is six nodes across two data centre sites.

A field report in the issue tracker shows what happens at that seam. On 20 October a user described a two-node setup with DRBD 8.4.11, Pacemaker and IPMI fencing. After a forced reboot the mount never comes back: DRBD reports the disk as inconsistent, the built-in two-node authority refuses to power the neighbour off, and the lock layer fails to initialise. The same session shows DRBD 9 being refused because the replication protocol is not C. A second report from that day, about the mounted directory being empty after a node was shut down, had no reply when we read it. The Proxmox forum thread from 16 October, opened by the maintainer to look for testers, has no answer from Proxmox staff so far.

Our verdict is WATCH. We are not putting it into a cluster and not building a test rig for it: the precondition is missing and the release page itself recommends test data and backups. Three things are worth watching. Answered issues, because recovery after fencing and a reboot is what decides whether a cluster filesystem is usable in our HA setup. A drbd 9 attach path, or one that works beyond two nodes. And whether the announced comparison run against other cluster filesystems arrives; if it does, we measure against those numbers instead of the project's own.

Further Reading

• The MeshXFS repository on GitHub, read on 20 Oct 2026: README with the array and KVM limitations, data/defects.json with 129 entries, LICENSE as GPL-2.0-only
• Release v0.90.130, published 16 Oct 2026 12:37 UTC, page text last edited 20 Oct 2026 00:33 UTC, with the advisory and the three defect descriptions
• Issue #2: mount that never returns after a forced reboot on DRBD 8.4.11, DRBD 9 refused, open and unanswered on 20 Oct 2026. Issue #3: empty mount directory after a node was shut down, also open. Issue #1 covers the 400 error from the storage command on Proxmox 9.2.21
• Proxmox forum: the maintainer's thread looking for testers from 16 Oct 2026
• The blog post that brought the attention: introduction to the filesystem, with a note about own comparison benchmarks within the next days
• Linux Foundation study on generative AI in open source development from 20 Oct 2026, with the pull request and contribution volume shares