FlashStore frente a BlueStore de Umbrella: lo que croit cambió bajo el OSD

Aviso desde el principio: trabajo para croit, que ha escrito esto. Todo lo que sigue está leído del código fuente y la documentación publicados de los dos proyectos, enlazados al pie de la página, y donde la documentación de croit contradice el código de croit, lo digo.

El OSD de Ceph, reescrito desde cero

croit ha publicado ceph-rust, un OSD de Ceph escrito desde la nada en Rust, con un almacén de objetos propio llamado FlashStore en lugar de BlueStore¹. Entró en vista previa pública el 9 de noviembre de 2026, con la disponibilidad general prevista para el primer trimestre de 2027¹. No es un fork. La regla del propio proyecto es que el C++ de Ceph se lee como referencia, se redacta como especificación con palabras de croit y luego se implementa a partir de la especificación².

Lo que importa a quien opera Ceph es la promesa de sustitución directa. Tus monitores, tus managers, la CLI ceph y tus clientes se quedan como están. Un OSD FlashStore entra en los mismos pools y los mismos placement groups que los OSD clásicos que ya están ahí, y cambias un disco cada vez¹.

Así que la pregunta para un operador es práctica. Si cambias un OSD BlueStore por uno FlashStore, ¿qué es distinto por debajo? No en abstracto, y no frente a un BlueStore de una charla de congreso de hace años. Frente al BlueStore que de verdad ejecutas hoy si estás en Umbrella, Ceph 21.2.0, que es la versión contra la que se compila y se prueba FlashStore¹.

Esa es la comparación aquí, y solo esa. El BlueStore de Umbrella tal como lo describen su código y su documentación, frente a FlashStore tal como lo describen su código y sus registros de decisiones.

Afecta a cualquiera con clústeres Ceph sobre NVMe, y a cualquiera que haya mirado cuántos núcleos le cuesta un OSD. A los clústeres de HDD no les afecta en absoluto, y el motivo sale más abajo.

Qué hay en el repositorio

El repositorio es una instantánea de solo lectura del árbol de desarrollo privado de croit. Sin gestor de incidencias, sin pull requests; las actualizaciones llegan como nuevos commits de instantánea¹. Eso corresponde a la fase de preview, que existe para recoger las opiniones de la comunidad mientras croit pasa internamente sus casos de prueba de producción antes de marcarlo como seguro para su uso. El desarrollo se abre tras la primera versión de producción, como en la mayoría de los proyectos de código abierto respaldados por una empresa. Esta tiene fecha del 10 de noviembre de 2026 y lleva unas 700.000 líneas de Rust y más de 450 registros de decisiones de arquitectura, los ADR, que son los documentos breves donde queda escrito por qué se tomó cada decisión de diseño.

Los ADR son la parte útil para una comparación como esta. Son directos, llevan mediciones y recogen lo que se probó y se tiró además de lo que se quedó.

Conviene conocer las licencias antes de construir nada encima. El daemon y las herramientas son LGPL-3.0-only, las bibliotecas cliente son MPL-2.0 y la documentación es CC-BY-SA-4.0³. Las bibliotecas cliente pasaron a MPL para que un programa en Rust pueda enlazarlas estáticamente sin las obligaciones de reenlazado que trae la LGPL, lo cual es una decisión razonada y está escrita como tal³.

Vista previa significa lo que dice. El propio README de croit dice que es para pruebas y evaluación y «not yet recommended for production data»¹. Yo tampoco pondría datos de clientes encima todavía, y nada en el resto del artículo cambia eso.

Dos almacenes, uno al lado del otro

Un OSD tiene dos mitades. La mitad de arriba habla el protocolo de Ceph, es dueña de los placement groups, hace peering, recupera y hace scrub. La mitad de abajo, el almacén de objetos, convierte «escribe estos bytes en este objeto» en bloques en un disco y promete que sobreviven a un corte de corriente.

BlueStore es la mitad de abajo de Umbrella. Su documentación dice que «reads and writes to the devices directly in a ‘raw’ fashion»⁴, y que consume «raw block devices or partitions»⁵. Los datos de los objetos van directos al dispositivo de bloques. Todo lo demás, los metadatos de los objetos, el OMAP y su propia contabilidad, va a una base de datos clave/valor RocksDB embebida, y RocksDB se apoya en BlueFS, un pequeño sistema de ficheros que BlueStore lleva para ella⁵⁶.

