SchOS/kernel/fs/schfs
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz b34779111a schfs: several snapshots at once, and unmount gives the slot back
Two loose ends from the mount-by-name commit, both closed.

A slot is a device number, so supporting more than one snapshot is a
small array rather than a redesign: SCHFS_SNAP_DEV through
SCHFS_SNAP_DEV + SCHFS_SNAP_SLOTS - 1, each with its own volume and its
own scratch pages, allocated on first use. Four of them -- "one at a
time" is an odd thing to have to explain, and the cost is two pages per
slot. Not many, because each one is a device number and those are a
small fixed space.

The leak mattered more. umount removed the mount table entry and left the
slot marked in use, so a snapshot could be unmounted and then never
mounted again until reboot. sys_umount2 releases it now, keyed off the
device it already has in hand.

Verified in the running system: two snapshots mounted at once, both
readable, both unmounted, and a third mount afterwards succeeds and reads
correctly -- which is the case that failed before.

schfs-check passes; bootcheck 108 [ok].

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 21:30:28 +02:00
..
btree.c Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00
btree.h Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00
kmount.c schfs: several snapshots at once, and unmount gives the slot back 2026-08-10 21:30:28 +02:00
obj.c schfs: snapshots 2026-08-10 19:10:24 +02:00
objw.c schfs: snapshots 2026-08-10 19:10:24 +02:00
schfs_int.h schfs: snapshots 2026-08-10 19:10:24 +02:00
space.c schfs: snapshots 2026-08-10 19:10:24 +02:00
vfs.c schfs: several snapshots at once, and unmount gives the slot back 2026-08-10 21:30:28 +02:00
vol.c Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00