[RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Steve Shoecraft]

I asked claude code for an email body and this is what It said:

  MXFS is a Linux shared-disk clustered filesystem derived from XFS: several
  nodes mount the same block device read/write, with distributed locking,
  cache coherency, fencing (SCSI persistent reservations) and journal
  recovery of failed nodes.

  It is built as an out-of-tree module. The xfs/ tree is XFS forked from the
  6.19 development cycle and heavily modified, plus a coordination overlay,
  a DLM and a platform layer; it is not a patch series against upstream.

  The code was written by an AI coding agent (Anthropic's Claude Code),
  directed by me; I have not reviewed it line by line. The README states
  this at the top.

  The released configuration is two nodes over the TCP DLM transport,
  verified on specific kernels (Ubuntu 24.04 6.8, Proxmox VE 9 6.17/7.0,
  RHEL 9.8), and it passes the project's two-node test suite. Other
  configurations (more nodes, a disk-based lock transport) are in
  development. Open defects, with their evidence, are tracked publicly in
  the repository (data/defects.json).

  I am not proposing upstream inclusion. I am looking for review from
  filesystem and XFS developers, especially of the locking, coherency and
  recovery design, and of where it diverges from XFS's assumptions.

  https://github.com/sshoecraft/mxfs

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Christoph Hellwig]

I don't think too many people are going to care about your LLM dump,
or even review it.  But please make sure you use different magic numbers
so that a mxfs image left in the wild is not mistaken for an xfs one.

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Steve Shoecraft]

Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.

I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.

Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.

Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.


> On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
> 
> I don't think too many people are going to care about your LLM dump,
> or even review it.  But please make sure you use different magic numbers
> so that a mxfs image left in the wild is not mistaken for an xfs one.
> 

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Carlos Maiolino]

On Sat, Sep 26, 2026 at 07:32:27AM -0500, Steve Shoecraft wrote:
> 
> Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.
> 
> I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.
> 
> Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.
> 
> Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.

If you are not even bothering reviewing your own project source code as
you stated, don't expect anybody else to spend their time or have
interest on it.


> 
> 
> > On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > I don't think too many people are going to care about your LLM dump,
> > or even review it.  But please make sure you use different magic numbers
> > so that a mxfs image left in the wild is not mistaken for an xfs one.

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Steve Shoecraft]

I’m disappointed in your responses. I would have thought that you’d at least be interested in how well the AI did.

It’s going to get better — not worse.

Since the initial 2-node TCP/DLM release (0.89.77 on September 23), Fable and Astra have completed 2-node CAW (0.90.7 on September 26), and 4-node TCP and CAW (0.90.24) have now been released on:
• Proxmox VE 9 (kernels 6.17 and 7.0)
• RHEL / AlmaLinux / Rocky 9.8
• Ubuntu 24.04 LTS (GA kernel 6.8)
• Debian 13 (kernel 6.12)

All are distributed as native DEB/RPM packages, with the kernel module built against the target kernel via DKMS.

The 0.90.24 release passed the complete release criteria: 4-node TCP 31/31, 4-node CAW 30/30, 2-node TCP 31/31, and 2-node CAW 30/30. All four platforms passed their packaged installation and validation runs.

The goal is full 32-node support for both TCP and CAW DLM.



The next project is OSN — a fully AI-written OS from scratch.


> On Sep 27, 2026, at 7:03 AM, Carlos Maiolino <cem@kernel.org> wrote:
> 
> On Sat, Sep 26, 2026 at 07:32:27AM -0500, Steve Shoecraft wrote:
>> 
>> Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.
>> 
>> I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.
>> 
>> Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.
>> 
>> Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.
> 
> If you are not even bothering reviewing your own project source code as
> you stated, don't expect anybody else to spend their time or have
> interest on it.
> 
> 
>> 
>> 
>>> On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
>>> 
>>> I don't think too many people are going to care about your LLM dump,
>>> or even review it.  But please make sure you use different magic numbers
>>> so that a mxfs image left in the wild is not mistaken for an xfs one.

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Darrick J. Wong]

On Tue, Sep 29, 2026 at 09:19:39AM -0400, Steve Shoecraft wrote:
> I’m disappointed in your responses. I would have thought that you’d at
> least be interested in how well the AI did.

And I'm disappointed every time someone unfamiliar to the (xfs)
community appears out of nowhere with a giant pile of code (LLM
generated or otherwise) and a request that we read it.

If you want people to review your code, start by watching the mailing
list for a month or two to familiarize yourself with community norms,
and to ask questions when others post patches.

