FlashStore gegen Crimson: Zwei Neuschreibungen desselben OSD

Offenlegung vorweg: Ich arbeite für croit, die FlashStore geschrieben haben. Alles unten ist aus Cephs Quellcode und Dokumentation bei v21.2.0 und aus croits veröffentlichtem ceph-rust-Snapshot gelesen, alles verlinkt am Ende der Seite. Wo croits eigene Begründung auf einer Seite eines Arguments steht, sage ich, wessen Begründung es ist.

Zwei Neuschreibungen desselben Daemons

Das klassische Ceph-OSD ist ein Thread-Server in C++, der auf drehenden Platten groß geworden ist. Auf schnellem NVMe und schnellen Netzen verbringt es viel seiner CPU mit Dingen, die nicht deine Daten speichern: Operationen zwischen Thread-Pools weiterreichen, Locks nehmen, auf andere Threads warten. Zwei Projekte haben sich vorgenommen, das zu beheben, indem sie das OSD komplett neu schreiben.

Das eine ist Crimson, Cephs eigenes. Umbrellas Dokumentation nennt es „the next generation ceph-osd“, gebaut „to deliver enhanced performance on fast network and storage devices“¹. Das andere ist croits FlashStore-OSD aus dem Projekt ceph-rust, seit 9. November 2026 in Public Preview².

Beide sagen, sie seien Drop-in-Ersatz. Beide sagen, sie seien für NVMe. Beide sind in der Preview, und keins von beiden sollte heute Produktivdaten halten. Wenn du also NVMe-Ceph betreibst und überlegst, welches du im Auge behalten solltest, lohnt es sich zu wissen, wo sie sich wirklich unterscheiden, denn das ist nicht da, wo die Schlagzeilen es vermuten lassen.

Hier stehen sie so nebeneinander, wie du sie auf Ceph 21.2.0, Umbrella, vorfindest: Crimson, wie dieses Release es dokumentiert und ausliefert, gegen FlashStore, das gegen genau dieses Release gebaut und getestet wird². Es schließt an FlashStore gegen Umbrella-BlueStore an, und was dort über FlashStore schon steht, setze ich voraus.

Woher jedes kommt

Der erste Unterschied ist, wer es baut und wie.

Crimson lebt in Cephs eigenem Repository und wird von Cephs eigenen Entwicklern gebaut. Es ist auf Seastar geschrieben, einem C++-Framework für Thread-per-Core-Server, das von ScyllaDB stammt³. Die Umbrella-Doku sagt klar, dass es „is in a tech-preview stage and is not suitable for production use“¹.

FlashStore ist von Grund auf in Rust geschrieben und linkt überhaupt keinen Ceph-Code; Cephs C++ wird als Referenz gelesen und nach croits eigenen Spezifikationen neu implementiert⁴. Seine README sagt, es sei für Tests und Evaluierung und „not yet recommended for production data“, die allgemeine Verfügbarkeit ist für das erste Quartal 2027 geplant². Das öffentliche Repository ist ein schreibgeschützter Snapshot: „no issue tracker, no contribution workflow“².

Diese Zeile solltest du genau lesen. Crimson wird offen entwickelt, und jeder kann die Pull Requests lesen und darüber streiten. FlashStore kommt vorerst als fertige Snapshots von einer Firma: Du kannst jede Zeile lesen, aber noch keinen Patch schicken. Das ist die Preview-Phase, nicht der Plan. Die Preview ist dazu da, Feedback aus der Community zu sammeln, während croit intern seine Produktions-Testfälle durchläuft, bevor es das OSD als sicher für den Einsatz freigibt. Nach diesem ersten Produktiv-Release wird die Entwicklung offen, der Weg, den die meisten von Firmen getragenen Open-Source-Projekte gehen. Das kommt aus croit selbst und nicht aus einer veröffentlichten Roadmap, also nimm sie beim Wort.

