FlashStore Tegenover Crimson: Twee Herschrijvingen Van Dezelfde OSD

Eerst de disclosure: ik werk voor croit, dat FlashStore geschreven heeft. Alles hieronder is gelezen uit de broncode en documentatie van Ceph op v21.2.0 en uit de gepubliceerde ceph-rust-snapshot van croit, allemaal gelinkt onderaan de pagina. Waar de eigen redenering van croit aan één kant van een argument staat, zeg ik van wie die redenering is.

Twee Herschrijvingen Van Dezelfde Daemon

De klassieke Ceph-OSD is een C++-server met threads die is opgegroeid op draaiende schijven. Op snelle NVMe en snelle netwerken besteedt hij een groot deel van zijn CPU aan dingen die niet het opslaan van je data zijn: ops doorgeven tussen threadpools, locks nemen, wachten op andere threads. Twee projecten zijn begonnen om dat op te lossen door de OSD helemaal te herschrijven.

Het ene is Crimson, van Ceph zelf. De documentatie van Umbrella noemt het “the next generation ceph-osd”, gebouwd “to deliver enhanced performance on fast network and storage devices”¹. Het andere is de FlashStore-OSD van croit, uit het ceph-rust-project, in public preview sinds 9 november 2026².

Allebei zeggen ze drop-in-vervangers te zijn. Allebei zeggen ze voor NVMe te zijn. Allebei zitten ze in preview, en geen van beide hoort vandaag productiedata te bewaren. Dus als je NVMe-Ceph draait en je je afvraagt welke je in de gaten moet houden, loont het om te weten waar ze echt verschillen, want dat is niet waar de koppen het doen vermoeden.

Deze post vergelijkt ze zoals je ze aantreft op Ceph 21.2.0, Umbrella: Crimson zoals die release het documenteert en levert, tegenover FlashStore, dat tegen precies die release gebouwd en getest is². Hij volgt op FlashStore Tegenover Umbrella BlueStore, en alles wat daar al over FlashStore gezegd is, neem ik hier als bekend aan.

Waar Elk Vandaan Komt

Het eerste verschil is wie het bouwt en hoe.

Crimson staat in Ceph’s eigen repository en wordt gebouwd door Ceph’s eigen ontwikkelaars. Het is geschreven op Seastar, een C++-framework voor thread-per-core-servers dat uit ScyllaDB komt³. De docs van Umbrella zeggen het zonder omwegen: het “is in a tech-preview stage and is not suitable for production use”¹.

FlashStore is vanaf nul in Rust geschreven en linkt helemaal geen Ceph-code; de C++ van Ceph wordt als referentie gelezen en opnieuw geïmplementeerd vanuit croits eigen specificaties⁴. De README zegt dat het voor testen en evaluatie is en “not yet recommended for production data”, met algemene beschikbaarheid gepland voor het eerste kwartaal van 2027². De publieke repository is een read-only snapshot: “no issue tracker, no contribution workflow”².

Die rij is het waard om goed te lezen. Crimson wordt in het open ontwikkeld, en iedereen kan de pull requests lezen en erover in discussie gaan. FlashStore komt voorlopig binnen als afgewerkte snapshots van één bedrijf: je kunt elke regel lezen, maar je kunt er nog geen patch naartoe sturen. Dat is de preview-fase, niet het plan. De preview is er om feedback uit de community te verzamelen terwijl croit intern zijn productietestcases doorloopt, voordat het de OSD als veilig voor gebruik aanmerkt. Na die eerste productierelease wordt de ontwikkeling open, dezelfde weg die de meeste door bedrijven gedragen open-sourceprojecten nemen. Dat komt van binnen croit en niet uit een gepubliceerde roadmap, dus houd ze eraan.

croit heeft wel naar een fork van Crimson gekeken en heeft opgeschreven waarom het dat niet deed. De ADR zegt dat Crimson “tries to support everything (HDD, alienstore/BlueStore, all pool types)”, en voegt toe “Complex code is never fast”⁴. Dat is croits mening over Crimson, geen meting, en zo zou ik het ook behandelen. Dezelfde ADR wees een fork deels af vanwege de LGPL⁴, en acht dagen later gaf croit zijn eigen daemon een LGPL-3.0-licentie⁵. De licentie was dus nooit echt de reden.

Geheugenveiligheid: Rust Tegenover C++

