Documentation
Compiler Internals
On Hardware
Storage on Metal

Storage on Metal

A freestanding target owns its own persistence. There is no filesystem underneath a sealed image, and the substrate spectrum this section describes reaches parts whose storage is a region of flash behind the MMIO seam. This page describes how our design supplies durable state on such targets, and how the same structures continue upward to hosted and clustered deployments. The normative definitions are in the spec: Modular Blob Storage for the substrate and Namespace Storage for the layer above it. This page is the orientation, and those chapters are the contract.

The Sealed Floor

Modular Blob Storage (MBS) is the durable rung of the lifetime lattice: values that outlive the process, at known locations, under an access policy. Its shape is set by what a constrained target can afford. An MBS instance is a fixed set of slots sized at provision time, placed in static storage with no heap anywhere in the path. Records are written and read whole at the API boundary. Crash consistency additionally requires a target primitive or commit protocol that makes each accepted update recover as an old or new valid record after power loss. Whole-record calls do not make flash programming atomic; erase/program granularity, torn writes, and recovery must be handled below that API. Addressing is by opaque, store-issued handles, with a small secret-free index for selection. The design seals records at rest with device-bound key custody. Confidentiality alone does not provide integrity, freshness, or rollback protection. The target must implement the specified authentication and recovery contract, including nonce/key handling and the treatment of replayed or interrupted writes; a ciphertext-bearing medium still has security-relevant behavior.

The spec treats durability as a coeffect on the Program Semantic Graph: survives-power-loss, atomic-write, and sealed travel with the value through the middle end and are committed at target binding, where the pathway selects the non-volatile medium, the atomic-write primitive, and the sealing capability. A target without those capabilities is required to fail binding under the design. This is a specification requirement, not evidence that a complete RA6M5 storage backend or all of its rejection paths already exist. The September 2026 HelloBlinky milestone does not implement persistent storage.

The Ledger Above It

A filesystem adds an open namespace, a path hierarchy, run-time growth, and a mutable metadata tree. The Namespace Storage draft supplies the first rungs of that ladder in a form the same constrained targets can afford, and its central decision is that the namespace keeps no mutable tree. Namespace state is the fold of an append-only, hash-linked ledger of change entries. Checkpoints of the fold are compressed, sealed, and written back as ordinary MBS records, and a single root record binds the segment set to its checkpoint position with one update whose atomicity must be supplied by the MBS target contract. Recovery must never select a root referring to uncommitted segments.

Storing the namespace’s own cold metadata in the blob substrate keeps the design at one persistence mechanism for the target. Append-only logical updates can simplify recovery and audit. A finite flash medium still needs erase/reuse, endurance management, and power-failure behavior for reclamation. A hash chain supports tamper detection relative to a trusted anchor; it does not alone prevent rollback to an older valid chain. The durability coeffect gains two components here, chained and replayable, committed at target binding like the rest.

Continuity Upward

Nothing in the ledger, the segments, or the root record names a scale, and the chapters mark their server-scale readings as informative sections rather than separate designs. At cluster size the ledger reads as a subscribable metadata event stream, the segments read as compressed metadata chunks in bulk storage, and the custody anchor is a keyring in the metadata store in place of the device sequester. The blog entry An Emergent File System Model covers the design study behind that continuity, including the production system whose metadata architecture we read against these chapters, and the S3-shaped sealed image we see at the far end.

Related Sections

Scheduling on MetalBring-Up Beyond the CPU