MeshXFS: ein clusterfähiges XFS für Proxmox, geschrieben von einer KI-Agenten-Schleife

Seit dem 16. Oktober 2026 gibt es auf GitHub ein erstes öffentliches Release von MeshXFS: ein Dateisystem, das die XFS-Struktur auf einer gemeinsamen Blockressource von mehreren Proxmox-Knoten aus gleichzeitig beschrieben wird, samt eigener Sperrverwaltung im Cluster. Der Autor Stephen P. Shoecraft beschreibt das Projekt als Arbeit einer KI-Agenten-Schleife. Die Idee trifft einen bekannten Punkt: Ohne geteilten Storage gibt es keine Live-Migration, und geteilte Speicher sind das Teuerste an einer Proxmox-Umgebung. Das Projekt haben wir eine Woche verfolgt und zwei Fragen geprüft: Was sagt die Herstellungsqualität, und passt das in unsere Cluster?

Was das Projekt ist

MeshXFS ist ein Fork des XFS aus Linux 6.19 mit eigener Sperrschicht. Die Plattenstruktur bleibt dabei unverändert. Ein Knoten sperrt Bereiche der Metadaten, die anderen Knoten fragen diese Sperren über einen Verteiler ab, der wahlweise über TCP, über SCSI-Befehle auf der gemeinsamen Platte oder über den DRBD-Status läuft. Ausgeliefert wird ein DKMS-Paket: Es baut das Kernelmodul mxfs.ko und bringt mkfs.mxfs, chk_mxfs, resize_mxfs und mxfs_admin mit. Die Lizenz ist GPL-2.0-only, die Datei liegt im Repo und trägt den Namen des Autors.

Das Repository existiert seit dem 20. Juli 2026 und zählt 96 Commits von genau einem Contributor. Pull Requests gab es bisher null, bei 42 Sternen. Zwischen dem 23. September und dem 16. Oktober liegen 19 veröffentlichte Versionen, zuletzt v0.90.130. Einen Teil der Baustelle sieht man im Repo selbst: Ein Ordner für Agenten-Kontext, eine CLAUDE.md mit 25 kB, ein Runskript mit 157 kB und eine Statusdatei mit 76 kB gehören zum Arbeitszweig.

Zwei Sätze aus dem README gehören in jede Abwägung hinein. Der erste: Kein Release sei auf einem Storage-Array geprüft, die Tests liefen auf QEMU-KVM. Der zweite steht im selben Abschnitt und schränkt die Hardwaremessung ein: Als einziger echter Hardwaretest gilt ein Zwei-Knoten-Aufbau mit DRBD an zwei physischen Proxmox-9-Hosts, Stand Version 0.90.107. Die Attach-Variante drbd ist dabei auf DRBD 8.4 gebaut und auf zwei Knoten begrenzt.

Die Release-Seite bremst selbst

Am 16. Oktober um 12:37 UTC ist v0.90.130 veröffentlicht worden. Am 20. Oktober um 00:33 UTC hat der Autor den Text dieser Seite überschrieben, und zwar mit einem Warnhinweis: Die Tests der nächsten Version hätten drei Defekte in Konfigurationen gefunden, die diese Release-Version abdeckt. Wörtlich steht dort, man solle MeshXFS auf Testdaten beschränken, Backups führen und nach jedem Testlauf chk_mxfs -v auf das Device ansetzen, solange es auf keinem Knoten mehr eingebunden ist.

Die drei genannten Fehler sind keine Randnotizen. Einer fährt nach dem Zäunen und Wiederkommen eines Knotens das Dateisystem herunter, einer erzeugt im Acht-Knoten-Aufbau mit Pfad-Multipath einen Dateinamen, den zwei Verzeichniseinträge besitzen, während die Verlinkungszahl eins bleibt. Der dritte fährt das Dateisystem rund 16 Sekunden nachdem ein eingefrorener Knoten nicht mehr antwortet herunter, während ein Anlegevorgang läuft. Die letzten beiden Punkte liegen außerhalb der Konfiguration, mit der das Projekt misst: gemessen wird an zwei Knoten mit Multipath und etwa 40 000 Dateien.

Die zeitliche Nähe ist der eigentliche Befund. Um 09:48 UTC stand im Repo noch ein Hinweis, der 0.90.131 für Tests festschrieb. Um 00:33 UTC desselben Tages war er auf 0.90.130 umgezogen und um das Advisory reicher. Unveröffentlichte Versionen werden also gebaut und wieder zurückgezogen, bevor sie öffentlich sind.

Die Defect-Datei im Hauptzweig

Im Hauptzweig liegt data/defects.json, eine maschinenlesbare Liste aller bekannten Defekte mit Schwere, betroffenen Konfigurationen und Mechanismus. Wir haben die Datei am 20. Oktober gelesen: 129 Einträge, davon 46 critical, 42 major, 27 high, 9 minor und 5 medium. Neun Einträge sind am 20. Oktober eröffnet worden, sechs davon critical.

Drei dieser sechs kritischen Einträge tragen die Versionsangabe 0.90.131, also die noch unveröffentlichte Fassung. Sie sind Regressionsfunde der laufenden Arbeit und ein Argument für die Prüfschleife, die sie gefunden hat. Die anderen drei tragen keine Versionsgrenze und gelten damit für jede Konfiguration: zwei Beschreibungen eines fehlgeschlagenen Mounts, der hängenbleibt, eine Notiz über uninitialisierte Nacharbeit, die während eines langsamen Mounts eingereiht wird. Die Befundklasse ist uns nicht fremd, sie steht auf unserer eigenen Storage-Liste ganz oben: Wir betreiben auf unseren Knoten noch den Zustand on-no-quorum io-error statt suspend-io, also genau die Kategorie "Reaktion auf einen weggebrochenen Knoten".

