Fly.io has introduced a new storage architecture for Sprites, its persistent computing environments, after reliability testing exposed weaknesses in the customized filesystem stack used at launch. The replacement, called Sprites Block Device, or SBD, presents object storage to Linux as a block device and lets the standard ext4 filesystem manage files.

The company said Sprites must retain their disks when an instance sleeps and later resumes on another server. That requirement makes local server storage unsuitable as the durable source of truth. Fly.io therefore keeps each Sprite’s state in object storage, while caching active data near the machine running the workload.

The first design used a modified JuiceFS installation. It stored a 100-gigabyte disk image containing ext4, while a SQLite metadata database recorded how chunks in an object bucket formed that image. A separate checkpoint database tracked image versions. This arrangement enabled fast copy-on-write checkpoints, but it also created several records that had to remain synchronized.

Fly.io described a failure mode in which JuiceFS metadata could point to a chunk that had not completed its upload before a machine stopped. A missing chunk could then cause ext4 checksum failures and force the filesystem into read-only mode. Because checkpoints shared chunks, restoring an earlier checkpoint did not necessarily avoid the missing data.

The company built an automated test harness that repeatedly wrote data, checkpointed, suspended, resumed and restored hundreds of Sprites while checking returned bytes. In roughly 5,000 cycles involving 400 JuiceFS-backed Sprites, some environments permanently lost checkpoint capability, prompting the redesign.

SBD removes the separate filesystem metadata database and disk-image layer. A daemon inside each Sprite serves block reads and writes over the Network Block Device interface, uses a local cache, uploads dirty blocks in the background and flushes them when durability is required. Metadata is stored in the bucket beside the blocks it describes.

Checkpoints become versioned block snapshots recorded in SBD’s own catalog. Restoring one unmounts ext4, rewinds the volume and mounts it again. SBD also verifies blocks fetched from object storage against what was written. If the daemon fails, Fly.io restarts the Sprite rather than continuing with storage it cannot verify.

Fly.io said extended internal testing and early design-partner use showed substantially better reliability. SBD will now be the storage system for Sprites, retaining familiar ext4 semantics while reducing the number of components that must agree for a disk to remain usable.