croit hat sich tatsächlich einen Fork von Crimson angeschaut und aufgeschrieben, warum es keinen gemacht hat. Sein ADR sagt, Crimson „tries to support everything (HDD, alienstore/BlueStore, all pool types)“, und fügt hinzu: „Complex code is never fast“⁴. Das ist croits Meinung über Crimson, keine Messung, und so würde ich sie auch behandeln. Dasselbe ADR hat einen Fork auch wegen der LGPL abgelehnt⁴, und acht Tage später hat croit seinen eigenen Daemon unter LGPL-3.0 gestellt⁵. Die Lizenz war also nie wirklich der Grund.

Speichersicherheit: Rust gegen C++

Ein OSD ist der Code, der deine Daten hält. Ein Use-after-free oder ein Pufferüberlauf darin ist kein Absturz, nach dem du neu startest; es sind kaputte Daten auf der Platte, kopiert auf jedes Replikat. Genau diese Klasse von Fehlern sollen Hersteller nach dem Willen der westlichen Cyber-Behörden seit drei Jahren per Design ausschließen.

Die gemeinsame Leitlinie sagt es klar: „Programming languages such as C and C++ are examples of memory unsafe programming languages“⁶. CISA und FBI gehen weiter und nennen „the development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++)“ gefährlich, wenn eine speichersichere Alternative verwendet werden könnte⁷. Das ist eine Leitlinie, kein Gesetz. Aber Storage unter kritischen Diensten ist genau der Code, auf den sie zielt, und beide hier sind OSDs der nächsten Generation, die daran gemessen werden.

FlashStore erfüllt sie. Es ist in Rust geschrieben, und croits ADR gibt den Grund in einer Zeile: „Storage = correctness-critical; memory-safety bugs = data loss“⁸. Der Compiler prüft die Speichersicherheit überall außer in Code, der als unsafe markiert ist, und dasselbe ADR beschränkt den auf die Module für FFI, DMA, NVMe und Netzwerktreiber, jeweils mit einem SAFETY-Kommentar⁸. Ich habe im Snapshot nachgezählt: 1.216 Zeilen, die unsafe erwähnen, von 696.125 Zeilen Rust, etwa 0,17 %, und sie sitzen in den Crates für RDMA, Runtime, NVMe und Store, wo der Code mit der Hardware spricht. Die gemeinsame Leitlinie nennt diese Hintertür selbst und merkt an, dass Rust „can contain the ‘unsafe’ keyword“⁶, also ist das das ehrliche Maß: nicht null, aber klein, abgezäunt und an den Stellen, an denen du es erwarten würdest. Das C, das es aufruft, SPDK und DPDK, sitzt hinter denselben Grenzen⁸.

Crimson erfüllt sie nicht. Es ist ein neues OSD, in C++ auf einem C++-Framework geschrieben¹³, also in der Sprache, die die Behörden oben als speicherunsicher benennen. Jede Zeile davon liegt außerhalb dessen, was ein Compiler auf Speichersicherheit prüfen kann, und in seiner Standardkonfiguration übergibt es den Store an BlueStore, das ebenfalls C++ ist.

Cephs Entwickler haben C++ nicht leichtfertig gewählt; Crimson ist aus einer C++-Codebasis gewachsen, und an Ort und Stelle neu zu schreiben hieß, darin zu bleiben. Das ist ein vernünftiger technischer Weg. Es bleibt trotzdem dabei, dass das Ceph-OSD der nächsten Generation in genau der Art von Sprache geschrieben ist, die neuer kritischer Code nach dem Wunsch der Behörden von fünf Ländern hinter sich lassen soll.

Wie jedes einem Cluster beitritt

Das ist der größte praktische Unterschied zwischen beiden, und mit Performance hat er überhaupt nichts zu tun.

Ein FlashStore-OSD tritt den Pools bei, die du schon hast. Es sitzt in denselben Placement Groups neben klassischen BlueStore-OSDs, und du tauschst ein Laufwerk nach dem anderen².

