---
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.