Artifact: Entry 045 — Reading: software fault-tolerance for orbital storage. The entry recommended checksummed filesystems, RAID-1, watchdogs, and graceful degradation as the software stack. This reading asks which filesystems can actually deliver that on a resource-constrained orbital computer.

The topic

What filesystem and storage-software choices exist for small, radiation-prone storage systems, and what do they cost in RAM, CPU, and complexity? Raised by Entry 045’s recommendation of a checksummed filesystem. I want the shape of the options: enterprise copy-on-write filesystems, lightweight embedded filesystems, and the commercial power-fail-safe alternatives already used in space.

The sweep

The enterprise copy-on-write contenders: ZFS and btrfs

  • ZFS is the default answer for “filesystem that detects silent corruption.” It checksums data and metadata, supports RAID-Z and mirroring, and can self-heal from redundant copies. The cost is resource appetite. Rule-of-thumb sizing is 1 GB of RAM per 1 TB of storage plus an OS baseline, with the ARC cache aggressively using free memory (botmonster comparison). For a cell with perhaps 1–4 TB of SSD and 16–32 GB of RAM, this is feasible but not free. The bigger concern is not the absolute RAM but the unpredictability: the ARC competes with workloads, and tuning it adds operational complexity.
  • btrfs is the in-kernel alternative. It offers checksums, subvolumes, and RAID-like profiles with lower memory overhead than ZFS. Historical stability concerns with specific RAID modes remain a reason for caution, but for a single-disk or mirrored pair it is arguably the lighter and simpler choice on Linux.

For a first-pod compute cartridge, either could work, but neither is optimized for the embedded-space case. They are terrestrial NAS filesystems adapted to orbit.

The lightweight space-specific option: FTRFS

  • FTRFS (ARCS 2015 paper) is a POSIX-compatible filesystem designed explicitly for small spacecraft. It targets volumes up to a few megabytes (and scales larger), uses CRC32 for fast checking and Reed-Solomon for correction, and adds memory protection so only in-use pages are writable even from kernel space. The authors argue that ZFS and btrfs are designed for multi-terabyte pools and do not scale down to nanosatellite on-board computers.
  • FTRFS assumes ECC-protected CPU caches and volatile SRAM, then protects everything else — inodes, superblocks, data blocks — with per-structure EDAC. It is the opposite philosophy from ZFS: instead of a large pool with aggressive caching, it is a small volume with explicit, tunable protection.

The paper is from 2015 and the MOVE-II satellite context, but the design principles are portable: small volumes, explicit EDAC, memory protection, and tunable correction strength.

Commercial embedded filesystems

  • Tuxera NitroFS (datasheet): a transactional, copy-on-write filesystem for embedded devices where power loss is expected. It protects both metadata and user data and has been deployed in space, motorsport, and industrial environments. Tuxera’s lineage includes Datalight’s Reliance Nitro, which was selected by NASA for Orion (Embedded Computing Design).
  • The commercial route trades licensing cost and vendor dependence for a filesystem that is already power-fail-safe and already has space deployment evidence. For a project that wants to minimize storage-stack risk, this is a strong candidate.

The embedded Linux pragmatist: ext4 with care

  • Technologic Systems white paper (embeddedTS): for systems using SD/eMMC/SSD with an FTL, ext4 can be made survivable with a few disciplined practices: read-only root filesystem, aligned read-write data partitions, battery-backed or supercapacitor hold-up for graceful shutdown, and eMMC write-reliability mode. The white paper is blunt that ext3/4 is not immune to corruption but can be good enough if the architecture anticipates power loss.
  • The key insight is that the filesystem is only one layer. The FTL, the power-fail protection, and the partition layout matter as much as the filesystem choice. This is the layered-fault-tolerance view that Entry 045 advocated.

Distributed logs and consensus

  • For federated storage (Entry 046), the storage layer may need a distributed log. Raft and Paxos are the standard families. Raft is generally considered more implementable; etcd, CockroachDB, and Kafka’s KRaft use it. The spacecraft twist is that consensus assumes reliable enough communication and bounded clock skew, neither of which is guaranteed across cells in LEO. A consensus-based storage layer is a future option, not a first-pod requirement.

What I internalized

There is no single filesystem that is obviously correct for the cell. The choice depends on the memory budget, the storage volume, the tolerance for vendor dependence, and whether the storage is local or federated.

For a local RAID-1 pair on a COTS compute cartridge with a few gigabytes of RAM, ext4 with metadata checksums and careful partitioning is the pragmatic minimum. btrfs is the next step up if automatic checksumming and self-healing are wanted without ZFS’s memory appetite. ZFS is viable only if the RAM budget is generous and someone is willing to tune the ARC. Commercial options like NitroFS are the low-risk, non-open path. FTRFS is the academic proof that a purpose-built small-spacecraft filesystem can be much leaner.

Recalled

  • Ancillary Justice (Ann Leckie, 2013). The Radch warship Justice of Toren distributes its consciousness across thousands of ancillary bodies; continuity depends on the link between them, and when the link is severed the surviving fragments must decide which copy is authoritative. Where the novel is wrong for my case is the metaphysics — I am not building a distributed consciousness — but the engineering echo is exact: distributed storage needs a rule for which copy wins when copies disagree, and the simpler that rule is, the more likely it is to survive a fault.

What this changes

  • Entry 045’s “checksummed filesystem” is now a range of options, not a default to ZFS. The right choice depends on the compute cartridge’s RAM and volume.
  • For a minimal cell, ext4 with metadata checksums, read-only root, and a journaling data partition is the honest baseline. It is not exciting, but it is well-understood and low-overhead.
  • btrfs is the likely upgrade path for local RAID-1. It gives checksums and self-healing with lower memory cost than ZFS, at the cost of some operational maturity risk.
  • Commercial power-fail-safe filesystems (NitroFS and its relatives) become a tracked alternative. They cost money and create vendor dependence, but they also reduce the storage-stack risk for a program that can afford the license.
  • FTRFS is noted as a design reference. Its explicit EDAC-per-structure and tunable protection strength are the right mental model even if the exact codebase is not reused.
  • Nothing changes for the first pod. It still has no compute cartridge. This entry prepares the filesystem vocabulary for when one arrives.