The dynamic layer as files of entries and a map of keys

[PaulSnow]

Step 1 of the entries-written-once proposal (#96), stacked on it and on the platform (#95). Draft: the dynamic layer alone measures as intended; the permanent layer (step 2) is not started, and under the full load the seal is still set by the permanent merges.

What it is (database/heap.go, opened with NewKVShardHeapN / NewKV2Heap, recognised on open by its directory; bdbench -dyna-heap):

• Entries [len][height][key][value][crc] at exact aligned length, appended to fixed-size data files; a key is (file, offset, length) in an in-memory map. A block appends to the current file; the mover appends to a file of its own, so their barriers never share an inode.
• A rewrite within the block reuses its slot when the entry keeps its size; across blocks it appends and the old slot is dead where it lies. A slot the durable index names is never overwritten.
• The mover (on the adapter's cadence) takes the deadest files — once half dead, or whatever their ratio while dead exceeds live, which bounds the heap at twice its live set — copies their live entries, syncs its own copies, and marks a file with nothing live for deletion by the sync after the delta naming the copies. It holds the shard lock only to pick, to plan a chunk, and to name; never across a read, a write, an fsync or a CRC.
• The index is generations (index-G.log): a snapshot record starts a generation in its own file (written aside, fsynced, renamed, directory fsynced), deltas append to it, the previous generation is removed. No delta is ever truncated away.
• Repair reads the keys from the data: highest committed copy wins, entries above the committed height dropped.
• KV2 asks its dynamic layer through a small interface; sharding and the adapter are unchanged.

Measured (platform, nine stores on one NVMe, dynamic layer only, five minutes): seal p50 53–61 ms every minute (segment layer alone: 33–38 ms, but with a compaction storm in minute 4: seal max 1.5 s, 58 blocks missed); read p99 1–2 µs (segments: 11–13); maintenance ~10 s/min (segments: 22–110); store 3.8 GB at five minutes (segments 3.1); zero wrong answers. The remaining tail (p90 150–250 ms in the minutes the mover copies most) follows the mover's fsync volume in the device queue; the last commit shrinks the pass to 4 MB and is not yet measured.

Tests: in-place reuse and one-sync-late deletion; reopen replays the generation and drops the unsynced block; torn log tail; generation switch with an interrupted snapshot; damaged slot; repair from data; shard round trip with rolling and deletion; a put between the mover's copy and its naming; a child process killed mid-block three times over, reopened and repaired to exactly the last durable block. All under -race. The full suite under -race is running.

🤖 Generated with Claude Code

https://claude.ai/code/session_015wUZmWRdAPtcfFgYrLJCc5