FlashStore se quita todo eso de encima. Un único B+tree copy-on-write por shard del almacén lo guarda todo: colecciones, metadatos de objetos, atributos extendidos, mapas de extents, OMAP, el PG log, contadores de referencias y hasta el propio bitmap del asignador⁷. A su lado hay un anillo de registro de escritura anticipada (WAL) de tipo redo y la región de datos. No hay RocksDB, no hay BlueFS y no hay una segunda base de datos que afinar.

La otra gran diferencia es el propio disco. BlueStore pasa por la capa de bloques del kernel hacia lo que le des. FlashStore habla con el NVMe o bien con SPDK, un driver en espacio de usuario que le quita el dispositivo al kernel mediante vfio, o bien a través del kernel con io_uring⁸⁹. SPDK es el backend por defecto. El nivel io_uring es el que funciona donde vfio no, y como tal es en el que acabé en el montaje en Proxmox.

Dónde viven los metadatos

Empieza por aquí. Casi todo lo demás sale de esto.

Los valores por defecto del lado de BlueStore salen directamente del fichero de opciones de Umbrella: RocksDB como backend clave/valor, el asignador hybrid y checksums crc32c⁶¹⁰¹¹. El checksum de metadatos de BlueStore «is handled by RocksDB and uses the crc32c algorithm», y los datos le cuestan «a checksum value (usually 4 bytes) for every 4 KB block of data»⁴. En checksums los dos almacenes coinciden. FlashStore guarda un crc32c por cada bloque de 4 KiB en el mapa de extents y lo verifica al leer⁷.

Donde se separan es en la estructura. El RocksDB de BlueStore es un árbol LSM, así que escribe y luego compacta en segundo plano, reescribiendo datos que ya había escrito. El árbol de FlashStore se actualiza por copy-on-write y se vuelca a disco en checkpoints: cada cinco segundos mientras haya algo sin persistir, o cuando el anillo del WAL llega a la mitad⁷.

Otra consecuencia es que FlashStore no tiene dispositivo rápido para metadatos, porque no lo necesita. En Umbrella puedes poner block.db en un disco más rápido, y BlueStore pondrá «as much metadata as it can on the DB device»⁴. FlashStore da por hecho que todos los discos ya son NVMe rápidos, y guarda sus metadatos junto a los datos. Es una suposición razonable para el hardware al que apunta. También es exactamente la razón de que no haya nada para HDD.

El OMAP es el único sitio donde FlashStore se cubre las espaldas. El árbol es lo predeterminado, pero un almacén se puede preparar con un motor LSM propio de croit, o con RocksDB, detrás de la misma interfaz¹². El motor de OMAP se elige al crear el almacén. No se cambia en un OSD en marcha.

Una escritura de 4 KiB, de dos maneras

Esta es la diferencia que notarías, si es que notas alguna.

Toma una escritura de 4 KiB en un objeto en Umbrella con la configuración por defecto sobre flash. bluestore_min_alloc_size_ssd es 4 KiB y bluestore_prefer_deferred_size_ssd es 0, así que una escritura entera de 4 KiB va a 4 KiB recién asignados¹³¹⁴. BlueStore envía esa escritura de datos, y la transacción se queda en STATE_AIO_WAIT hasta que el disco dice que ha terminado¹⁵. Solo entonces se encolan los metadatos para RocksDB, y el hilo de sincronización de RocksDB vacía el dispositivo de bloques antes de hacer commit¹⁶. Después el cliente recibe su confirmación.

Dos viajes al dispositivo, en serie.

FlashStore envía los dos a la vez. Los datos van a un extent nuevo de 4 KiB y la unidad de WAL va al anillo del log en paralelo. El registro del WAL lleva el crc32c de cada bloque de datos nuevo, así que el replay tras un fallo puede saber si los datos llegaron⁷. La confirmación sale, en orden del log, cuando los datos, la unidad de WAL y todas las transacciones anteriores son duraderos⁷. La justificación del propio ADR para el diseño es «parallel commit gives one device latency per ack»⁷.