Een OSD is de code die je data vasthoudt. Een use-after-free of een buffer overrun daarin is geen crash waar je van herstart; het is corrupte data op schijf, gekopieerd naar elke replica. Dat is precies de klasse bugs waarvan de westerse cyberagentschappen de industrie de afgelopen drie jaar voorhouden dat ze die moet wegontwerpen.

De gezamenlijke richtlijn zegt het zonder omwegen: “Programming languages such as C and C++ are examples of memory unsafe programming languages”⁶. CISA en de FBI gaan verder, en noemen “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++)” gevaarlijk als er een geheugenveilig alternatief gebruikt had kunnen worden⁷. Dat is een richtlijn, geen wet. Maar opslag onder kritieke diensten is precies de code waar hij op mikt, en dit zijn allebei OSD’s van de volgende generatie die eraan afgemeten zullen worden.

FlashStore voldoet eraan. Het is geschreven in Rust, en de ADR van croit geeft de reden in één regel: “Storage = correctness-critical; memory-safety bugs = data loss”⁸. De compiler controleert geheugenveiligheid overal behalve in code die als unsafe gemarkeerd is, en dezelfde ADR beperkt dat tot de FFI-, DMA-, NVMe- en netwerkdrivermodules, elk met een SAFETY-commentaar⁸. Ik heb het geteld in de snapshot: 1.216 regels die unsafe noemen op 696.125 regels Rust, ongeveer 0,17%, en ze zitten in de RDMA-, runtime-, NVMe- en store-crates, waar de code met hardware praat. De gezamenlijke richtlijn noemt die nooduitgang zelf, met de opmerking dat Rust “can contain the ‘unsafe’ keyword”⁶, dus dat is de eerlijke maatstaf: niet nul, maar klein, afgebakend, en op de plekken waar je het zou verwachten. De C die het wel aanroept, SPDK en DPDK, zit achter diezelfde grenzen⁸.

Crimson voldoet er niet aan. Het is een nieuwe OSD, geschreven in C++ op een C++-framework¹³, en dat is de taal die de agentschappen hierboven als niet geheugenveilig noemen. Geen regel ervan valt binnen wat een compiler op geheugenveiligheid kan controleren, en in de standaardconfiguratie geeft het de store door aan BlueStore, en dat is ook C++.

De ontwikkelaars van Ceph hebben niet achteloos voor C++ gekozen; Crimson is gegroeid uit een C++-codebase, en ter plekke herschrijven betekende daarin blijven. Dat is een redelijk engineeringpad. Het laat de Ceph-OSD van de volgende generatie nog steeds geschreven in precies het soort taal waarvan de agentschappen van vijf landen gevraagd hebben dat nieuwe kritieke code het achter zich laat.

Hoe Elk Bij Een Cluster Aansluit

Dit is het grootste praktische verschil tussen de twee, en het gaat helemaal niet over performance.

Een FlashStore-OSD sluit aan bij de pools die je al hebt. Hij zit in dezelfde placement groups naast klassieke BlueStore-OSD’s, en je vervangt één schijf tegelijk².

Een Crimson-OSD doet dat niet. Bij lange na niet. De docs van Umbrella zeggen: “Crimson OSD won’t instantiate PGs from non-Crimson pools”¹. De code doet precies dat. Als de monitor een Crimson-OSD vraagt een PG aan te maken in een pool zonder de crimson-vlag, logt hij “pool lacks crimson flag” en annuleert hij het aanmaken⁹.

Een proef met Crimson betekent dus nieuwe pools, aangemaakt met de crimson-vlag, en je data die daarnaartoe verhuist. En die pools komen met voorwaarden die de monitor afdwingt:

FlashStore bedient klassieke pools, zowel gerepliceerd als erasure-coded, en slaat de EC-configuraties die het niet ondersteunt zelf af in plaats van ze bij de monitor te weigeren¹⁴. Geen van beide aanpakken is fout. Maar met de ene kun je testen op een kopie van je echte poolindeling, en met de andere moet je eerst een aparte bouwen.

Geen Weg Over Voor De Pools Die Je Al Hebt

Kun je dan een bestaande pool in een Crimson-pool veranderen, en hem schijf voor schijf overzetten? Nee.

De docs van Umbrella zeggen dat Crimson “aiming to allow seamless migration from existing ceph-osd deployments” is¹. Aiming. De release doet het niet, en de broncode laat zien waarom het niet kan. De crimson-vlag is een optie op ceph osd pool create en nergens anders¹⁵. ceph osd pool set heeft geen crimson-variabele om te zetten op een pool die al bestaat¹⁶. En een Crimson-OSD negeert elke PG in een pool zonder de vlag, zoals hierboven⁹. Ik heb in de broncode en de docs geen conversietool gevonden.

