Vitastor 3.2 im Nachtest: Upstream testet jetzt Stromausfälle

Wir haben Vitastor für unsere Produktion bisher abgelehnt, weil wir dem Schreibpfad nicht genug vertrauten. Upstream hat seitdem an genau dieser Stelle nachgelegt: Vitastor 3.2.0 vom 31. August enthält einen Simulationstest für Stromausfälle, 3.2.1 (13. September) und 3.2.2 (27. September) haben weitere Fehler behoben. Die Zahlen aus den Release-Notizen stammen vom Maintainer, wir haben sie nicht selbst nachgemessen. Wo wir selbst etwas gemessen oder erlebt haben, steht das dabei.

Was der neue Test macht

Ein Prozess, der mit kill -9 beendet wird, verliert keine Schreibvorgänge, die schon im Cache des Betriebssystems liegen. Ein Stromausfall verliert sie. Die Integrationstests, die Vitastor bis 3.1 mitbrachte, liefen gegen Dateien und konnten diese Fehlerklasse deshalb nicht auslösen. So haben wir die Testsuite am 22. August gelesen. Der Test aus 3.2.0 simuliert stattdessen die Platte: Der flüchtige Schreibcache verliert bei einem simulierten Ausfall eine zufällige Teilmenge seines Inhalts, und Schreibvorgänge, die gerade liefen, landen ganz, teilweise (an einer Sektorgrenze abgerissen) oder gar nicht. Dazu liefert io_uring Abschlüsse in zufälliger Reihenfolge und mit Verzögerung. Der Store selbst ist der echte: Journal, Metadaten, Flusher, Compaction und Prüfsummen.

Die CI fährt bei jedem Build 200 Läufe, sogenannte Seeds, in 24 Konfigurationen: alter und neuer Store, Server- und Desktop-Platten (mit und ohne Kondensatoren), zweiphasige (EC) und sofortige (replizierte) Schreibvorgänge, Prüfsummen aus oder an mit 4 KB oder 16 KB Blockgröße.

Angabe des Maintainers in den Release-Notizen zu 3.2.0 vom 31.08.2026. (Quelle: Vitastor 3.2.0, Release-Notizen)

83 von 200 Läufen fielen gegen 3.1.0 durch. Für uns ist das die wichtigste Zahl: Nach unserer Lektüre der Testsuite konnte bis dahin kein Test der Version diese Fehlerklasse finden.

Was der Test gefunden hat

Nach den Release-Notizen zu 3.2.0 gehörten im neuen Store dazu:

Ein Objekt wurde nach einem Stromausfall unlesbar und meldete einen Prüfsummenfehler, in einem Fall lieferte es die Daten eines anderen Objekts.
SYNC konnte Erfolg melden, ohne etwas auf die Platte zu schreiben. Synchronisierten zwei Clients gleichzeitig, verbrauchte der zweite den Zähler des ersten, und als synchronisiert bestätigte Daten konnten bei einem Stromausfall verloren gehen.
Ein Schreibvorgang konnte verloren gehen, während ein neuerer Schreibvorgang desselben Objekts erhalten blieb. Das Objekt hielt dann eine Mischung aus zwei Versionen.
Ein Objekt konnte nach einem Neustart komplett verschwinden, wenn der Strom mitten in der Compaction ausfiel. Der Maintainer schreibt dazu, das sei bei Server-SSDs selten, aber theoretisch möglich.

Im alten Store brach der OSD bei allen Läufen der sechs EC-Konfigurationen mit einem internen Fehler ab. Das Journal-Replay konnte veraltete Schreibvorgänge eines gelöschten Objekts wieder aufleben lassen, zwei Schreibvorgänge auf denselben Journal-Sektor konnten gleichzeitig laufen, und der Maintainer nennt außerdem Korrekturen für Laufwerke ohne Kondensatoren.

Was danach kam

3.2.1 machte den Test asynchroner und fand damit rund sechs weitere Fehler im alten und rund neun im neuen Store. Dazu kam ein Fehler beim Entfernen älterer Snapshots: Der rm-Befehl mit der Optimierung „inverse“ löschte Daten einer Schicht vor dem Umbenennen, und Kind-Images konnten dadurch falsche Daten lesen. 3.2.2 brachte fünf Korrekturen. Dazu gehören der Fehler, dass replizierte Objekte nach mehreren fehlgeschlagenen Teilschreibvorgängen fälschlich in den Zustand INCOMPLETE wechselten, eine abgelehnte Compaction und ein Absturz von vitastor-cli rm, den 3.2.1 selbst eingeführt hatte. Zum Testen enthält die Notiz zu 3.2.2 keine Angaben.

