Daniel Botha sostiene que, al construir infraestructura, el objetivo debe ser una solución simple y fiable, como una bolsa de espaguetis de 1 $, y no una solución ingeniosa. Cuando comenzó el trabajo en Sprites, el equipo no encontró un sistema de archivos adecuado listo para usar, así que construyó el suyo. Ese diseño era ingenioso, y precisamente por eso llegaron a no gustarle. Esta entrada presenta su reemplazo, el Sprites Block Device (SBD).
La raíz del disco de un Sprite sigue siendo almacenamiento de objetos y no la unidad NVMe del servidor donde se ejecuta. Esto es lo que permite que un Sprite se duerma, se despierte en otro servidor y aun así encuentre sus archivos. Como los almacenes de objetos no pueden cambiar una parte de un objeto, algo debe traducir las ediciones de archivos en el lugar en escrituras de objetos completos. Al lanzarse, ese papel lo cumplía una versión muy modificada de JuiceFS, respaldada por un almacén de metadatos SQLite reescrito y mantenido de forma duradera con Litestream. Almacenaba una única imagen de disco de 100 GB con ext4 dentro, y los puntos de control eran rápidos porque en su mayoría solo movían metadatos.
A medida que crecía el uso, aparecieron grietas. El sistema dependía de dos bases de datos con durabilidad independiente, una para los metadatos de los fragmentos y otra para los puntos de control, y cada una podía ser correcta mientras las otras estaban equivocadas. Ejecutar JuiceFS en modo de escritura diferida significaba que un fallo podía dejar metadatos apuntando a fragmentos que nunca se subieron. La capa ext4 superior fallaba entonces las comprobaciones de suma y pasaba a solo lectura, y los puntos de control, que compartían los mismos fragmentos, no podían reparar el daño.
SBD sustituye este diseño por un enfoque más convencional, con el objetivo de lograr el mismo comportamiento simple con mayor fiabilidad.
Fuente: Hacker News · Resumido por HeadlinesBriefing