SchOS/kernel
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz edc4e0537d schfs: commit every 5 s, survive a full disk, mount up to 64 TiB
Transaction groups commit from a schfsd thread every 5 seconds, on sync
and fsync, on unmount and shutdown, and early when freed-but-pending
blocks crowd the free ones -- the contract ext4 and ZFS have. A crash
still lands on the last group whole, and loses at most those seconds.
Committing before every write(2) returned cost two cache flushes and an
uberblock a call: 4 KB writes go from 2.8 to 6.6 MB/s on AHCI, and from
66 KB/s to 3.9 MB/s on QEMU's IDE disk.

Filling the disk made the root volume unmountable, on the last commit
as well: a tree update that ran out of blocks halfway was published by
the next commit. 1% of the volume (1 to 64 MiB) is now a metadata
reserve, as btrfs and ZFS keep one; data stops at it with ENOSPC as a
short write, new names at half of it, and deletes may use the rest. A
write that runs out part way records what it wrote in the inode rather
than leaving blocks past an end of file nothing moved.

Deleting a large file goes in 4 MiB steps from the end with a commit
allowed between them, as ext4 restarts its transaction through a long
truncate. Deleting 80 MB on a full disk ran out of room halfway and
leaked the rest.

The VFS's dirunlink called the object layer's whole unlink, which freed
the object with its last name, so a file removed while open lost its
data under the reader. It removes the name only now, and the object is
freed on the last iput. An object still open when the machine went down
is found by the mount's space scan and freed, like ext4's orphan list.

The allocation bitmap has a second level of pointer pages, so the mount
ceiling is 64 TiB instead of 64 GiB, and the freed-this-group bitmap
has pages only where frees happened: a 1 TiB volume takes 32 MiB.

A freed block written after the newest snapshot is reused at once
(ZFS's birth-time rule, so bfree carries the block's generation); only
older ones are kept while a snapshot exists. Deleting one snapshot no
longer stops retaining for the others, which let their blocks be
handed out again.

Checked under QEMU: crash after sync, after 8 s and within 5 s; fill to
ENOSPC, rm, remount; unlink while open; an orphan freed at the next
mount; a 1 TiB volume. schfs-check passes, with a new test for the
snapshot rule.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2026-10-23 12:20:05 +02:00
..
acpi fat: FAT12, FAT16 and FAT32 with long names, read and write 2026-10-23 09:33:35 +02:00
arch/x86_64 gfx: draw the console in RAM, and write it to the card write-combined 2026-10-22 23:46:58 +02:00
core dev: read /dev/zero and /dev/urandom from them, not from the keyboard 2026-10-23 09:33:08 +02:00
dev vfs: room for 32 disks and partitions, 32 mounts, 16 SchFS volumes 2026-10-23 12:19:50 +02:00
drivers acpi, vga: say what the first real boot actually found 2026-10-22 23:47:17 +02:00
fs schfs: commit every 5 s, survive a full disk, mount up to 64 TiB 2026-10-23 12:20:05 +02:00
net licence: SchOS is GPL-2.0-or-later, no longer Apache-2.0 2026-10-22 08:48:45 +02:00
proc storage: AHCI, GPT/MBR partitions, and a disk a PC can boot 2026-10-22 10:57:41 +02:00
sys vfs: names up to 255 bytes and paths up to 4096, like Linux 2026-10-23 11:17:28 +02:00
kernel.ld debugger: the kernel can be asked a question 2026-09-14 00:58:45 +02:00