> It’s going to get better — not worse.
> 
> Since the initial 2-node TCP/DLM release (0.89.77 on September 23), Fable and Astra have completed 2-node CAW (0.90.7 on September 26), and 4-node TCP and CAW (0.90.24) have now been released on:
> • Proxmox VE 9 (kernels 6.17 and 7.0)
> • RHEL / AlmaLinux / Rocky 9.8
> • Ubuntu 24.04 LTS (GA kernel 6.8)
> • Debian 13 (kernel 6.12)
> 
> All are distributed as native DEB/RPM packages, with the kernel module built against the target kernel via DKMS.
> 
> The 0.90.24 release passed the complete release criteria: 4-node TCP 31/31, 4-node CAW 30/30, 2-node TCP 31/31, and 2-node CAW 30/30. All four platforms passed their packaged installation and validation runs.
> 
> The goal is full 32-node support for both TCP and CAW DLM.
> 
> 
> 
> The next project is OSN — a fully AI-written OS from scratch.

Good luck with that when you can't even be bothered to llmcode a test
to make sure the magic numbers do not match standard xfs.

--D

> > On Sep 27, 2026, at 7:03 AM, Carlos Maiolino <cem@kernel.org> wrote:
> > 
> > On Sat, Sep 26, 2026 at 07:32:27AM -0500, Steve Shoecraft wrote:
> >> 
> >> Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.
> >> 
> >> I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.
> >> 
> >> Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.
> >> 
> >> Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.
> > 
> > If you are not even bothering reviewing your own project source code as
> > you stated, don't expect anybody else to spend their time or have
> > interest on it.
> > 
> > 
> >> 
> >> 
> >>> On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >>> 
> >>> I don't think too many people are going to care about your LLM dump,
> >>> or even review it.  But please make sure you use different magic numbers
> >>> so that a mxfs image left in the wild is not mistaken for an xfs one.
> 
> 

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Steve Shoecraft]

All good points and a nice snarky comment at the end - was a definite oversight that has been rectified.


> On Sep 29, 2026, at 11:00 AM, Darrick J. Wong <djwong@kernel.org> wrote:
> 
> On Tue, Sep 29, 2026 at 09:19:39AM -0400, Steve Shoecraft wrote:
>> I’m disappointed in your responses. I would have thought that you’d at
>> least be interested in how well the AI did.
> 
> And I'm disappointed every time someone unfamiliar to the (xfs)
> community appears out of nowhere with a giant pile of code (LLM
> generated or otherwise) and a request that we read it.
> 
> If you want people to review your code, start by watching the mailing
> list for a month or two to familiarize yourself with community norms,
> and to ask questions when others post patches.
> 
>> It’s going to get better — not worse.
>> 
>> Since the initial 2-node TCP/DLM release (0.89.77 on September 23), Fable and Astra have completed 2-node CAW (0.90.7 on September 26), and 4-node TCP and CAW (0.90.24) have now been released on:
>> • Proxmox VE 9 (kernels 6.17 and 7.0)
>> • RHEL / AlmaLinux / Rocky 9.8
>> • Ubuntu 24.04 LTS (GA kernel 6.8)
>> • Debian 13 (kernel 6.12)
>> 
>> All are distributed as native DEB/RPM packages, with the kernel module built against the target kernel via DKMS.
>> 
>> The 0.90.24 release passed the complete release criteria: 4-node TCP 31/31, 4-node CAW 30/30, 2-node TCP 31/31, and 2-node CAW 30/30. All four platforms passed their packaged installation and validation runs.
>> 
>> The goal is full 32-node support for both TCP and CAW DLM.
>> 
>> 
>> 
>> The next project is OSN — a fully AI-written OS from scratch.
> 
> Good luck with that when you can't even be bothered to llmcode a test
> to make sure the magic numbers do not match standard xfs.
> 
> --D
> 
>>> On Sep 27, 2026, at 7:03 AM, Carlos Maiolino <cem@kernel.org> wrote:
>>> 
>>> On Sat, Sep 26, 2026 at 07:32:27AM -0500, Steve Shoecraft wrote:
>>>> 
>>>> Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.
>>>> 
>>>> I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.
>>>> 
>>>> Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.
>>>> 
>>>> Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.
>>> 
>>> If you are not even bothering reviewing your own project source code as
>>> you stated, don't expect anybody else to spend their time or have
>>> interest on it.
>>> 
>>> 
>>>> 
>>>> 
>>>>> On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
>>>>> 
>>>>> I don't think too many people are going to care about your LLM dump,
>>>>> or even review it.  But please make sure you use different magic numbers
>>>>> so that a mxfs image left in the wild is not mistaken for an xfs one.

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Eric Sandeen]

On 9/29/26 8:19 AM, Steve Shoecraft wrote:
> I’m disappointed in your responses. I would have thought that you’d at least be interested in how well the AI did.
Not trying to pile on here, but still echoing the other "disappointing"
responses:

This developer community, like many others, is already oversubscribed.
This was true before the LLM onslaught, it is /far/ worse after it.

Review has been a community bottleneck here for /years/ - for the actual,
shipping XFS project code.

