CetraFS: ein VMFS-Prinzip für Proxmox, am Code gelesen

Innerhalb einer Woche sind zwei Projekte aufgetaucht, die dasselbe Ziel haben: das VMFS-Prinzip von VMware auf Proxmox bringen, also mehrere Knoten, die sich eine gemeinsame Platte teilen und die VM-Images direkt darauf ablegen. Am 24. Oktober hat Virtualization Howto beide in einem Beitrag vorgestellt: MeshXFS, über das wir am 21. Oktober geschrieben haben, und das neue CetraFS. Der MeshXFS-Beitrag ging um die Sperrschicht auf XFS; hier geht es um CetraFS, ein eigenes Format mit SCSI-Sperren auf dem LUN. Wir lesen es im Repository nach und prüfen, ob es zu unserem Storage passt.

CetraFS ist ein Dateisystem für gemeinsam genutzten Blockspeicher: Mehrere Linux- oder Proxmox-Knoten mounten dieselbe iSCSI- oder Fibre-Channel-LUN gleichzeitig und legen VM-Images direkt darauf ab. Die Knoten koordinieren sich über atomare SCSI-Befehle (COMPARE AND WRITE) auf dem Laufwerk selbst, ohne Netzwerkprotokoll im Datenpfad. Das Projekt versteht sich als offene Alternative zu VMFS und nennt sich Beta, also vor Version 1.0.

Aktualisiert am 5. November 2026. Seit der ersten Fassung vom 25. Oktober hat das Projekt fünf Releases veröffentlicht (0.8.2 bis 0.9.3, zuletzt am 2. November). Versionsnummer, Plattenformat, Testumfang und Reifegrad-Einstufung sind gegen die heutige Statusseite nachgezogen. Die Messungen an unserem Cluster stammen unverändert vom 25. Oktober.

Auf einen Blick

Zahlen aus dem Projekt sind Herstellerangaben, die wir nicht nachgemessen haben. Die letzte Zeile ist unsere eigene Messung.

Wie CetraFS die Knoten koordiniert

CetraFS setzt auf einen einzigen Mechanismus. Alle strittigen Entscheidungen laufen über SCSI COMPARE AND WRITE, einen atomaren Vergleichs-und-Tausch-Befehl auf einem 512-Byte-Datensatz direkt auf dem Laufwerk: welche Zone ein Knoten belegen darf, wer eine Datei offen hält, wem ein Eintrag im Knotenregister gehört. Das README vergleicht das mit dem ATS-Prinzip von VMFS ("the same idea as VMFS's ATS"). Ein verteilter Lock Manager, Corosync und ein zweites Netzwerk sind im Datenpfad nicht nötig. Die Liveness der Knoten läuft über einen Heartbeat im Abstand von 15 Sekunden mit einem Stale-Fenster danach.

An diesem Fenster sieht man, dass der Autor an echter Hardware gebaut hat. Der Kommentar in include/cetrafs.h hält fest, dass die frühere Einstellung von vier Takten, also 60 Sekunden, bei echtem Multipath-Speicher falsch war; der Standard sind jetzt acht Takte, also 120 Sekunden. Der Grund steht in README und Header: Wenn bei einem Multipath-Aufbau alle Pfade ausfallen, hält dm-multipath die Ein- und Ausgabe für no_path_retry mal Abfragetakt in der Warteschlange, statt sie sofort mit einem Fehler zurückzugeben, bei der Standardeinstellung für eine HPE 3PAR 90 Sekunden. In dieser Zeit kann der Knoten auch seinen Heartbeat nicht erneuern. Wäre das Stale-Fenster kürzer, erklärten die Nachbarn den Knoten für tot und übernähmen seine Zonen, während seine Schreibvorgänge noch in der Warteschlange hängen; diese landeten danach auf fremdem Gebiet. 120 Sekunden überstehen die 90. Der Wert lässt sich zwischen 15 und 240 Sekunden einstellen, mindestens aber auf drei Heartbeat-Takte.

Was im Repo steht, neben der Idee