Dos cosas mantienen esto en su sitio. En un OSD con carga los dos almacenes agrupan commits, así que bajo carga la diferencia es menor que una latencia de dispositivo por escritura. Y un viaje al dispositivo en NVMe son unas pocas decenas de microsegundos. Que lo notes depende de si tus clientes esperan por latencia con poca profundidad de cola, como suelen hacer las bases de datos sobre RBD, o empujan rendimiento, donde se diluye.

croit intentó ir más lejos, a una sola escritura de dispositivo por transacción, al estilo ZFS. Lo construyeron, lo midieron y lo tiraron: la ganancia solo aparecía con profundidad de cola 1 y la complejidad no compensaba¹⁷. Eso lo valoro más que cualquier gráfico de benchmark. Es un registro de decisión que dice «lo construimos y no merecía la pena», en público.

La escritura de menos de 4 KiB

La escritura más pequeña es donde los dos se separan de verdad.

Pongamos que un cliente sobrescribe 512 bytes en medio de un bloque que ya tiene datos. Umbrella sigue usando por defecto su ruta de escritura original; bluestore_write_v2, la reescritura, viene desactivada¹⁸. En esa ruta, una escritura más pequeña que min_alloc_size en un bloque que ya está asignado se convierte en una escritura diferida¹⁹. Los datos viajan dentro de la transacción de RocksDB como una clave con el prefijo L, y solo van a su sitio real después de que al cliente se le haya dicho que están a salvo²⁰²¹.

Así que los datos llegan al disco dos veces. La documentación de Umbrella no lo esconde: «writes smaller than min_alloc_size must first pass through the BlueStore WAL»⁴.

FlashStore nunca sobrescribe datos vivos en su sitio, y punto⁷. Los objetos de hasta 2 KiB van más allá y viven enteros en el árbol, así que una escritura de WAL es todo el commit⁷.

Eso también significa que FlashStore no tiene cola de escrituras diferidas que vaciar, ni replay diferido al montar, ni claves L que limpiar. Lo paga en otro sitio: los bloques liberados se retienen hasta el siguiente checkpoint, así que el espacio liberado va con hasta un intervalo de checkpoint de retraso⁷.

Hilos frente a núcleos

La mitad de arriba del OSD difiere igual de mucho.

El ceph-osd de Umbrella es un servidor de hilos clásico, y cada número de la mitad izquierda del diagrama de abajo es uno de sus valores por defecto sobre flash²². Una operación cruza varios de esos pools por el camino. Comparten estado detrás de locks.

FlashStore mantiene todo el recorrido en un único núcleo fijado que hace polling, desde la tarjeta de red hasta el disco y vuelta²³. Cada placement group pertenece exactamente a un núcleo, y también todo lo que toca el PG: «no locks, no atomics, no shared mutable state»²⁴. El tráfico entre núcleos va por anillos de un solo productor, y la propiedad del mensaje viaja con él.

El almacén sigue el mismo reparto. flashstore_store_shards usa por defecto un shard por núcleo, cada uno con su propio anillo de WAL, árbol y asignador, y un PG vive en exactamente un shard²⁵⁷. BlueStore es un almacén por OSD con un RocksDB.

Tiene un precio, y el ADR lo dice: «idle cores burn CPU (accepted; optional adaptive sleep later)»²³. Un trabajo posterior añadió reposo adaptativo y esperas temporizadas al dispositivo para que un núcleo no gire durante toda la latencia del dispositivo con poca profundidad de cola⁸, pero el principio sigue en pie, y flashstore_cores vale 8 por defecto cuando no fijas un rango²⁵. A FlashStore le das núcleos enteros.

En un nodo de almacenamiento dedicado, no hay problema. En una máquina hiperconvergente donde esos núcleos también corren VM, es la primera cuenta que hay que hacer.

El disco tiene que cumplir su promesa

BlueStore está escrito para apañarse con un disco que miente sobre cuándo están a salvo los datos. FlashStore se niega a tratar con ese disco.

El lado de BlueStore es el hilo de sincronización kv ya citado¹⁶. El lado de FlashStore es el ADR de durabilidad y la comprobación del host: PLP significa que el disco no declara caché de escritura volátil, así que una finalización significa que los datos están en un medio estable²⁴²⁶.

