memory: the SchFS and platform roadmap, and the 614 MB ceiling
Records the direction set out today -- snapshots, scrub, compression and encryption for SchFS; one shared home for the format; a unified second stage under both firmwares; audio -- and the two requests that were pushed back on, with the reasoning, so neither gets re-litigated from scratch: 128-bit addressing buys nothing over the 64 ZB already addressable, and SchFS cannot live in projects/ because the kernel has to mount it to boot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
527e6eac42
commit
58296b3376
2 changed files with 68 additions and 0 deletions
|
|
@ -35,6 +35,7 @@
|
|||
- [Boot splash and logo](schunix-boot-splash-logo.md) — the loader draws the logo, not the kernel; STAGE2_SECTORS was in five places and is now in one.
|
||||
- [SchAPI direction](schunix-schapi-direction.md) — Schunix as a macOS-shaped *system*; the stable ABI is a library, not the syscall table.
|
||||
- [Schcom v0](schcom-v0.md) - the compositor runs; Wayland-shaped, verified by checking pixels from the host.
|
||||
- [SchFS next + platform roadmap](schfs-next-and-platform-roadmap.md) - snapshots/scrub/compression/encryption, one home for the format, a unified loader, audio; and the 614 MB ceiling that was fixed.
|
||||
- [Roadmap and projects/](schunix-roadmap-and-projects.md) — the agreed order through to Schcom/SchWM/SchDE; the GUI and installer live outside the OS tree.
|
||||
- [Driver infrastructure](schunix-driver-infrastructure.md) — dynamic IRQ registration, a DMA arena, PCI capabilities; PCI interrupts are level/active-low.
|
||||
- [Network stack choice](schunix-network-stack-choice.md) — don't write TCP; lwIP over FreeBSD over NetBSD, with the licence evidence.
|
||||
|
|
|
|||
67
.claude/memory/schfs-next-and-platform-roadmap.md
Normal file
67
.claude/memory/schfs-next-and-platform-roadmap.md
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
name: schfs-next-and-platform-roadmap
|
||||
description: "The 2026-08-10 direction — SchFS features, one shared home for the format, a unified loader, audio; and the two requests that were pushed back on"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
|
||||
modified: 2026-08-10T16:52:05.449Z
|
||||
---
|
||||
|
||||
**Set out by Nexoniarz 2026-08-10**, after the compositor and resolution work.
|
||||
|
||||
## Two requests that were pushed back on, and why
|
||||
|
||||
**"Make SchFS bigger than ZFS."** Declined as stated, and Nexoniarz did not
|
||||
press it. SchFS already addresses **64 ZB** (64-bit block numbers at 4 KB).
|
||||
ZFS is 128-bit — a number its designers said could not be filled without
|
||||
boiling the oceans. Beating it means 128-bit block pointers: every pointer in
|
||||
the B-tree doubles, cache pressure with it, for a limit already physically
|
||||
unreachable. A spec-sheet win with a real cost.
|
||||
|
||||
**"Move SchFS to projects/."** Cannot be done as stated: `projects/` is for
|
||||
things that run *on* SchOS, never linking kernel headers and never a dependency
|
||||
of the kernel build ([[schunix-roadmap-and-projects]]). SchFS is the root
|
||||
filesystem — the kernel must mount it to boot. **The version that works** is a
|
||||
neutral `lib/schfs/` consumed by the kernel, by `mkschfs`/`schfs_fsck`, and by
|
||||
`projects/schfs-linux`. The source is *already* shared verbatim; this only moves
|
||||
where it lives. Agreed as the sensible form, not yet done.
|
||||
|
||||
## Done 2026-08-10: the ceiling that actually existed
|
||||
|
||||
The format said 64 ZB; the stack under it said **614 MB**. `idestart` panicked
|
||||
on any block past `FSSIZE` (150000 blocks) — a constant describing a v1
|
||||
filesystem *image*, bounding a physical device. Fixed in commit 527e6ea along
|
||||
with the rest of the chain: `struct buf.blockno` and `bread` are 64-bit,
|
||||
sectors are computed in 64 bits, and LBA48 is used per request when the sector
|
||||
does not fit in 28 bits.
|
||||
|
||||
**Still capped, deliberately:** raw `/dev/hdN` goes through devsw's 32-bit
|
||||
offset, so a raw device is addressable to **4 GB**; `usb_storage` builds a
|
||||
32-bit LBA, which is what SCSI READ(10) carries — READ(16) is a different
|
||||
command, not a wider variable.
|
||||
|
||||
## The SchFS feature list, all four wanted
|
||||
|
||||
Nexoniarz asked for all of these. Suggested order is mine, cheapest and
|
||||
highest-leverage first:
|
||||
|
||||
1. **Snapshots and clones.** The copy-on-write B-tree already makes a snapshot
|
||||
a retained tree root ([[schfs-btree-phase1]]). Almost certainly the best
|
||||
value per unit of work on the list.
|
||||
2. **Integrity: scrub, repair, redundancy.** CRC32c per data block already
|
||||
exists; this is detecting and *repairing* rather than only reporting —
|
||||
duplicate metadata, a scrub pass.
|
||||
3. **Compression**, per extent. The extent record already carries a length and
|
||||
a disk block, so there is somewhere to put a compressed size.
|
||||
4. **Encryption.** Confidentiality, where the checksums give integrity. Last
|
||||
because it is the one with the most ways to be subtly wrong.
|
||||
|
||||
## The platform list
|
||||
|
||||
- **A unified second stage.** BIOS and UEFI become thin starters handing off to
|
||||
one common loader. This is worth real money: the duplication is exactly what
|
||||
produced the `EFER.SCE` and RSDP bugs, where the BIOS path had something the
|
||||
UEFI path silently did not ([[schos-uefi-loader]]).
|
||||
- **Audio.** First sound driver, new device class. Intel HDA or AC'97 — both
|
||||
emulated by QEMU, both with public specs.
|
||||
Loading…
Reference in a new issue