Ein Crimson-OSD tut das nicht. Nicht mal annähernd. Umbrellas Doku sagt: „Crimson OSD won’t instantiate PGs from non-Crimson pools“¹. Der Code macht genau das. Wenn der Monitor ein Crimson-OSD bittet, eine PG in einem Pool ohne das crimson-Flag anzulegen, loggt es „pool lacks crimson flag“ und bricht das Anlegen ab⁹.

Ein Crimson-Test heißt also neue Pools, mit dem crimson-Flag angelegt, und deine Daten dorthin umgezogen. Und diese Pools kommen mit Bedingungen, die der Monitor durchsetzt:

FlashStore bedient klassische Pools, replizierte wie erasure-codierte, und lehnt die EC-Konfigurationen, die es nicht unterstützt, selbst ab, statt dass der Monitor sie verweigert¹⁴. Keiner der beiden Ansätze ist falsch. Aber mit dem einen testest du auf einer Kopie deines echten Pool-Layouts, und der andere lässt dich erst ein separates bauen.

Kein Weg hinüber für die Pools, die du schon hast

Kannst du also einen bestehenden Pool in einen Crimson-Pool verwandeln und ihn Laufwerk für Laufwerk umziehen? Nein.

Umbrellas Doku sagt, Crimson sei „aiming to allow seamless migration from existing ceph-osd deployments“¹. Aiming. Das Release kann es nicht, und der Quellcode zeigt, warum es nicht geht. Das crimson-Flag ist eine Option von ceph osd pool create und sonst nirgends¹⁵. ceph osd pool set hat keine crimson-Variable, die du auf einem schon bestehenden Pool setzen könntest¹⁶. Und ein Crimson-OSD ignoriert, wie oben, jede PG in einem Pool ohne das Flag⁹. Ein Umwandlungswerkzeug habe ich weder im Quellcode noch in der Doku gefunden.

Ein Umzug zu Crimson ist damit eine Datenkopie, die du selbst fährst: RBD-Images lassen sich live „between different pools“ migrieren¹⁷, und Objekt- oder Dateidaten brauchen das, womit deine Anwendungen sie eben kopieren. Danach muss jeder Client auf den neuen Pool zeigen.

FlashStore ist mit den Pools kompatibel, die du heute fährst. Du bereitest es auf einem Laufwerk vor, der Cluster füllt per Backfill die Placement Groups auf, die es zugeteilt bekommt, und deine Clients merken nie, dass sich der Pool unter ihnen geändert hat, weil er das nicht hat¹⁸. Das ist der ganze Unterschied zwischen einer Neuschreibung, die deinem Cluster beitritt, und einer, die daneben sitzt.

Was jedes dem Monitor meldet

Crimson meldet sich an. Beim Booten schickt es osd_type=crimson¹⁹, und der Monitor lässt es nicht rein, solange das OSDMap-Flag allow_crimson nicht gesetzt ist, mit einer Logzeile, die sagt, crimson-osd „is considered unstable and may result in crashes or data loss“²⁰. Bis dahin brauchst du laut Doku vier Befehle, und der erste setzt eine Option namens enable_experimental_unrecoverable_data_corrupting_features¹.

FlashStore macht das Gegenteil. Es schickt überhaupt kein osd_type und meldet osd_objectstore=bluestore, also sieht der Monitor ein klassisches OSD und stellt keine Fragen²¹. Der vorige Post erklärt, warum: Umbrellas Monitor macht Features wie EC-Overwrites davon abhängig, dass jedes OSD in einem Pool BlueStore meldet²¹. Das gilt für die Standard-Monitore und -Manager, die heute in Produktion laufen. Auf croits eigenen Ceph-Builds, wo sie so gepatcht sind, dass sie es kennen, meldet sich FlashStore als flashstore²¹.

Mir ist lieber, wenn Software mir sagt, was sie ist. Crimson tut das. Sein Weg ist der ehrliche, und der Name des Flags lässt keinen Zweifel daran, worauf du dich einlässt. FlashStores Weg ist das, womit Drop-in auf den Standard-Monitoren und -Managern funktioniert, die die Leute heute fahren, und er ist eine Kompatibilitätsmaßnahme, nicht der Endzustand. Beides ist Absicht, und beides ist aufgeschrieben. Du solltest nur wissen, mit welchem du es zu tun hast, wenn du deine OSDs zählst.