Para su objetivo es la decisión correcta, pero ten claro lo que deja fuera, porque casi todo el NVMe de consumo tiene caché volátil y no tiene PLP, y lo mismo pasa con bastante material «de centro de datos» que se vende por precio. Sin PLP, no hay FlashStore. Pienses lo que pienses de lo demás.

En qué no funciona FlashStore

Pon los requisitos uno al lado del otro y el mercado al que apunta está claro.

La columna de BlueStore es de Umbrella: ceph-volume cifra volúmenes lógicos «using dmcrypt by specifying the --dmcrypt flag»²⁷, y ms_bind_msgr1 sigue valiendo true por defecto²⁸. La columna de FlashStore sale de su referencia de hardware y de su decisión de alcance²⁶²⁹.

Dos de esas filas merecen más que una línea de tabla.

El cifrado en reposo queda fuera, con un motivo: SPDK se salta dm-crypt, y no está previsto cifrar dentro del almacén. La respuesta del ADR son discos NVMe autocifrados, o cifrar por encima del almacén, en el cliente o en RGW²⁹. Si tienes un requisito de cumplimiento que nombra dm-crypt en el OSD, hoy eso te para en seco.

msgr1 queda fuera como riesgo aceptado. Los clientes de kernel anteriores a 5.11 y los librados anteriores a Nautilus no pueden hablar con un OSD FlashStore en absoluto²⁹. La mayoría de las instalaciones hace tiempo que pasaron eso. Algunas no, y es la vieja máquina olvidada del rincón la que se entera.

Le dice al monitor que es BlueStore

Esta es la que va a pillar a la gente.

Por defecto, un OSD FlashStore arranca y les dice a los monitores osd_objectstore=bluestore³⁰. No se esconde. Añade al lado sus propias claves flashstore_version y flashstore_build³⁰. El motivo es la compatibilidad: un monitor de Umbrella solo permite funciones como las sobrescrituras EC en un pool cuando todos los OSD del pool declaran BlueStore, y los módulos del manager como Prometheus y telemetry toman decisiones según ese mismo valor³⁰. El ADR deja claro que bluestore aquí «is a compat value for mon/mgr feature gates, not a product name»³⁰.

Hay un interruptor, flashstore_report_objectstore=flashstore, que lo renombra todo: los metadatos, las claves bluestore_bdev_*, el perf logger, los comandos tell y los códigos de salud BLUESTORE_*. Necesita monitores parcheados, y el valor por defecto sigue siendo bluestore²⁵³⁰. Las compilaciones de Ceph de la propia croit llevan esos parches, así que en ellas FlashStore se declara flashstore y nada de lo que sigue aplica. El nombre bluestore está para los monitores y managers estándar que hoy corren en producción.

Entiendo por qué. Un control del monitor basado en una cadena es diseño de Ceph, no de croit, y negarse a decir bluestore desactivaría funciones en un clúster sin parchear. Ahí está la trampa en un clúster estándar. Cada dashboard, cada script de inventario y cada ceph osd count-metadata osd_objectstore que ejecutes contará los OSD FlashStore como BlueStore. Durante una migración, justo cuando más necesitas saber qué OSD es cuál, el campo obvio no te dice nada.

Así que mira flashstore_version en ceph osd metadata, no osd_objectstore. Ponlo en tu runbook antes de que entre el primer OSD FlashStore.

Los mismos mandos, otro comportamiento

FlashStore lee muchas de las opciones que Ceph ya tiene, y eso es sobre todo una buena noticia. No todas las opciones significan lo que significaban en Umbrella, y las que no son donde un clúster afinado se lleva la sorpresa.

La compresión coincide. El modo por defecto de BlueStore es none y su algoritmo por defecto es snappy³²³³; FlashStore implementa los mismos cuatro modos, las mismas opciones de pool y los mismos trozos de 64 KiB, y el ADR señala que un trozo de 64 KiB comprimible al 50% ocupa lo mismo en los dos³⁴. No siempre iba a estar. El fichero del ADR todavía se llama no-store-compression, por la decisión original, revocada cuando croit fijó como mandato la paridad funcional completa con el Ceph clásico³⁴.

