GlusterFS sollte tot sein. Dann hat es jemand zurück nach Proxmox gezerrt.

Das Feature, das verschwand, und die Leute, die nicht loslassen wollten

Es gibt eine bestimmte Art von Entfernung, die sich weniger wie Aufräumen anfühlt und mehr wie eine Tür, die einer ganzen Nutzergruppe vor der Nase zugeschlagen wird. Proxmox 9 hat GlusterFS als Storage-Typ gestrichen, und für alle, die es noch im Einsatz hatten, war das kein bloßer Eintrag im Changelog. Es war eine sehr klare Botschaft: Hier will die Plattform ihre Energie nicht mehr investieren. Der offizielle Weg war deutlich genug. Weiterziehen. Ceph nutzen. Etwas anderes nutzen. Aufhören, an einem Storage-Stack festzuhalten, den das weitere Ökosystem längst wie altes Kellermobiliar behandelt.

Aber Open-Source-Communities akzeptieren nicht immer die offizielle Stimmungslage. Ein Nutzer schrieb ein eigenes Storage-Plugin, um die GlusterFS-Funktionalität in Proxmox 9 wiederherzustellen, samt zusätzlicher Patches, um Teile wie pvesm scan und GUI-Unterstützung zurückzubringen. Das ist die Art von Sache, die Leute gleichzeitig jubeln und zusammenzucken lässt. Auf der einen Seite ist es genau der Grund, warum man diese Welt liebt: Ein Feature wird gestrichen, und jemand mit genug Verärgerung und Können sagt: "Gut, dann baue ich es eben selbst wieder ein." Auf der anderen Seite wirft es die unbequeme Frage auf, der niemand ewig ausweichen kann: Wenn eine Plattform die Unterstützung entfernt hat, weil die Upstream-Lage wackelig ist, löst die Wiederherstellung dann das Problem oder verschafft sie nur Zeit?

Diese Spannung zog sich durch die gesamte Diskussion. Manche waren dankbar. Manche waren skeptisch. Manche trauerten fast um GlusterFS wie um einen alten Freund, den man in der Öffentlichkeit nicht mehr so leicht verteidigen konnte. In dem Beitrag ging es nicht nur um ein Plugin. Es ging darum, was passiert, wenn eine Storage-Technologie für manche Nutzer noch funktioniert, noch emotionale Loyalität genießt, noch eine Nische füllt, aber nicht mehr sauber in die Enterprise-first-Roadmap des Hypervisors um sie herum passt.

Und das ist der eigentliche Stich. GlusterFS ist nicht verschwunden, weil es jeder Nutzer hasste. Es ist verschwunden, weil Support-Aufwand, Upstream-Dynamik, QEMU-Änderungen und Enterprise-Erwartungen allesamt in die falsche Richtung zeigten.

"Gepflegt" trägt hier eine Menge Gewicht

Der schärfste Streitpunkt drehte sich um ein einziges Wort: gepflegt. Dieses Wort klingt einfach, bis ein Storage-System davon abhängt. Ein Lager verwies darauf, dass GlusterFS End-of-Life sei oder zumindest nicht mehr in einer Weise gepflegt werde, die sie als bedeutsam ansahen. Die Warnung war unverblümt: Es wurde aus gutem Grund aus Proxmox entfernt, und man solle vorsichtig sein, bevor man etwas Wichtiges auf einem wiederbelebten Plugin aufbaut. Jemand sagte im Grunde, dass eine Handvoll Leute, die Code am Leben halten, nachdem die große Unterstützung durch ein Unternehmen weggefallen ist, nicht dasselbe sei wie ein gesundes, supportfähiges Projekt.

Diese Sichtweise ist hart, aber nicht irrational. Enterprise-Plattformen brauchen langweilige Abhängigkeiten. Sie brauchen Projekte mit aktivem Upstream, vorhersehbaren Fixes, klaren Release-Pfaden und genug Nutzung, um den Support-Aufwand zu rechtfertigen. Ein Storage-Plugin ist nicht nur eine Menüoption. Es betrifft VM-Disks, Migrationen, Backups, Scans, Provisioning und all die schrecklichen Randfälle, die erst auftauchen, wenn ein Kunde bereits verärgert ist. Aus dieser Perspektive war die Streichung von GlusterFS durch Proxmox kein Verrat. Es war Risikomanagement.