Dat maakt een overstap naar Crimson een datakopie die je zelf draait: RBD-images kunnen live gemigreerd worden “between different pools”¹⁷, en object- of bestandsdata heeft nodig wat je applicaties ook gebruiken om ze te kopiëren. Daarna moet elke client naar de nieuwe pool gewezen worden.

FlashStore is compatibel met de pools die je vandaag draait. Je prepareert hem op een schijf, het cluster backfillt de placement groups die hij krijgt, en je clients merken nooit dat de pool onder ze veranderde, want dat deed hij niet¹⁸. Dat is het hele verschil tussen een herschrijving die bij je cluster aansluit en een die ernaast staat.

Wat Elk Aan De Monitor Meldt

Crimson maakt zich bekend. Bij het opstarten stuurt het osd_type=crimson¹⁹, en de monitor laat het niet binnen tenzij de OSDMap-vlag allow_crimson gezet is, met een logregel die zegt dat crimson-osd “is considered unstable and may result in crashes or data loss”²⁰. Zo ver komen kost vier commando’s uit de docs, en het eerste daarvan zet een optie die enable_experimental_unrecoverable_data_corrupting_features heet¹.

FlashStore doet het omgekeerde. Het stuurt helemaal geen osd_type en meldt osd_objectstore=bluestore, dus de monitor ziet een klassieke OSD en stelt geen vragen²¹. De vorige post legt uit waarom: de monitor van Umbrella laat features zoals EC-overwrites afhangen van elke OSD in een pool die BlueStore meldt²¹. Dat is voor de standaard monitors en managers die vandaag in productie draaien. Op croits eigen Ceph-builds, waar die gepatcht zijn om hem te kennen, meldt FlashStore zich als flashstore²¹.

Ik heb liever dat software me vertelt wat het is. Crimson doet dat. Zijn manier is de eerlijke, en de naam van de vlag laat je geen twijfel over waar je mee instemt. De manier van FlashStore is wat drop-in laat werken op de standaard monitors en managers die mensen nu draaien, en het is een compatibiliteitsmaatregel, niet de eindtoestand. Allebei zijn ze bewust gekozen, en allebei staan ze op papier. Weet alleen met welke je te maken hebt als je je OSD’s telt.

Cores: Reactors Tegenover Vastgepinde Pollende Threads

Beide projecten hebben de threadpools eruit gegooid. Mooi. Allebei draaien ze één thread per core en verdelen ze hun werk per core. Het verschil zit in hoeveel ze van de beheerder vragen en hoe hard ze de core vasthouden.

Over crimson_cpu_num zeggen de docs van Crimson dat het “does not have a default value”, dat het gezet moet worden voordat de OSD’s uitgerold worden, en dat het “cannot be changed after deployment”¹. Het pint geen threads vast tenzij je ook crimson_cpu_set zet, wat de docs omschrijven als “generally less recommended due to its complexity”¹. De reactor pollt bij idle 200 µs voordat hij weer gaat slapen, en er bestaat een volledige pollmodus “at the expense of 100% cpu usage”, standaard uit²². SeaStore weigert ook een wijziging van het aantal reactors na mkfs²³.

FlashStore pint vast door ontwerp, pollt door ontwerp, en schakelt terug bij idle²⁴²⁵. Het aantal store-shards ligt vast wanneer de store geprepareerd wordt, dezelfde beperking op een andere plek²⁶.

In de praktijk willen ze allebei hele cores, en willen ze allebei dat je die dimensioneert voordat je uitrolt. Crimson maakt van het pollen een keuze waar je voor kiest. FlashStore maakt het de standaard en laat de idle-logica een deel van de CPU terugwinnen.

De Standaard-Store Van Crimson Is BlueStore

Dit is het deel dat me verraste. Dat had niet gehoeven.

Crimson kent twee soorten object stores. Native stores draaien binnen de Seastar-reactor; niet-native stores draaien via “a thread pool proxy” naar “alien threads: worker threads not managed by Seastar”¹. SeaStore is de native. BlueStore is niet-native. En BlueStore is de standaard.