Daneben stehen die Performancezahlen des Projekts: 997 Prozent beim zufälligen Lesen und 356 Prozent beim sequenziellen Schreiben gegenüber nativem XFS. Sie stammen aus dem Projekt selbst, gemessen auf QEMU-KVM, an vier Knoten, ohne Array, mit Läufen von dreißig Sekunden Länge als längster Stufe. Gegen XFS zu gewinnen ist auf einer virtuellen Platte keine Überraschung, weil XFS auf Shared-Storage ohnehin nicht für diese Zugriffsform gebaut ist.

Die Gegenrechnung liefert an diesem Tag die Linux Foundation selbst. Ihre am 20. Oktober vorgestellte Studie zu generativer KI in der Open-Source-Entwicklung schätzt 25 Prozent der eingehenden Pull Requests auf Open-Source-Projekte als niedrige Qualität ein, bei großen Projekten 31 Prozent, und lässt sie von den Maintainern selbst schätzen. MeshXFS entzieht sich dieser Zählweise: Dort gibt es keine eingehenden Anträge, die man als Slop einstufen könnte. Der Engpass liegt darin, dass es diese Beiträge gar nicht gibt. Ein Reviewer von außen fehlt, weil der Prozess ihn nicht vorsieht.

Passt das in unsere Cluster

Unsere Frage war die Geschwindigkeit gegen XFS auf einer virtuellen Platte nicht. Wir wollten wissen, ob es in unsere Umgebung passt. Am 20. Oktober haben wir über die Proxmox-API die Storage-Liste eines unserer sechs Knoten gelesen: ein lokales Verzeichnis, nicht geteilt, zwei DRBD-Ressourcen für Betriebssystem- und SQL-Platten, dazu drei Backup-Server als Store. NFS, CIFS oder ein SAN-Target sind nicht vorhanden. Repliziert wird über LINSTOR mit DRBD in Protokoll C über zwei gebündelte 100-Gigabit-Strecken; der Bestand sind knapp 60 TiB Rohkapazität, wovon nach Spiegelhälfte und Vertrauenszuschlag rund 30 TiB nutzbar sind, belegt mit knapp 12,5 TiB.

Genau hier trennt sich MeshXFS von uns. Es braucht einen Blockspeicher, den mehrere Knoten gleichzeitig sehen. Diesen Pfad haben wir nicht; er wäre ein zweites Speicher-Setup neben dem bestehenden. Der attach-Typ drbd wäre der Weg, der zu uns passen würde: Er setzt DRBD 8.4 voraus und endet bei zwei Knoten. Unser Bestand sind sechs Knoten in zwei Rechenzentren.

Ein Anwenderbericht aus dem Issue-Tracker zeigt, was an dieser Naht passiert. Ein Nutzer hat am 20. Oktober ein Zwei-Knoten-Setup mit DRBD 8.4.11, Pacemaker und IPMI-Zaunbeschreibung beschrieben. Nach einem erzwungenen Neustart kehrt der Mount nicht zurück: DRBD meldet die Platte als inkonsistent, die eingebaute Zwei-Knoten-Autorität verweigert das Abschalten des Nachbarn, die Initialisierung der Sperrschicht schlägt fehl. Dazu passt die Meldung aus derselben Sitzung, DRBD 9 werde abgelehnt, weil das Replikationsprotokoll nicht C sei. Ein zweiter Bericht vom selben Tag, das gemountete Verzeichnis sei nach dem Herunterfahren eines Knotens leer, war beim Lesen unbeantwortet. Der Proxmox-Thread vom 16. Oktober, den der Maintainer selbst eröffnet hat, um Tester zu suchen, hat bisher keine Antwort von Proxmox-Mitarbeitenden.

Unsere Einordnung ist WATCH. Wir nehmen es nicht in einen Cluster auf und bauen keinen Testaufbau dafür: Die Voraussetzung fehlt, und die Release-Seite rät selbst zu Testdaten und Backups. Beobachten wir drei Dinge. Die beantworteten Issues, denn an Recovery nach Zaun und Neustart entscheidet sich, ob ein Cluster-Dateisystem in unserem HA-Verbund taugt. Einen Attach-Pfad für DRBD 9 oder für mehrere Knoten. Und ob die Ankündigung eines Vergleichslaufs mit anderen Cluster-Dateisystemen kommt, dann messen wir gegen diese Zahlen statt gegen die eigenen.

Weiterführende Quellen

• MeshXFS-Repository auf GitHub, ausgelesen am 20.10.2026: README mit Array- und KVM-Einschränkung, data/defects.json mit 129 Einträgen, LICENSE als GPL-2.0-only
• Release v0.90.130, veröffentlicht 16.10.2026 12:37 UTC, Text zuletzt bearbeitet 20.10.2026 00:33 UTC, mit Advisory und den drei Defektbeschreibungen
• Issue #2: hängender Mount nach erzwungenem Neustart an DRBD 8.4.11, abgelehntes DRBD 9, offen und unbeantwortet am 20.10.2026. Issue #3: leeres Mount-Verzeichnis nach dem Herunterfahren eines Knotens, ebenfalls offen. Issue #1 beschreibt den 400-Fehler des Storage-Kommandos auf Proxmox 9.2.21
• Proxmox-Forum: Thread des Maintainers auf der Suche nach Testern vom 16.10.2026
• Blogbeitrag, der die Aufmerksamkeit brachte: Vorstellung des Dateisystems, Hinweis auf eigene Vergleichsmessungen in den nächsten Tagen
• Linux Foundation: Studie zu generativer KI in der Open-Source-Entwicklung vom 20.10.2026, mit den Anteilen zu Pull Requests und Beitragseingang