Das öffentliche Repo cetrafs/cetrafs wurde laut GitHub-API am 22. Oktober 2026 um 12:24 UTC angelegt. Die Release 0.8.1 mit den Debian-Paketen (cetrafs-dkms, cetrafs-tools) erschien am selben Tag um 17:33 UTC. Es folgten 0.8.2 am 26. Oktober, 0.9 und 0.9.1 am 29. Oktober, 0.9.2 am 1. November und 0.9.3 am 2. November. Autor ist Massimo Cetra (GitHub-Konto ctrix, seit 2011 registriert, Blog ctrix.it). Die Releasenotes nennen inzwischen Mitwirkende von außen: Das meiste in 0.9.2 geht laut Releasenotes auf eine Durchsicht des gesamten Codes durch Matteo Croce zurück. Das Proxmox-Plugin pve-storage-cetrafs liegt in einem eigenen Repo. Ein Repo dieser Altersklasse ist ein Standbild. Der Autor schreibt laut der Wiedergabe bei Virtualization Howto, die Architektur des Dateisystems sei vor den heutigen KI-Coding-Werkzeugen entstanden, KI-Assistenz habe er bei späterer Entwicklung, Debugging und Tests eingesetzt. Den Reddit-Beitrag selbst konnten wir nicht abrufen (Bot-Sperre), deshalb zitieren wir nur diese Wiedergabe. Bei MeshXFS beschreibt der Autor dagegen die KI-Agenten-Schleife als Herkunft des Codes.

Die Lizenz steht in der LICENSE-Datei, auch wenn GitHub oben "NOASSERTION" anzeigt, und sie ist zweigeteilt. Das Kernelmodul unter kmod/ ist GPL-2.0-or-later, ohne kommerzielle Variante; "none can be offered" steht dort wörtlich. Die Werkzeuge unter userspace/ stehen unter AGPL-3.0-or-later oder einer kommerziellen Lizenz, die das Projekt für alle anbietet, denen die AGPL-Pflicht zur Quellcode-Offenlegung nicht passt. Welche Variante für Ihren Einsatz gilt, klärt im Zweifel ein Anwalt; dieser Beitrag gibt keine Rechtsauskunft.

An zwei Stellen sagt das Projekt selbst, wo die Sorgfalt endet. Das README hält fest, dass die Paketierung make check beim Paketbau auslässt: "a built package is not a tested one". Die Plugin-Readme schreibt, dass der CI-Bau das Paket im nocheck-Profil erzeugt und die Tests nicht ausführt.

Wie gereift das Projekt ist

Die Statusseite (Stand 2. November 2026) führt als Verifikationsstufen auf: 243 Suiten mit 2.257 Assertions auf Schleifengeräten, eine Crash-Konsistenz-Anlage (dm-log-writes, dm-flakey, Stromverlust ohne vorherigen Flush), Fuzzing der Mount- und fsck-Parser, Dauertests und eine Mehrknoten-Suite gegen ein echtes gemeinsames LUN. Deren erster vollständig grüner Lauf lief auf einem Drei-Knoten-Cluster mit arm64-Proxmox an einer HPE 3PAR über 32-Gb-Fibre-Channel-Multipath, ein zweiter mit Version 0.7.4 auf einem Drei-Knoten-Cluster amd64 an einem handelsüblichen iSCSI-LUN: 27 Szenarien, dreimal hintereinander bestanden. Die Seite schränkt selbst ein: Es gibt Testevidenz, aber noch keine Jahre im Produktivbetrieb, und manche Wettlauf-Szenarien seien auf echter Hardware erst wenige Male gelaufen.

Die Schleifentests simulieren Mehrknoten-Fälle nur. Laut README prüft allein die Suite ctest/ die Pfade zwischen Knoten auf einem echten LUN; die Datei docs/PERFORMANCE.md sagt über make check: "proves correctness; it cannot prove speed". Die Durchsatzzahlen der Projektseite sind Herstellerangaben: 613 bis 710 MB/s O_DIRECT-Schreibdurchsatz auf einer 3PAR-LUN, laut Projekt rund das 2,3-Fache von GFS2 auf derselben Platte. Nachgemessen haben wir sie nicht.

Das Plattenformat ist das größte Warnschild. Die Version 0.8.1 trug das Format 0x0008, die aktuelle 0.9.3 trägt 0x0009. Ab 0.9.2 mountet CetraFS das alte Format 0x0008 nicht mehr: Ein solches Volume muss erst mit 0.9.1 gewachsen oder neu formatiert werden. Eine Migration an Ort und Stelle gibt es nicht, ein Formatwechsel heißt Daten räumen, neu formatieren, zurückspielen. Beim Reifegrad hat das Projekt nachgezogen: Die Release 0.8.1 nannte sich noch Alpha, Projektseite und Statusseite nennen sich heute Beta.

Der Vergleich mit MeshXFS

