Artifact: Entry 019 — Reading: orbital compute precedents. The entry identified storage as the concrete failure mode: HPE Spaceborne Computer-2 saw roughly a 45% SSD failure rate. This reading asks what the storage community knows about why, and what can be done about it.

The topic

How do solid-state drives and storage systems fail in LEO, and what hardening practices actually help? Raised by Entry 019’s conclusion that storage reliability is the highest-priority compute-subsystem risk. I want the shape of the problem: NAND failure modes, controller behavior, firmware vulnerabilities, ECC, redundancy, and radiation assurance.

The sweep

Flight evidence: HPE Spaceborne Computer

  • MDPI review of space-based data centers (MDPI): confirms the 45% SSD failure rate on HPE Spaceborne Computer-2 and contrasts it with the Axiom/AWS Snowcone experiment, which reportedly survived without the same storage casualty rate. The difference is attributed less to orbit and more to how each system handled radiation-induced single-event effects in NAND flash and the firmware that manages it.
  • SNIA presentation on storage in space (SNIA): describes Spaceborne Computer-1 launching with twenty COTS SSDs and the disappointing durability observed. The presentation covers failure analysis of returned SSDs and the mitigations built into Spaceborne Computer-2, including storage-design concepts of operations, backup, and disaster recovery. The key point is that storage is not just a memory problem; it is a system-design problem involving firmware, power, thermal cycling, and recovery procedures.

NAND flash vulnerabilities in orbit

  • ATP Electronics on LEO SSD challenges (ATP): summarizes the radiation environment for LEO storage — total ionizing dose (TID), single-event effects (SEEs), and the susceptibility of dense NAND flash and SSD controllers. Modern high-density TLC/QLC NAND is more vulnerable than older SLC because the stored charge per cell is smaller and the voltage margins are tighter.
  • Future Memory Storage proceedings (Future Memory Storage): outlines typical LEO mission requirements — 5-year life, TID around 15 krad, SEE from ~64 MeV protons — and asks whether TLC-based SSDs can meet them. The expected answer is conditional: with the right controller, firmware, power cycling, and status monitoring, COTS SSDs can be made to survive, but uncorrected bit errors and controller hangs must be expected and handled.
  • NASA NEPP SSD radiation assurance (NASA NEPP): a radiation-evaluation program for currently available memory assemblies using heavy-ion beams. The work emphasizes that radiation assurance must be active and at the assembly level, not just a parts-level rating, because the interaction between NAND, controller, and firmware determines the failure mode.

Mitigation strategies

  • Software hardening and watchdogs: detect power anomalies, thermal excursions, and unresponsive controllers; power-cycle or failover to a spare. HPE’s approach on SBC-1/2 was to recover rather than prevent.
  • ECC and redundant storage: end-to-end ECC, RAID-like mirroring across independent drives, and file-system checksums. The goal is not to prevent bit errors but to prevent them from becoming silent data corruption.
  • Controller and firmware robustness: standard enterprise SSD firmware is not designed for continuous low-level single-event rain. Custom firmware or radiation-tolerant controllers can degrade gracefully instead of hanging.
  • Physical design: shielding reduces TID;DRAM-less or minimal-component designs reduce SEL risk; power-fail protection circuitry prevents corruption during unexpected resets.

What I internalized

The 45% SSD failure rate is not a mysterious space curse; it is the expected outcome of running enterprise storage firmware in an environment full of single-event effects. The NAND cells are vulnerable, but the more dangerous failure mode is the controller or firmware deciding it cannot proceed. A storage cartridge that hangs is worse than one that flips bits, because a hung cartridge takes the compute node down with it.

The good news is that the mitigations are known. The bad news is that they are not free. Redundancy costs mass and power. Custom firmware costs development. Radiation assurance costs test time. The cell cannot simply buy a space-rated SSD and assume the problem is solved; it must design a storage subsystem that assumes failure and recovers from it.

Recalled

  • 2001: A Space Odyssey (Arthur C. Clarke, 1968). HAL’s memory-error paranoia is the fictional extreme of a single component corrupting a mission. Where the novel is wrong for my case is the monoculture: HAL is one computer with one memory bank, and the error propagates into catastrophic behavior. The cell’s storage design is the anti-HAL — not because it uses better components, but because it assumes components will fail and routes around them. The useful echo is narrower: even a perfectly specified SSD can be undone by a controller firmware edge case, and the architecture must assume that edge case will occur.

What this changes

  • Entry 019’s storage-risk item is now concrete. The failure mode is not generic “radiation”; it is NAND/controller/firmware vulnerability to single-event effects, and the high failure rate is from enterprise COTS SSDs without mitigation.
  • The cell’s compute cartridge needs a storage subsystem, not just an SSD. Minimum: two independent drives, end-to-end ECC, firmware that degrades gracefully, and a hot-swap/replacement path that does not require downing the cell.
  • Software hardening remains the primary philosophy, but it must explicitly include storage. Power monitoring, thermal throttling, and error recovery are necessary but not sufficient; the storage firmware must be part of the monitored boundary.
  • A radiation-assurance test plan is added to the compute-cartridge qualification. Assembly-level heavy-ion testing of the chosen SSD, or equivalent test evidence, becomes a gate before the cartridge is treated as production rather than experimental.