SBD：家里就有个文件系统
内容提要
Fly.io 为 Sprites 自研的 JuiceFS 文件系统因元数据与数据分离、多套账本需同步，导致检查点丢失和磁盘损坏。经大规模测试验证后，团队将其替换为 Sprites Block Device（SBD）：通过 NBD 将对象存储呈现为块设备，元数据与数据块同存于桶中，由单一守护进程管理，检查点改为卷快照，恢复如同重启。SBD 更简单可靠，已成为 Sprites 默认文件系统。
延伸解读
从“自制意面”到“超市意面”：基础设施的简化哲学
文章用“自制意面”比喻过度复杂的自研文件系统，强调基础设施应追求简单可靠而非炫技。JuiceFS 方案需要维护元数据数据库、检查点数据库和磁盘镜像三套账本，任何一套出错都可能导致数据不一致。SBD 将元数据与数据块同存于对象存储，仅用一个守护进程管理，大幅降低了同步复杂度。这提醒我们：当系统需要大量修复工具来维持运行时，或许该重新审视设计本身。
检查点机制的简化：从克隆到快照
在 JuiceFS 下，检查点是磁盘镜像的写时复制克隆，多个检查点共享底层数据块，一旦某个块丢失，所有检查点都会受影响。SBD 改为对整个卷做块快照并记录版本号，恢复时只需回卷并重新挂载，成本接近重启。这种“笨”办法反而更可靠，因为每个检查点独立完整，不依赖共享块链。对于需要频繁创建检查点的 Agent 场景，这种设计能避免故障扩散。
可靠性验证：大规模狗粮测试暴露的隐患
Fly.io 用自动化测试工具驱动 400 个 JuiceFS Sprite 进行了约 5000 次写、检查点、休眠、唤醒和恢复循环，结果有部分 Sprite 永久失去检查点能力。问题根源在于写回模式下元数据先记录、数据后上传，机器在中间被杀死就会产生指向不存在块的元数据。SBD 通过读取时校验每个块、守护进程崩溃则整体重启来保证磁盘可信，虽然仍可能出错，但会明确停止而非带病运行。
Q&A
Fly.io 为什么放弃自研的 JuiceFS 文件系统？
JuiceFS 将元数据与数据分离，需要维护多个账本（元数据数据库、检查点数据库等），这些账本分别持久化，容易不一致。在写入回写模式下，元数据可能指向不存在的块，导致文件系统损坏、检查点丢失。大规模测试中，部分 Sprite 永久失去检查点能力。
SBD 是什么？它是如何工作的？
SBD（Sprites Block Device）是 Fly.io 为 Sprites 自研的块设备文件系统。它通过 NBD 将对象存储桶呈现为块设备，元数据与数据块同存于桶中，由单一守护进程 sbd serve 管理。Sprite 将该设备格式化为 ext4 并挂载，守护进程处理内核的块读写，利用本地缓存并异步上传脏块。
SBD 的检查点机制和恢复过程是怎样的？
SBD 的检查点是整个卷的块快照，带有版本号，记录在 SBD 自己的检查点目录中。恢复时，卸载文件系统，将卷回滚到指定版本，再重新挂载，耗时约等于一次重启。每个检查点知道所属卷版本，确保单一事实来源。
SBD 如何保证数据可靠性？
SBD 会校验从对象存储读回的每个块是否与写入时一致。如果 SBD 自身崩溃，整个 Sprite 会重启，因为干净重启是回到可信磁盘的唯一方式。此外，SBD 在需要保证数据落盘时执行刷新操作。
SBD 相比 JuiceFS 有哪些优势？
SBD 更简单可靠：只有一个守护进程和一个桶，无需维护多个账本同步；检查点是块快照而非写时复制克隆，恢复简单；元数据与数据块同存，避免不一致；经过大规模测试验证，可靠性比 JuiceFS 高几个数量级。
如何迁移现有的 Sprites 到 SBD？
对于 10/6 之前创建的 Sprites，可以按照官方提供的迁移说明进行操作。文章提到有迁移指南，但未给出具体步骤。