Kerne: Reaktoren gegen gepinnte pollende Threads

Beide Projekte haben die Thread-Pools rausgeworfen. Gut so. Beide fahren einen Thread pro Kern und verteilen ihre Arbeit nach Kern. Der Unterschied liegt darin, wie viel sie vom Betreiber verlangen und wie fest sie den Kern halten.

Für Crimsons crimson_cpu_num gilt: Es „does not have a default value“, muss vor dem Deployment der OSDs gesetzt werden und „cannot be changed after deployment“¹. Es pinnt keine Threads, solange du nicht auch crimson_cpu_set setzt, was die Doku als „generally less recommended due to its complexity“ beschreibt¹. Der Reaktor pollt im Leerlauf 200 µs, bevor er wieder schlafen geht, und einen vollen Poll-Modus gibt es „at the expense of 100% cpu usage“, standardmäßig aus²². SeaStore verweigert außerdem nach mkfs eine Änderung der Reaktorzahl²³.

FlashStore pinnt per Design, pollt per Design und fährt im Leerlauf zurück²⁴²⁵. Seine Zahl der Store-Shards wird beim Prepare des Stores festgelegt, dieselbe Einschränkung an einer anderen Stelle²⁶.

In der Praxis wollen beide ganze Kerne, und beide wollen, dass du sie vor dem Deployment dimensionierst. Crimson macht das Polling zu einer Wahl, für die du dich entscheidest. FlashStore macht es zum Standard und lässt die Leerlauf-Logik einen Teil der CPU zurückholen.

Crimsons Standard-Store ist BlueStore

Das ist der Teil, der mich überrascht hat. Hätte er nicht sollen.

Crimson hat zwei Arten von Object Store. Native laufen im Seastar-Reaktor; nicht-native laufen über „a thread pool proxy“ zu „alien threads: worker threads not managed by Seastar“¹. SeaStore ist der native. BlueStore ist nicht-nativ. Und BlueStore ist der Standard.

Die Doku sagt das unverblümt. SeaStore „is the primary native object store for Crimson OSD, though it is not the default as the support is in early stages“¹. Cephadm deployt Crimson mit --objectstore bluestore, solange man nichts anderes sagt, und selbst dann lässt sich SeaStore nicht mit --method raw deployen; du sollst LVM nehmen¹.

Ein Crimson-OSD, das heute mit Standardeinstellungen deployt wird, fährt also ein Seastar-Frontend auf demselben BlueStore, RocksDB und BlueFS, die das klassische OSD nutzt, mit crimson_bluestore_num_threads Threads, die dafür abgestellt sind²². Auf der Store-Seite hat sich gegenüber dem klassischen OSD rein gar nix geändert. Als Migrationspfad ist das vernünftig gebaut. Es ist auch der Grund, warum ein Performance-Vergleich von „Crimson“ gegen FlashStore sehr wenig heißt, solange du nicht sagst, welchen Store Crimson gefahren hat.

Der faire Vergleich für den Store ist SeaStore gegen FlashStore. Darum geht es im Rest dieses Posts.

SeaStore und FlashStore: Wo die Metadaten liegen

Beide Stores wurden von Anfang an für NVMe geschrieben, beide sind nach Kern geshardet, und beide halten ihre Metadaten in eigenen B-Bäumen statt in RocksDB. Ihre Layouts sind trotzdem sehr verschieden.

SeaStore gibt jedem Reaktor seine eigene Wurzel²⁷. Darunter sitzen ein Onode-Baum, ein LBA-Baum und ein Backref-Baum. Der Onode jedes Objekts zeigt dann auf seinen eigenen OMAP-B-Baum und seinen eigenen XATTR-B-Baum, und auf Daten-Extents mit logischen Adressen²⁷. Der LBA-Baum bildet diese logischen Adressen auf physische ab, sodass ein Block auf der Platte wandern kann, ohne dass sich die Bäume des Objekts ändern; die Doku nennt diese Indirektion den Grund, warum die meisten Extents „can be relocated freely“²⁷.