We've been victims of turn-the-crank work generation for a long time, whether
it's running xfstests and throwing un-triaged failures over the wall, or
fsfuzzer,  husyzkaller, now AI-found flaws and exploits, etc. Generating work
for humans is getting easier and easier, and the human workforce is not growing.

(FWIW, many of us do use LLMs as a force multiplier, both for coding and for
code review. It's still a struggle.)

I ran cloc on your repo:

github.com/AlDanial/cloc v 2.10  T=1.87 s (1565.8 files/s, 466746.3 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
C                               306          39193         121404         284212
Markdown                       1195          22872            715         143738
Bourne Shell                   1046           6436          42299          82939
C/C++ Header                    222           5834          23461          37391
JSON                             34              0              0          32925
Python                          103           2306           3392          15533
Text                              6             85              0           6819
make                              9            102             45            424
Perl                              1             53             20            190
Bourne Again Shell                3             16             84            152
JavaScript                        1             10             13             72
Expect                            1              4              7             30
Snakemake                         1              0              5              1
--------------------------------------------------------------------------------
SUM:                           2928          76911         191445         604426
--------------------------------------------------------------------------------

a quarter million lines of C, never mind the rest.

Your project sounds interesting, but the humans here are not going to be a
review workforce for it.

I'd suggest that maybe you continue your AI-only approach, and continue using
AI to design a comprehensive test suite as well, and let any potential users know
that it's AI-turtles all the way down. If they trust it enough to use it, and
it works without eating anyone's data, then your AI-only experiment might just
be a success.

And if it's not a success, thank you for changing the magic number. ;)

-Eric

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Carlos Maiolino]

On Tue, Sep 29, 2026 at 09:19:39AM -0400, Steve Shoecraft wrote:
> I’m disappointed in your responses. I would have thought that you’d at least be interested in how well the AI did.

And I'm disappointed how you didn't get the point you should not demand
others to validate code you didn't bother reading yourself.

> 
> It’s going to get better — not worse.
> 
> Since the initial 2-node TCP/DLM release (0.89.77 on September 23), Fable and Astra have completed 2-node CAW (0.90.7 on September 26), and 4-node TCP and CAW (0.90.24) have now been released on:
> • Proxmox VE 9 (kernels 6.17 and 7.0)
> • RHEL / AlmaLinux / Rocky 9.8
> • Ubuntu 24.04 LTS (GA kernel 6.8)
> • Debian 13 (kernel 6.12)
> 
> All are distributed as native DEB/RPM packages, with the kernel module built against the target kernel via DKMS.
> 
> The 0.90.24 release passed the complete release criteria: 4-node TCP 31/31, 4-node CAW 30/30, 2-node TCP 31/31, and 2-node CAW 30/30. All four platforms passed their packaged installation and validation runs.
> 
> The goal is full 32-node support for both TCP and CAW DLM.
> 
> 
> 
> The next project is OSN — a fully AI-written OS from scratch.
> 
> 
> > On Sep 27, 2026, at 7:03 AM, Carlos Maiolino <cem@kernel.org> wrote:
> > 
> > On Sat, Sep 26, 2026 at 07:32:27AM -0500, Steve Shoecraft wrote:
> >> 
> >> Good catch on the magic - I had it changed in previous attempts and forgot on this one - release 0.90.0 has MXFS unique magic.
> >> 
> >> I’ve been writing device drivers since the 90s on FreeBSD.  This was a research project to see if an LLM could do it with the right harness.
> >> 
> >> Release conditions of course included 100% data integrity and 100% stability.   XFS was the right choice for the base.
> >> 
> >> Intent is a good clustered FS for Proxmox to compete with vSphere and VMFS.  Yes, I’m aware of the differences in implementations.
> > 
> > If you are not even bothering reviewing your own project source code as
> > you stated, don't expect anybody else to spend their time or have
> > interest on it.
> > 
> > 
> >> 
> >> 
> >>> On Sep 26, 2026, at 1:07 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >>> 
> >>> I don't think too many people are going to care about your LLM dump,
> >>> or even review it.  But please make sure you use different magic numbers
> >>> so that a mxfs image left in the wild is not mistaken for an xfs one.
> 
> 

Re: [RFC] MXFS: a shared-disk clustered filesystem derived from XFS

[Emmanuel Florac]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Le Sat, 26 Sep 2026 07:32:27 -0500
Steve Shoecraft <spshoecraft@gmail.com> écrivait:

> Intent is a good clustered FS for Proxmox to compete with vSphere and
> VMFS.  Yes, I’m aware of the differences in implementations.
> 

What's wrong with OCFS2 and other already existing numerous cluster
filesystems?

-- 
------------------------------------------------------------------------
   Emmanuel Florac     |   Direction technique
------------------------------------------------------------------------
   https://intellique.com
   +33 6 16 30 15 95
------------------------------------------------------------------------
 

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]