La memoria no tiene paridad. Umbrella autoajusta las cachés de BlueStore contra osd_memory_target mientras funciona³⁵³⁶. FlashStore lee el objetivo una vez al arrancar, lo reparte entre sus shards, y un cambio hecho con ceph config set se aplica en el siguiente reinicio³⁷. Tampoco mantiene el proceso dentro del objetivo: hugepages, buffers de red y estado de los PG quedan fuera³⁷. Así que osd_memory_target dimensiona las cachés de FlashStore. No limita la memoria del OSD como puede que estés acostumbrado.

Y mClock se ignora sin más³⁷. No se rebaja. Se ignora. No hay planificador de operaciones que configurar, porque cada núcleo es dueño de sus PG. La recuperación y el backfill se frenan en su lugar con osd_max_backfills, osd_recovery_max_active y las opciones de sleep³⁷. Si afinaste perfiles de mClock para una reconstrucción en Umbrella, esos ajustes no hacen nada en un OSD FlashStore, y nada te va a avisar.

No hay conversión, en ningún sentido

No puedes convertir un OSD BlueStore en uno FlashStore. La guía de migración de croit lo dice claramente: «There is no in-place conversion of a BlueStore device»³⁸. Ofrece dos órdenes en su lugar, y los dos son backfill³⁸:

Y no se vuelve más fácil después. El formato en disco de FlashStore tiene bits de características, y un montaje rechaza un bit desconocido: «Every format change means mkfs; unknown bits refuse mount (no downgrade)»⁷. Así que un cambio de formato en una versión posterior de FlashStore es el mismo vaciar y rellenar que la primera migración.

Hay una cosa que la documentación tiene mal. La lista de comprobación de la guía de migración dice que te asegures de que «the pools do not use erasure coding on croit-flashstore-osd OSDs»³⁸. La guía de erasure coding de la misma instantánea dice que FlashStore sirve por defecto los pools EC heredados, y el valor por defecto del propio código para EC optimizado es all³⁹⁴⁰. Una de las dos está desactualizada, y por el código es la guía de migración. Aun así me leería entera la guía de EC antes de mezclar pools EC entre los dos tipos de OSD, porque el fallo que describe es un PG que se degrada y un backfill que se atasca³⁹.

Un almacén hecho para los discos que de verdad compramos

BlueStore se hizo para funcionar en todo. Discos que giran, SSD baratos, NVMe, particiones, LVM, volúmenes cifrados, un dispositivo DB rápido delante de un dispositivo de datos lento. Esa amplitud es la razón de que se convirtiera en el predeterminado, y es la razón de que lleve una ruta de escritura diferida, un vaciado antes de cada commit, una base de datos clave/valor sobre un sistema de ficheros propio y un pool de hilos para que todo eso siga moviéndose. Cada una de esas piezas existe porque algún disco en algún sitio la necesitó.

FlashStore empieza por el otro extremo. Da por hecho que el disco es NVMe, que tiene protección ante cortes de corriente y que es lo bastante rápido como para que ahora el cuello de botella sea el software. Luego tira todo lo que solo existía por los otros discos.

¿Es la apuesta correcta? Para clústeres nuevos todo flash, montados con NVMe empresarial de verdad, sí. Ahí es hacia donde van los clústeres Ceph, y un OSD que gasta sus núcleos en locks, traspasos y una base de datos compactando a su espalda está pagando, cada segundo de cada día, por una flexibilidad que un clúster así no va a usar nunca.

Pero la apuesta tiene un coste, y prefiero que lo veas antes de entrar en ella. Renuncias a HDD, dm-crypt, msgr1, el ajuste de memoria en vivo y mClock. En un clúster estándar te llevas un OSD que les dice a tus monitores que es BlueStore, porque los monitores y managers actuales no le dejan otra; las compilaciones de croit no lo necesitarán. Te llevas un formato al que no puedes convertir, y entre cuyas versiones tampoco puedes convertir. Y te lo llevas en vista previa, de un único proveedor, que resulta que me tiene en plantilla.

Así que toma el código fuente como la prueba, no este artículo ni el informe de benchmarks de croit. Los registros de decisiones son públicos y dicen qué se midió y qué se tiró. Léelos, monta un clúster de pruebas con el material que de verdad desplegarías y mide tu propia carga. Si hace en tus discos lo que dicen los ADR, lo sabrás. Si no lo hace, también lo sabrás, y te habrás enterado en un clúster de pruebas.