v2026.5.16 - LSM L0 Manifest Recovery

v2026.5.16 - LSM L0 Manifest Recovery

Release date: 2026-05-16 Profiles affected: :core Status: Storage beta-hardening slice

std.db.lsm.GrainStoreBytes now has an explicit L0 manifest surface for flushed SSTables.

What Shipped

• gs_save_l0_manifest_bytes records attached L0 SSTables oldest-to-newest.
• The manifest includes level, slot order, SSTable path, file length, footer entry count, and an SSTable image fingerprint.
• The save path uses temp-file write, file fsync, rename, and directory fsync.
• gs_load_l0_manifest_bytes reloads L0 metadata into a fresh bytes store.
• Load validation rejects torn manifests, missing or truncated SSTables, and stale same-shape SSTables before publishing L0 state.
• Smoke tests prove recovery from SSTable metadata after WAL truncation, WAL/manifest replay idempotence, and refusal of partial or stale artifacts.
• std.stl.lsm_store.flush_with_manifest and make_store_recovered apply the save/load policy at the STL facade boundary.

Why It Matters

Before this slice, clean-reopen tests still worked because the WAL retained the written frames. That is not enough for a boring storage substrate. Once a producer flushes to SSTable and truncates or rotates the WAL, the store needs durable level metadata to find those SSTables again.

The manifest is the first beta-hardening step for LSM/STL durability. It makes flushed L0 state explicit, validates it on load, and gives crash-consistency tests a concrete artifact to tear, truncate, replace, and replay against.

Remaining Work

Manifest paths are still explicit. Automatic path discovery, tombstone-aware compaction, TTL policy, group-fsync batching, and performance baselines remain separate storage hardening slices.