Die andere Seite widersprach. Der Ersteller argumentierte, GlusterFS werde noch immer gepflegt, nur langsamer, besonders nachdem sich Red Hat zurückgezogen hatte. Wichtiger noch: Er argumentierte, die Entfernung durch Proxmox sei falsch angelegt gewesen, weil der QEMU-Block-Treiber nur ein Teil dessen war, was das Storage-Plugin leistete. Selbst wenn QEMU seinen nativen Gluster-Treiber fallen ließ, konnten VMs weiterhin über GlusterFS via FUSE laufen, ungefähr nach demselben Muster wie bei Directory-Storage. Für Nutzer, die bereits in Gluster investiert hatten, zählt das. Sie baten Proxmox nicht darum, die Welt für immer zu forken. Sie wollten, dass die bestehende Storage-Integration dort nützlich bleibt, wo sie es noch sein kann.

Bei der Meinungsverschiedenheit ging es nicht wirklich darum, ob Code existiert. Es ging um Vertrauen. Ist ein Projekt "gepflegt", wenn ein paar Leute noch Fehler beheben? Ist es "tot", wenn große Anbieter ihre Aufmerksamkeit anderswohin verlagert haben, Nutzer es aber weiterhin betreiben können? Ist langsame Pflege für ein Homelab akzeptabel, aber inakzeptabel für Enterprise? Die Antwort hängt davon ab, wer ans Telefon gehen muss, wenn etwas kaputtgeht. Deshalb kann dasselbe Plugin für die eine Person heldenhaft wirken und für die andere leichtsinnig.

Hier existiert eine Art Open-Source-Fegefeuer. Nicht tot genug, um zu verschwinden. Nicht lebendig genug, um Vertrauen zu wecken. GlusterFS lebt jetzt in diesem seltsamen Zwischenraum, in dem treue Nutzer es am Laufen halten können, sich aber jedes Upgrade anfühlt wie die Frage, ob der Boden noch da ist.

Das Enterprise-Argument gegen Nostalgie

Das Enterprise-Argument kam klar durch: Proxmox ist eine Enterprise-first-Plattform, auch wenn es dank seiner Open-Source-Wurzeln eine riesige Fangemeinde außerhalb des Enterprise-Bereichs hat. Das bedeutet, das Projekt kann nicht jedes Feature am Leben erhalten, nur weil eine Teilmenge der Nutzer es weiterhin mag. Wenn Upstream-QEMU ein Verhalten fallen lässt, wenn das Gluster-Ökosystem nicht mehr gesund aussieht, wenn Enterprise-Support-Tickets keine ausreichende Nachfrage zeigen, dann wird es schwer zu rechtfertigen, GlusterFS innerhalb der offiziellen Plattform zu behalten.

Das ist emotional nicht befriedigend, aber so überleben Produkte. Storage zu unterstützen ist nicht wie das Unterstützen einer vergessenen Theme-Option. Storage-Bugs sind karrierebeendende Bugs. Ein instabiles Plugin kann Vertrauen schneller zerstören als fast alles andere in einem Virtualisierungs-Stack. Enterprise-Nutzer wollen Features, hinter die Anbieter stehen können, ohne von Patches, FUSE-Schichten und "na ja, technisch funktioniert es noch" zu murmeln. Wenn man Support verkauft, reicht "technisch" nicht aus.

Ein Kommentator verwies auf Proxmox' eigene erklärte Sichtweise, dass Enterprise-Support-Auswertungen keine ausreichende GlusterFS-Nutzung zeigten, um den Aufwand zu rechtfertigen. Das mag kalt klingen, erklärt aber vieles. Software-Projekte treffen Entscheidungen danach, wo ihre Nutzer stehen, wohin sich Upstream entwickelt und wo die Support-Kosten wahrscheinlich explodieren. In dieser Rechnung wurde GlusterFS zu einer schlechten Wette. Ceph, Object Storage und OpenStack-nahe Prioritäten gewannen das Rennen. GlusterFS wurde zur Antwort von gestern.

