58296b3376
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>
3.3 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schfs-next-and-platform-roadmap | 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 |
|
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:
- 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.
- Integrity: scrub, repair, redundancy. CRC32c per data block already exists; this is detecting and repairing rather than only reporting — duplicate metadata, a scrub pass.
- Compression, per extent. The extent record already carries a length and a disk block, so there is somewhere to put a compressed size.
- 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.SCEand 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.