FlashStore legt alles in einen Copy-on-Write-B+-Baum pro Shard: Onodes, Xattrs, OMAP, Extent-Maps mit einem crc32c pro 4-KiB-Block, das PG-Log und die Bitmap des Allocators²⁸. Extent-Maps zeigen direkt auf physische Blöcke. Dazwischen gibt es keine logische Schicht.

Beide Entscheidungen haben einen Grund. SeaStores Indirektion macht seinen Cleaner billig: Er kann lebende Daten verschieben, ohne jeden Baum neu zu schreiben, der auf sie zeigt. FlashStore braucht das nicht, weil es keinen Cleaner hat, wie unten beschrieben. Sein ADR führt „Per-object omap subtree/root“ unter den Alternativen auf, die es erwogen und verworfen hat²⁸.

Ein Unterschied bei den Prüfsummen, den du kennen solltest: SeaStore berechnet sein crc32c über einen ganzen gecachten Extent²⁹, FlashStore hält eins pro 4-KiB-Block²⁸.

Die Reihenfolge, in der ein Write committet

SeaStores Standard-Gerätetyp ist SSD, und der nutzt das segmentierte Backend³⁰. Auf diesem Backend ist eine Transaktion ein Journal-Eintrag mit Deltas, und mit den Daten kann eins von zwei Dingen passieren.

Kleine, kurzlebige Extents können inline im Journal-Eintrag mitfahren, und dann ist der Eintrag der ganze Commit²⁷. Größere oder langlebigere Extents gehen in separate Out-of-Line-Segmente, und dann legt die Doku die Reihenfolge fest: Der „final record with the deltas should be written only once the other blocks are persisted“²⁷. Das sind zwei Writes hintereinander, dieselbe Form wie BlueStores Commit erst der Daten, dann RocksDB.

FlashStore schreibt den Daten-Extent und die WAL-Einheit gleichzeitig, legt das crc32c der neuen Daten in den WAL-Eintrag, damit das Replay es prüfen kann, und bestätigt, wenn beides dauerhaft gespeichert ist²⁸. Ein Weg zum Gerät, egal wie groß.

Wie viel das ausmacht, hängt von deiner Last ab, genau wie im BlueStore-Vergleich. Bei niedriger Queue-Tiefe, wo Clients auf jeden Write warten, ist ein zweiter Weg echte Latenz. Unter Last versteckt das Bündeln das meiste davon.

Platz zurückbekommen

Die andere Hälfte eines Log-Structured-Designs ist das Aufräumen.

SeaStore auf dem segmentierten Backend schreibt nur in offene Segmente. Bevor ein Segment wiederverwendet werden kann, müssen seine lebenden Blöcke woanders neu geschrieben werden, und das Design-Dokument sagt, was das kostet: „we must ‘clean’ one byte of an existing segment for every byte written at steady state“²⁷. Einen Teil dieses Aufräumens mischt es in die laufenden Writes, um Spitzen zu vermeiden, den Rest erledigt es im Hintergrund, wenn das Laufwerk ruhiger ist²⁷. Die Segmentgröße steht standardmäßig auf 64 MiB³¹.

SeaStore hat zwar ein zweites Backend für NVMe, den Random Block Manager, laut Doku „Preferred for fast NVMe devices where overwrites are efficient enough that log structured updates aren’t worth the overhead“²⁷. Es ist nicht der Standard. Du wählst es mit seastore_main_device_type³⁰.

FlashStore hat keinen Segment-Cleaner. Keinen. Ein ersetzter Block geht an den Allocator des Shards zurück, sobald ein Checkpoint ihn hinter sich gelassen hat, und das passiert alle fünf Sekunden, solange etwas nicht persistiert ist, oder früher, wenn der WAL-Ring halb voll ist²⁸. Sein Design-Dokument hat ein Log-Structured-Layout rundweg abgelehnt²⁸. Das heißt nicht, dass es keine Hintergrundarbeit hat: Es führt weiterhin Baumseiten zusammen, kompaktiert sie und defragmentiert freien Platz, getaktet unter der Client-I/O²⁸. Aber es kopiert nie deine lebenden Daten, um Platz zu schaffen.