Auf dem Master steht seit dem 29. September ein weiterer Fix im neuen Store, der noch in keinem Release ist: „fill the checksum slot of zero-length small writes“ (Commit f3e047fb05). 3.2.2 ist damit nicht der letzte Stand.

Was offen bleibt

Das Issue #75, ein Datenintegritäts-Audit per KI vom 9. Juni, ist weiter offen. Es hat fünf Kommentare, alle vom Maintainer, der letzte vom 19. Juni. Zusammen mit #72 bis #74 sind das die vier offenen Issues auf dem Haupt-Tracker, alle vier aus externen KI-Audits. Laut dem Reporter von #75 löscht vitastor-cli modify --resize mit kleinerer Größe alle Daten des Images, gibt es einen Heap-Überlauf im OSD, der ohne Anmeldung erreichbar ist, und wird ein fsync im Gast beim ublk-Pfad bestätigt, ohne die OSD zu erreichen. Das sind Angaben des Reporters, einige tragen dort den Vermerk, dass der Maintainer sie noch bestätigen muss. Wir haben keine Bestätigung des Maintainers gefunden. Einzelne Punkte sind seitdem behoben, die übrigen finden wir in den Release-Notizen bis 3.2.2 nicht. Das ist ein Stichwortvergleich, kein Code-Vergleich. Proxmox nutzt den QEMU-Treiber und nicht ublk, für uns ist der fsync-Punkt also mittelbar.

Der Test läuft außerdem in einer Simulation. Er zeigt, was der Code bei den Fehlern tut, die die Simulation kennt. Firmware, die falsche Bestätigungen liefert, kennt sie nicht.

Weitere Punkte aus unseren Unterlagen und den Trackern:

Der Scrub, der schlechte Kopien findet, ist standardmäßig ausgeschaltet (auto_scrub steht auf false, scrub_interval auf 30 Tage).
Auf GitHub sind die Issues #138 (wird TRIM über den QEMU-Treiber durchgereicht?) und #143 (RDMA-CM ist viel langsamer als RDMA) weiter offen.
3.2.1 hat die Option rxbounce für Windows-Gäste mit TCP und Prüfsummen eingeführt. Der Maintainer nennt keine Ursache, wir vermuten, dass Windows Puffer während des Sendens verändert. Das ist eine Vermutung.
Vitastor hat keine Authentifizierung. Die Dokumentation verlangt, Gäste vom OSD- und etcd-Netz fernzuhalten.
Verteilen sich die Kopien gleichmäßig auf zwei Standorte (2:2), entscheidet die Mehrheit nichts. scrub_find_best wählt die Version mit den meisten übereinstimmenden Kopien. Ob dabei die Prüfsummen den Ausschlag geben, steht nicht in der Dokumentation, und wir haben es nicht getestet.

Wie reif das Projekt ist

Der Maintainer hat 2915 Commits, der Zweitplatzierte 9 (Stand 22. August 2026, GitHub). Auf der 3.0-Linie erschienen zwischen Dezember 2025 und Juli 2026 sechzehn Patch-Releases. In den Notizen zu 3.0.14 schreibt der Maintainer, mehr als 50 Fehler seien behoben, die meisten seien mit LLM-Analyse gefunden worden und die meisten Fixes kämen jetzt mit Regressionstests. 3.0.16 vom 19. Juli korrigierte unter anderem, dass CAS-Schreibvorgänge ihr eingebautes fsync übersprangen, dass der OSD bei einem Datenfehler im fsync von gebündelten Schreibvorgängen weiterlief, und dass Lesezugriffe auf degradierte Objekte möglicherweise Nullen lieferten. Sechs Tage später kam 3.1.0 mit Verschlüsselung im Schreibpfad.

Was bei unserem eigenen Test schiefging

Wir haben einen Black-Box-Test gebaut, der Vitastor mit Ausfällen beschießt und danach gegen ein Log der bestätigten Schreibvorgänge prüft. Bei der Durchsicht am 22. August fanden wir, dass er noch nie durchgelaufen war:

Die Gerätepfade waren um eins verschoben: Die Datenplatte zeigte auf die Metadaten-Platte, und das Journal-Gerät existierte nicht.
Ein Bau aus dem Quelltext installiert keine systemd-Units und keine udev-Regel. Die liefert nur das Debian-Paket, also startete weder ein OSD noch ein Monitor.
Der Monitor bekam ein Flag, das es nicht gibt (--etcd_url statt --etcd_address), sodass keine PGs vergeben wurden.
vitastor-cli hat keinen scrub-Befehl. Die zweite Prüfung, die der Test versprach, lief nie.
Die Prüfung verglich den Blockindex nicht. Ein Block mit der richtigen Sequenznummer am falschen Ort galt als sauber. Wir haben das nachgestellt: Der Prüfer meldete clean, der Selbsttest hatte für diesen Fall keinen Eintrag und hat ihn jetzt (7 von 7 statt 6 von 6).
Die eingestellte „Queue-Depth“ war keine, weil der Schreiber blockierend schrieb und nie mehr als eine Anfrage offen hatte.

Die Lehre daraus: bash -n prüft die Syntax, nicht ob ein /dev/-Pfad existiert. Der Test hat bisher kein Ergebnis geliefert. Der nächste Lauf gegen 3.2.2 braucht eigene Hardware.

Wie schnell es war

In unserem Test mit 100.000 gemischten Schreib- und Leseoperationen lag Vitastor am 31. Juli mit rund 200 Sekunden gleichauf mit DRBD. Von etwa 2 ms je Operation entfallen rund 0,15 ms auf die Storage-Replikation. Die Geschwindigkeit war nie der Grund für unsere Zurückhaltung.

Wie wir es einordnen

Als Freigabe für den Produktiveinsatz hatten wir vier Bedingungen notiert, und alle vier müssen erfüllt sein: Issue #75 ist vollständig geschlossen, das Online-Resharding ist wieder aktiv und hat Regressionstests, ein zweites unabhängiges Audit liegt ohne Befund vor, und zwei Releases in Folge bringen keine neue schwere Meldung zu Datenverlust. Zusätzlich hatten wir als Auslöser für eine Neubewertung einen Upstream-Test für Stromausfälle oder ein unabhängiges Audit notiert. Der Auslöser ist seit 3.2.0 erfüllt. Von den vier Bedingungen ist nach unserer Lesart der Release-Notizen keine erfüllt.

Der Test zeigt, dass die Lücke real war, und der Maintainer hat sie geschlossen. Ob die Fehlerklasse damit erledigt ist, zeigen die nächsten Releases: 3.2.1 fand mit mehr Asynchronität noch rund 15 Fehler, 3.2.2 brachte weitere Korrekturen, und auf dem Master liegt schon der nächste. Unsere Freigabe für den Produktiveinsatz bleibt deshalb aus.

Mehr Kopien schützen davor nicht: Ein Fehler im Schreibpfad würde alle Kopien gleich verfälschen. Das ist unsere Schlussfolgerung, kein Messwert.

Was wir als Nächstes tun

Wer Vitastor jetzt prüft, nimmt die neueste Version, schaltet auto_scrub ein und fährt einen eigenen Stromausfalltest auf echter Hardware, bevor Kundendaten darauf liegen. Wir tun dasselbe: Sobald wir Hardware haben, lassen wir unseren Test gegen 3.2.2 laufen und prüfen dabei auch, ob bei 2:2 die richtige Kopie gewinnt, wenn eine beschädigt ist.

Weiterführende Quellen

Fragen?

Was ist an Vitastor 3.2 neu?+

Die CI simuliert seit 3.2.0 Stromausfälle: Der Schreibcache der simulierten Platte verliert einen zufälligen Teil seines Inhalts, laufende Schreibvorgänge landen ganz, teilweise oder gar nicht. Es laufen 200 Läufe pro Build in 24 Konfigurationen. Gegen 3.1.0 scheiterten 83 dieser 200 Läufe, nach Angabe des Maintainers.

Ist Vitastor damit produktionsreif?+

Das können wir nicht bestätigen. Unser Auslöser für eine Neubewertung, ein Upstream-Test für Stromausfälle, ist erfüllt. Von den vier Freigabe-Bedingungen ist nach unserer Lesart keine erfüllt: Issue #75 ist offen, ein unabhängiges Audit haben wir nicht gefunden, das Online-Resharding ist nach den Release-Notizen weiter abgeschaltet, und 3.2.1 und 3.2.2 haben weiter Fehler im Schreibpfad behoben.

Warum genügt ein Test, der einen Prozess mit kill -9 beendet?+

Schreibvorgänge im Cache des Betriebssystems überleben das Beenden des Prozesses, ein Stromausfall vernichtet sie. Ein Test gegen Dateien kann deshalb Fehler im fsync-Pfad nicht auslösen, weil der Prozess seine Platte nie verliert.