From aea7f85d34b2be9a5e49191086dc024b3f1d7a66 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Tue, 25 Aug 2026 18:39:40 -0400 Subject: [PATCH] FABRIC-2.md: flag block_subsystem.c routing revision needed for single-block relocation Milestone 3 direction from this session: ACL decides when to relocate (capacity pressure or a compudynamics heat/cold signal), migration expected rare not routine. Flagging only, not designing yet: current lbn_to_slot() is pure contiguous-range routing, one device owns one unbroken range -- incompatible with relocating an individual block to a different device while its LBN stays fixed. Direction sketched (a sparse LBN-to-actual-device exception table, consulted before the range walk, zero cost for the common never-relocated case) but the actual structure is still open. Block-migration implementation now explicitly depends on this revision landing first. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn --- FABRIC-2.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/FABRIC-2.md b/FABRIC-2.md index f5c5546..429958f 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -4062,9 +4062,24 @@ something else. Implement the derivation function.~~ and explicitly settle the still-open question from Section U: does it reuse `physics_hotwords_cache.c`'s promote/evict logic (confirmed in Section V to be hardcoded to `DictEntry*`, so "reuse" would mean genericizing it, not a drop-in) or - get its own independent implementation + get its own independent implementation. Session direction, 2026-08-25: ACL manages + *when* to relocate (capacity pressure, or a compudynamics heat/cold signal); migration + itself is expected to be rare, not routine (identity+home-blocks drives "probably won't + migrate too much" — SSD moves individual blocks to the drive only when required) +- [ ] **Flagged 2026-08-25, not yet designed: `block_subsystem.c`'s LBN routing needs revision + before single-block relocation is possible.** `lbn_to_slot()` today is pure + contiguous-range routing — walks device slots checking `start_lbn <= lbn < + start_lbn+user_blocks`, one device owns one unbroken range. Relocating an individual + block to a different device while its LBN stays fixed (the whole point — FORTH code + never sees the physical backing move) breaks that assumption outright: nothing today + lets one LBN inside a device's declared range actually resolve to a *different* device. + Direction sketched but not designed in session: a sparse relocation-exception table + (LBN → actual backing device), consulted before the plain range walk — only relocated + LBNs need an entry, so the common case (nothing ever relocated) pays zero added cost. + Exact structure (per-device vs. global, storage format, interaction with the existing + BAM/cache machinery) is the actual design work, still to do. - [ ] Implement the block-migration function itself (move one block's content + BAM entry - between two attached devices) + between two attached devices) — depends on the routing revision above existing first - [x] Implement the `sk_repl_idle()` body — the cheap "anything dirty? no? done" check (Section V confirmed this hook is empty and ready right now, doesn't even need Milestone 2 to be written, only to be *tested end to end*). **Done 2026-08-25**, see