Daniel Botha argumenta que, ao construir infraestrutura, o objetivo deve ser uma solução simples e confiável, como um pacote de espaguete de US$ 1, e não uma solução engenhosa. Quando o trabalho no Sprites começou, a equipe não encontrou um sistema de arquivos adequado pronto para uso e construiu o seu próprio. Esse design era engenhoso, e foi exatamente por isso que a equipe passou a não gostar dele. Este post apresenta seu substituto, o Sprites Block Device (SBD).
A raiz do disco de um Sprite continua sendo armazenamento de objetos, e não o drive NVMe do servidor onde ele roda. É isso que permite que um Sprite entre em suspensão, acorde em outro servidor e ainda encontre seus arquivos. Como os armazenamentos de objetos não conseguem alterar uma parte de um objeto, algo precisa traduzir edições de arquivos no lugar em gravações de objetos inteiros. No lançamento, esse papel era desempenhado por uma versão muito modificada do JuiceFS, apoiada em um armazenamento de metadados SQLite reescrito e mantido durável com o Litestream. Ele guardava uma única imagem de disco de 100 GB com ext4 dentro, e os checkpoints eram rápidos porque em sua maioria apenas movimentavam metadados.
Conforme o uso crescia, surgiram rachaduras. O sistema dependia de dois bancos de dados com durabilidade separada, um para metadados de blocos e outro para checkpoints, e cada um podia estar correto enquanto o outro estava errado. Executar o JuiceFS no modo writeback significava que uma queda podia deixar metadados apontando para blocos que nunca foram enviados. A camada ext4 acima falhava nas verificações de checksum e passava para somente leitura, e os checkpoints, que compartilhavam os mesmos blocos, não conseguiam reparar o dano.
O SBD substitui esse design por uma abordagem mais convencional, com o objetivo de manter o mesmo comportamento simples e ganhar confiabilidade.
Fonte: Hacker News · Resumido por HeadlinesBriefing