nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schfs-btree-phase1.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

1.9 KiB
Raw Blame History

name description metadata
schfs-btree-phase1 SchFS phase 1 (the CoW B-tree) is built and passing; run `make schfs-test` after touching it
node_type type originSessionId modified
memory project a665e14b-86bd-4b41-a228-51377f3e9225 2026-08-01T20:34:28.236Z

The filesystem is called SchFS — not "SchFS v2". Design: docs/architecture/schfs.md.

Phase 1 is done (2026-08-01): the copy-on-write B-tree exists and passes its torture harness.

  • include/schfs.h — on-disk format: 4096-byte blocks, 24-byte (objectid, type, offset) keys, node header with a self-pointer, uberblock ring.
  • kernel/fs/schfs/btree.{c,h} — portable C against an abstract struct schfs_bdev, so the same code runs on a host file and in the kernel. Not yet linked into the kernel.
  • tools/schfs_test.c — the harness. make schfs-test builds and runs it.

Measured geometry: max inline value 1016 bytes, fanout 84 (internal) / 127 (leaf).

Run make schfs-test after any change to btree.c. It checks against a reference model, verifies structure, simulates a crash by discarding uncommitted writes, and confirms both a bit flip and a misdirected write are detected.

A test-design trap worth remembering: the harness originally used schfs_key_cmp inside its own reference model. Deliberately breaking that function then broke the tree and the oracle identically, and every check still passed — the suite could not fail. The model now has its own ref_key_cmp written out longhand. Mutation-test any new oracle the same way before trusting it.

Known and deliberate: delete does not merge or rebalance underfull nodes. The tree stays correct and sorted; merging is phase 3.

Next: phase 2 (read-only mount of a v2 image), then writes/transaction groups, then extents. Per-pid /proc for ps/top should ride along with that VFS work — see schunix-devfs-procfs.