Es gab auch Vorwürfe in Richtung Red Hat und IBM, vorgebracht im bitteren Ton von Leuten, die sich noch erinnern, als GlusterFS zentraler wirkte. Eine Person sagte, IBM habe die Nutzer im Regen stehen lassen, als es den Stecker zog. Eine andere sagte, Red Hat habe schlicht die Richtung gewechselt, hin zu Object Storage und OpenStack. Wie man es auch dreht, das Gefühl bleibt gleich: eine Technologie, der Menschen vertrauten und die sie nutzten, verlor institutionelle Dynamik, und nachgelagerte Projekte reagierten entsprechend.

Das ist der Teil, den Nutzer am meisten hassen. Etwas kann noch nützlich sein und trotzdem von den Unternehmen fallen gelassen werden, die ihm einst Legitimität verliehen haben. Dann bleiben den Betreibern Skripte, Plugins, Forenthreads und eine Entscheidung: migrieren, bevor sich der Boden wieder verschiebt, oder weiter patchen, weil das aktuelle Setup noch seinen Zweck erfüllt.

Warum Menschen GlusterFS immer noch vermissen

Die Zuneigung zu GlusterFS war nicht eingebildet. Eine Person sagte, sie bevorzuge es gegenüber Ceph, weil Ceph mehr Overhead mit sich bringe, während man GlusterFS auf fast alles ansetzen könne und es einfach "alles klar" sage. Diese Zeile bringt den Reiz perfekt auf den Punkt. GlusterFS wirkte zugänglich. Es verlangte nicht dieselbe Art von sorgfältig dimensioniertem Cluster, schnellem Netzwerk, Laufwerksplanung und operativer Disziplin, die Ceph oft erfordert. Für kleinere Setups, Labore, ungewöhnliche Hardware und Leute, die verteilten Storage wollten, ohne eine ganze Kathedrale darum herum zu bauen, hatte GlusterFS Charme.

Ceph kann brillant sein, aber es ist nicht beiläufig. Es will ein echtes Design. Es will genug Nodes, genug Disks, genug Netzwerk und genug Wissen. GlusterFS wirkte, zumindest in seiner freundlichsten Form, nachsichtiger. Deshalb greifen Menschen immer noch danach. Nicht weil es jeden Benchmark gewinnt oder jede moderne Enterprise-Anforderung abhakt, sondern weil es bestimmte unordentliche Setups möglich machte, ohne von Nutzern zu verlangen, über Nacht zu Storage-Architekten zu werden.

Doch die Nostalgie kam mit Narben. Jemand, der GlusterFS einst liebte, sagte, diese Liebe habe beim Node-Ausfall geendet. Rebuilds waren das Problem. Ein anderer Nutzer sagte, er habe es mit einem dedizierten 10-Gbit/s-Netzwerk für die Kommunikation zwischen Nodes ausprobiert und trotzdem eine Performance unterhalb der Erwartungen vorgefunden. Er ließ es auch fallen, weil native Snapshots fehlten. Das sind keine kleinen Beschwerden. Performance, Rebuild-Verhalten und Snapshots sind keine dekorativen Features, wenn es um VM-Storage geht. Sie machen den Unterschied zwischen "das ist clever" und "das wird das Wochenende ruinieren".

Deshalb wurde aus der Diskussion keine simple Feier. GlusterFS hat Fans, aber selbst die Fans wissen, wo die blauen Flecken sitzen. Das Plugin stellt einen Weg für Leute wieder her, die es weiterhin wollen, aber es schreibt die Geschichte nicht um. Es macht Rebuilds nicht angenehm. Es fügt nicht magisch das operative Vertrauen zurück hinzu, das mit dem Wegfall des großen Anbieter-Supports verschwand. Es gibt Nutzern Kontrolle, was mächtig ist, aber Kontrolle ist nicht dasselbe wie Sicherheit.

Trotzdem ist etwas zutiefst nachvollziehbar daran, wenn Menschen sich weigern, ein Tool aufzugeben, nur weil es nicht mehr auf der geweihten Spur liegt. Infrastruktur ist voll von solchen Loyalitäten. Menschen nutzen weiterhin, was sie verstehen, was ins Budget passt, was frühere Katastrophen überlebt hat, oder was auf Hardware, über die Ceph nur die Nase rümpfen würde, einfach gut genug funktioniert. Manchmal ist das schlechtes Engineering. Manchmal ist es praktische Weisheit. Meistens ist es beides.