Beide Projekte füllen dieselbe Lücke mit entgegengesetztem Ansatz. MeshXFS erweitert XFS um eine Sperrschicht, die wahlweise über TCP, über SCSI-Befehle oder über DRBD-Status läuft. Es bietet damit als einziges der beiden einen dokumentierten Pfad für Paare mit DRBD im Dual-Primary-Betrieb, gebaut für DRBD 8.4 und höchstens zwei Knoten. CetraFS baut ein eigenes Format nur für VM-Speicher und kennt nur SCSI COMPARE AND WRITE auf dem LUN. Der vergleichbare NVMe-Befehl ist laut Statusseite nicht angebunden, ein NVMe-Gerät ist deshalb nur für einen Knoten nutzbar. Für Mehrknoten-Betrieb in Produktion verlangt CetraFS einen externen Cluster-Manager mit Host-Isolation (STONITH) und sieht das nicht als seine Aufgabe. Reifegrad beider: vor 1.0. MeshXFS legt seine Fehlerliste als Datei offen (data/defects.json); CetraFS setzt auf die Statusseite, den Reformat-Hinweis und den Rat zu unabhängigen Backups. Bei MeshXFS wurde zudem v0.90.131 nach der Veröffentlichung zurückgezogen, weil ein Fehler in den Metadaten auf der Platte gefunden worden war; v0.90.132 vom 21. Oktober ist die korrigierte Fassung mit Unterstützung für Proxmox VE 9.2 (Release-Seite).

Passt das in unsere Cluster

Eigene Messung vom 25. Oktober 2026, lesend vom Admin-Relay aus gegen den LINSTOR-Controller: sieben Speicherknoten online, 97 Ressourcen, Storage-Pools vom Typ LVM Thin plus disklose Anbindungen. Das Bild an den Knoten ist dasselbe wie am 21. Oktober: kein SAN-Target, keine iSCSI-Präsentation an mehrere Knoten, Replikation über LINSTOR mit DRBD im Protokoll C. Ein geteiltes SCSI-LUN, auf dem die CAW-Probe überhaupt ansetzen könnte, existiert bei uns nicht.

Dazu kommt die Versionsfrage, die wir am 25. Oktober gemessen haben: Alle sieben Knoten laufen auf Kernel 7.0.2-6-pve bei pve-manager 9.2.21. CetraFS führt 7.0.14 und "Proxmox VE 7.0.14-*-pve" als unterstützt an. Die Statusseite sagt, andere Kernel seien unverifiziert und könnten beim Bau oder Laden scheitern. Und die Zaun-Komponente, die das Projekt für mehrere Knoten verlangt, haben wir in dieser Form nicht: Der LINSTOR-Tiebreaker entscheidet Quorumfragen der Replikation und schaltet keine Hosts ab.

Unsere Einordnung wie bei MeshXFS: beobachten, nicht in einen laufenden Cluster einbauen. Die Voraussetzungen, die das Projekt selbst nennt, passen zu einem echten SAN-Projekt. Wer keines hat, kann das Dateisystem nicht einmal probehalber mit zwei Knoten mounten. Drei Punkte entscheiden, ob ein Test lohnt: ob ein Build für die eigene Kernel-Familie bestätigt ist, ob die Mehrknoten-Evidenz von handelsüblichen iSCSI-Zielen über den einen Testlauf mit 0.7.4 hinauskommt, und ob Proxmox selbst die Lücke schließt. Die letzte Frage stellt Virtualization Howto am 24. Oktober; das ist eine Stimme aus der Community, keine Aussage von Proxmox. Wer ein SAN hat, misst zuerst die CAW-Probe aus der Projektdokumentation auf dem Array, bevor irgendein Knoten das Modul sieht. Eine Einordnung der Speicherwege für Ihre Umgebung finden Sie unter IT-Betrieb und Infrastruktur, weitere Storage-Beiträge im Hub Storage, Backup und Replikation.

Weiterführende Quellen

• CetraFS-Repo, gelesen am 05.11.2026: LICENSE mit der Aufteilung GPL/AGPL-kommerziell, include/cetrafs.h mit Heartbeat- und Stale-Fenster-Werten, docs/TESTING.md mit dem Schichten-Testplan
• Release 0.8.1, veröffentlicht 22.10.2026 17:33 UTC, mit Installationshinweis und Alpha-Hinweis
• Projektseite und Statusseite mit Plattform-Matrix, Verifikationsliste und Ausschlussliste
• Proxmox-Plugin-Repo (pve-storage-cetrafs)
• Reddit r/ProxmoxVE: Beitrag des Projektautors, von uns nicht abrufbar (Bot-Sperre), nur über die Wiedergabe bei Virtualization Howto verwendet
• Virtualization Howto, Beitrag vom 24.10.2026 mit dem Vergleich beider Projekte und der Wiedergabe der Reddit-Diskussion
• MeshXFS-Releases: v0.90.132 vom 21.10.2026 mit Proxmox-VE-9.2-Unterstützung, v0.90.131 zurückgezogen