De docs zijn er bot over. SeaStore “is the primary native object store for Crimson OSD, though it is not the default as the support is in early stages”¹. Cephadm rolt Crimson uit met --objectstore bluestore tenzij je iets anders zegt, en zelfs dan kan SeaStore niet uitgerold worden met --method raw; je wordt verwezen naar LVM¹.

Een Crimson-OSD die vandaag met de standaardinstellingen wordt uitgerold, draait dus een Seastar-front-end boven op dezelfde BlueStore, RocksDB en BlueFS die de klassieke OSD gebruikt, met crimson_bluestore_num_threads threads daarvoor gereserveerd²². Aan de store-kant is er niks veranderd ten opzichte van de klassieke OSD. Dat is een verstandige manier om een migratiepad te bouwen. Het is ook de reden dat “Crimson” tegen FlashStore afzetten op performance weinig zegt, tenzij je erbij zegt welke store Crimson draaide.

De eerlijke vergelijking voor de store is SeaStore tegenover FlashStore. Dat is de rest van deze post.

SeaStore En FlashStore: Waar De Metadata Staat

Beide stores zijn vanaf het begin voor NVMe geschreven, beide zijn per core gesharded, en beide bewaren hun metadata in eigen B-trees in plaats van in RocksDB. Hun indeling is toch heel verschillend.

SeaStore geeft elke reactor een eigen root²⁷. Daaronder zitten een onode-boom, een LBA-boom en een backref-boom. De onode van elk object wijst vervolgens naar zijn eigen OMAP-B-tree en zijn eigen XATTR-B-tree, en naar data-extents met logische adressen²⁷. De LBA-boom vertaalt die logische adressen naar fysieke, zodat een blok op schijf kan verhuizen zonder dat de eigen bomen van het object veranderen; de docs noemen die indirectie de reden dat de meeste extents “can be relocated freely”²⁷.

FlashStore stopt alles in één copy-on-write-B+tree per shard: onodes, xattrs, OMAP, extent maps met een crc32c per blok van 4 KiB, de PG-log en de bitmap van de allocator²⁸. Extent maps wijzen rechtstreeks naar fysieke blokken. Er zit geen logische laag tussen.

Beide keuzes hebben een reden. De indirectie van SeaStore is wat zijn cleaner goedkoop maakt: hij kan levende data verplaatsen zonder elke boom te herschrijven die ernaar wijst. FlashStore heeft dat niet nodig, omdat het geen cleaner heeft, zoals hieronder blijkt. De ADR noemt “Per-object omap subtree/root” onder de alternatieven die overwogen en afgewezen zijn²⁸.

Eén verschil in checksums dat de moeite waard is om te kennen: SeaStore berekent zijn crc32c over een hele gecachete extent²⁹, waar FlashStore er één per blok van 4 KiB bijhoudt²⁸.

De Volgorde Waarin Een Write Commit

Het standaard device-type van SeaStore is SSD, dat de gesegmenteerde backend gebruikt³⁰. Op die backend is een transactie een journal record met delta’s, en met de data kunnen twee dingen gebeuren.

Kleine, kortlevende extents kunnen inline in het journal record meeliften, en dan is het record de hele commit²⁷. Grotere of langerlevende extents gaan naar aparte out-of-line-segmenten, en dan leggen de docs de volgorde vast: het “final record with the deltas should be written only once the other blocks are persisted”²⁷. Dat zijn twee writes na elkaar, dezelfde vorm als de commit van BlueStore, eerst data en dan RocksDB.

FlashStore schrijft de data-extent en de WAL-unit tegelijk, zet de crc32c van de nieuwe data in het WAL-record zodat replay hem kan controleren, en bevestigt als beide duurzaam zijn²⁸. Eén trip naar het device, ongeacht de grootte.

Hoeveel dat uitmaakt hangt van je workload af, precies zoals in de vergelijking met BlueStore. Bij een lage queue depth, waar clients op elke write wachten, is een tweede trip echte latency. Onder belasting verbergt batching het meeste daarvan.

Ruimte Terugkrijgen

De andere helft van een log-structured ontwerp is het opruimen.

SeaStore op de gesegmenteerde backend schrijft alleen ooit naar open segmenten. Voordat een segment hergebruikt kan worden, moeten de levende blokken erin ergens anders herschreven worden, en het designdocument zegt wat dat kost: “we must ‘clean’ one byte of an existing segment for every byte written at steady state”²⁷. Het mengt een deel van dat opruimen door de lopende writes, om pieken te vermijden, en doet de rest op de achtergrond als de schijf rustiger is²⁷. De segmentgrootte is standaard 64 MiB³¹.