Ein Plugin kann ein Feature wiederbeleben, kein Ökosystem

Das eigene Plugin ist nützlich. Es ist beeindruckend. Es ist aber auch keine Zeitmaschine. Es kann die GlusterFS-Storage-Unterstützung innerhalb von Proxmox 9 wiederherstellen, Scans patchen und das GUI-Verhalten zurückbringen. Es kann Leuten das Leben erleichtern, die bereits aktualisiert haben oder aktualisieren wollen, ohne vorher ihren Storage-Stack herauszureißen. Für Community-Nutzer ist das ein echtes Geschenk. Es macht aus "geht nicht" ein "geht, mit Einschränkungen." In der Open-Source-Welt zählt das.

Aber die Einschränkungen sind die ganze Geschichte. Sobald der Support außerhalb der Hauptplattform liegt, werden Nutzer Teil des Support-Modells, ob es ihnen gefällt oder nicht. Jedes Proxmox-Update, jede QEMU-Änderung, jede GlusterFS-Eigenart, jedes FUSE-Verhalten, jeder seltsame Storage-Randfall wird zu etwas, das man im Auge behalten muss. Das Plugin mag heute stabil sein und morgen nerven, ohne dass die Person, die es geschrieben hat, dafür etwas kann. Das ist die Steuer, die man zahlt, wenn man ein Feature wiederherstellt, das die Plattform bewusst zurückgelassen hat.

Es gibt hier eigentlich drei Seiten. Die erste sagt, Proxmox habe recht gehabt: GlusterFS sei upstream zu schwach, habe zu wenig Enterprise-Nachfrage und sei zu riskant, um es offiziell weiterzutragen. Die zweite sagt, die Entfernung sei zu grob gewesen: Auch ohne den QEMU-Treiber funktioniere GlusterFS über FUSE weiterhin, und das Storage-Plugin leiste mehr als nur eine einzelne, enge Block-Treiber-Aufgabe. Die dritte sagt, das alles verfehle den praktischen Punkt: Manche Leute haben bereits GlusterFS, kennen bereits dessen Kompromisse und brauchen eine Brücke, keine Predigt.

Diese dritte Seite ist vielleicht die ehrlichste. Nicht jedes Plugin ist eine Revolution. Manchmal ist es ein Rettungsboot. Manchmal ist es ein Überdruckventil. Manchmal ist es einfach ein fähiger Nutzer, der sagt: "Ich weiß, das ist nicht die Zukunft, aber es ist noch meine Gegenwart."

Die Gefahr besteht darin, so zu tun, als sei das Rettungsboot ein Kreuzfahrtschiff. GlusterFS über Community-Patches in Proxmox 9 zu betreiben, mag für Labore, Migrationen, Nischen-Setups und Leute funktionieren, die den Blast Radius vollständig verstehen. Für frische Enterprise-Deployments ist es schwerer zu rechtfertigen, es sei denn, es gibt einen sehr spezifischen Grund und einen sehr nüchternen Support-Plan. Das Plugin bringt Wahlfreiheit zurück. Es bringt kein offizielles Vertrauen zurück.

Das macht diese ganze Episode so ungeschönt. Es geht nicht nur um Storage. Es geht um das unordentliche Nachleben nützlicher Software. Ein Projekt verblasst. Ein Anbieter zieht weiter. Eine Plattform streicht den Support. Nutzer protestieren. Jemand schreibt Code. Das Feature kehrt zurück, aber nicht auf dieselbe Weise. Jetzt trägt es ein Etikett, sichtbar oder nicht: von der Community wiederbelebt, mit offenen Augen fortfahren.

GlusterFS ist nicht ganz tot. Es ist aber auch nicht mehr richtig lebendig auf die alte Art. Und irgendwo in dieser unbequemen Mitte tut ein selbstgebautes Proxmox-Plugin genau das, was Open Source schon immer am besten konnte: sich zu weigern, das offizielle Ende als das einzige Ende gelten zu lassen.