Auf Flash, das in seinem Inneren schon seine eigene Garbage Collection fährt, wäre mir lieber, das OSD fährt nicht noch eine zweite obendrauf. SeaStores eigene Doku scheint das ähnlich zu sehen, nach dem, was sie über das RBM-Backend sagt. Der Unterschied ist, dass FlashStore das zur einzigen Option gemacht hat und SeaStore zur Nicht-Standard-Option.

Worauf jedes läuft

Crimson behält die Breite. Die Doku sagt, SeaStore „may not be suitable for traditional HDDs“, aber „Crimson will continue to support BlueStore ensuring compatibility with HDDs and slower SSDs“¹, und SeaStores Design-Dokument führt noch immer ein Interesse an HDDs auf²⁷. Sein Messenger lehnt v1 rundweg ab, „ProtocolV1 is no longer supported“³², dieselbe Entscheidung, die FlashStore getroffen hat³³. Seine Doku empfiehlt „one of the latest available builds, as Crimson evolves rapidly“, was in der Praxis CI-Images von main heißt¹.

FlashStore verengt alles auf NVMe mit Power-Loss-Protection und holt seine Einfachheit genau daraus³⁴. Was genau der Tausch ist, den croits ADR beschreibt, nur von der anderen Seite.

Zwei Antworten auf dieselbe Frage

Beide Projekte sind von derselben Beobachtung ausgegangen: Das klassische OSD verschwendet schnelle Hardware. Sie haben sehr verschiedene Antworten gegeben.

Crimsons Antwort ist die der Community. Das OSD an Ort und Stelle neu schreiben, in Ceph, jeden alten Store und jedes alte Laufwerk am Laufen halten, während der neue Store reift, und jeden die Arbeit sehen lassen, während sie passiert. Das ist langsam, und das merkt man. In Umbrella fährt das Crimson-OSD mit Standardeinstellungen noch BlueStore über einen Thread-Pool, seine eigenen Pools sind von deinen abgezäunt, und um es einzuschalten, tippst du die Worte „unrecoverable data corrupting“. Aber es gehört jedem, der Ceph betreibt, und niemand kann es dir wegnehmen.

FlashStores Antwort ist die eines Herstellers. Ein engeres Ziel wählen, NVMe mit Power-Loss-Protection, alles rauswerfen, was es nur für andere Hardware gab, und einen Store ausliefern, der in die Pools einsteigt, die du schon hast. Das ist schneller, und das merkt man auch. Aber es kommt von einer Firma, bis zum ersten Produktiv-Release als schreibgeschützte Snapshots, und auf einem Standard-Cluster kommt es hinein, indem es dem Monitor erzählt, es sei BlueStore.

Ich arbeite für diese Firma, also gewichte das Folgende entsprechend. croit hat für All-Flash-Cluster die richtige technische Wette gemacht. Crimson hat die richtige Wette für Ceph als Projekt gemacht. Das ist nicht dasselbe. Ein Projekt, das allen dient, kann HDDs nicht fallen lassen. Ein Hersteller kann das, und sollte es auch, wenn es das ist, was seine Kunden kaufen.

Was ich nicht tun würde: zwischen beiden anhand eines Benchmark-Diagramms von irgendeiner Seite wählen. Crimsons Zahlen hängen davon ab, welcher seiner drei Stores lief; FlashStores kommen aus croits eigenem Labor. Beide Projekte veröffentlichen ihre Design-Dokumente. Lies sie, stell dann beide auf die Laufwerke, die du tatsächlich einsetzen würdest, und fahr deine eigene Last. Das, was immer noch tut, was seine Dokumente sagen, wenn es um deine Daten geht, ist das, auf das sich das Warten lohnt.