SeaStore heeft wel een tweede backend voor NVMe, de random block manager, waarvan de docs zeggen dat hij “Preferred for fast NVMe devices where overwrites are efficient enough that log structured updates aren’t worth the overhead” is²⁷. Het is niet de standaard. Je kiest hem met seastore_main_device_type³⁰.

FlashStore heeft geen segment cleaner. Geen. Een vervangen blok gaat terug naar de allocator van de shard zodra een checkpoint er voorbij is, wat elke vijf seconden gebeurt zolang er werk is dat nog niet weggeschreven is, of eerder als de WAL-ring halfvol is²⁸. Het designdocument wees een log-structured indeling ronduit af²⁸. Dat betekent niet dat er geen achtergrondwerk is: het voegt nog steeds boompagina’s samen en compacteert ze, en defragmenteert vrije ruimte, getemperd onder client-I/O²⁸. Maar het kopieert nooit je levende data om ruimte te maken.

Op flash, dat binnen de schijf al zijn eigen garbage collection draait, heb ik liever dat de OSD er niet nog een tweede bovenop draait. De eigen docs van SeaStore lijken het daarmee eens, gezien wat ze over de RBM-backend zeggen. Het verschil is dat FlashStore dat de enige optie maakte, en SeaStore het de niet-standaardoptie maakte.

Waar Elk Op Draait

Crimson houdt de breedte. De docs zeggen dat SeaStore “may not be suitable for traditional HDDs”, maar dat “Crimson will continue to support BlueStore ensuring compatibility with HDDs and slower SSDs”¹, en het designdocument van SeaStore noemt nog steeds interesse in HDD’s²⁷. De messenger weigert v1 ronduit, “ProtocolV1 is no longer supported”³², dezelfde keuze die FlashStore maakte³³. De docs raden “one of the latest available builds, as Crimson evolves rapidly” aan, wat in de praktijk CI-images van main betekent¹.

FlashStore versmalt alles tot NVMe met power-loss protection, en haalt daar zijn eenvoud uit³⁴. Wat precies de afweging is die de ADR van croit beschrijft, van de andere kant bekeken.

Twee Antwoorden Op Dezelfde Vraag

Beide projecten begonnen bij dezelfde waarneming: de klassieke OSD verspilt snelle hardware. Ze gaven heel verschillende antwoorden.

Het antwoord van Crimson is dat van de community. Herschrijf de OSD ter plekke, binnen Ceph, houd elke oude store en elke oude schijf werkend terwijl de nieuwe store volwassen wordt, en laat iedereen het werk zien terwijl het gebeurt. Dat gaat langzaam, en dat zie je. In Umbrella draait de standaard Crimson-OSD nog steeds BlueStore via een threadpool, zijn eigen pools zijn van de jouwe afgeschermd, en hem aanzetten betekent de woorden “unrecoverable data corrupting” intikken. Maar het is van iedereen die Ceph draait, en niemand kan het je afpakken.

Het antwoord van FlashStore is dat van de leverancier. Kies een smaller doel, NVMe met power-loss protection, gooi alles eruit wat alleen voor andere hardware bestond, en lever een store die instapt in de pools die je al hebt. Dat gaat sneller, en dat zie je ook. Maar het komt van één bedrijf, als read-only snapshots tot de eerste productierelease, en op een standaardcluster komt het binnen door de monitor te vertellen dat het BlueStore is.

Ik werk voor dat bedrijf, dus weeg wat volgt daarnaar. croit heeft de juiste technische gok gedaan voor all-flash-clusters. Crimson heeft de juiste gok gedaan voor Ceph als project. Dat is niet hetzelfde. Een project dat iedereen bedient kan HDD’s niet laten vallen. Een leverancier kan dat wel, en hoort dat te doen als dat is wat zijn klanten kopen.

Wat ik niet zou doen, is tussen de twee kiezen op basis van een benchmarkgrafiek van welke kant dan ook. De cijfers van Crimson hangen ervan af welke van zijn drie stores er draaide; die van FlashStore komen uit croits eigen lab. Beide projecten publiceren hun designdocumenten. Lees ze, zet dan allebei op de schijven die je echt zou uitrollen en draai je eigen workload. Degene die nog steeds doet wat zijn documenten zeggen als het jouw data is die op het spel staat, is degene waarop het wachten waard is.