admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-2.md: flag block_subsystem.c routing revision needed for single-block relocation

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn
This commit is contained in:
Robert Allan James
2026-08-25 18:39:40 -04:00
co-authored by Claude Sonnet 5
parent 306ee70468
commit aea7f85d34
1 changed files with 17 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-2.md
+17 -2
View File
@@ -4062,9 +4062,24 @@ something else. Implement the derivation function.~~
and explicitly settle the still-open question from Section U: does it reuse 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 `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 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 - [ ] 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 - [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 (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 Milestone 2 to be written, only to be *tested end to end*). **Done 2026-08-25**, see