| Filename | Latest commit message | Latest commit date |
|---|---|---|
d0f7acf9eb
An x86-64 operating system built from xv6, now largely rewritten: SMP, a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF rasteriser, and a Linux-numbered syscall ABI. No history before this point -- the tree was never under version control. This commit exists so the rename that follows has something to undo to. |
||
| .. | ||
| LICENSE | ||
| README.md | ||
SchFS
A copy-on-write filesystem, built from the ground up.
SchFS is a modern-shaped filesystem in the tradition of BeFS, ZFS and btrfs: a copy-on-write B-tree, 64-bit object identifiers, checksummed metadata, and an extent-based layout. It is written from first principles rather than derived from an existing implementation.
Status: early. The on-disk format works and is exercised by a test suite, but it is not stable and there is no compatibility promise yet. Do not put anything you care about on it.
What it is
| Copy-on-write B-tree | Metadata is never overwritten in place. An update writes new blocks and swings a pointer, so a torn write leaves the previous consistent state rather than a half-updated tree. |
| Objects, not paths | Everything is a 64-bit object id. Directories are a mapping from name to id, which keeps naming a separate concern from storage. |
| Checksummed metadata | CRC32c on every inode and on the superblock, verified on read. Corruption is detected where it happens rather than inferred later from strange behaviour. |
| Derived free space | The free map is computed from the allocation tree rather than stored alongside it. There is no second structure to disagree with the first. |
| Extents | Contiguous ranges rather than per-block pointers, so a large file costs a small number of records. |
What it is not, yet
Being honest about this up front, because a filesystem's missing features are the part that matters:
- No snapshots. The B-tree is copy-on-write, which is most of the machinery, but nothing takes or names a snapshot yet.
- No journal replay beyond what copy-on-write gives for free.
- No extended attributes, no sparse-file support, no online repair.
- No format versioning policy. This is the first thing being fixed — see the roadmap below — because everything else is harder to change without it.
Roadmap
1. An on-disk format version, and an upgrade path. Not optional, and it gets harder every day it is postponed: the moment an image exists that somebody cares about, changing the layout means being able to read the old one. The superblock already carries a version field and a checksum; what is missing is the policy — a documented meaning for a version bump, a refusal to mount something newer than the driver understands rather than misreading it, and an explicit upgrade step.
2. FUSE. The first Linux implementation is a FUSE filesystem, not a kernel
module. Three reasons, in order of weight: it can be tested with fsx and
xfstests, which are far harsher than any suite written alongside the code; it
carries no licence entanglement, since libfuse is LGPL and used across a process
boundary; and it can reuse the existing image-building and checking code rather
than reimplementing the format a second time and having the two disagree.
3. A kernel module. Only after the format is pinned and FUSE passes
xfstests. Writing a kernel filesystem against a format that is still moving is
how you end up maintaining two of them.
Licence
Apache-2.0. See LICENSE.
Apache-2.0 rather than MIT or BSD for one reason that matters at this level: it contains an express patent grant and a patent-retaliation clause. MIT and BSD are silent on patents, which means a contributor can hand you code and later assert a patent over it.
Note that a Linux kernel module is a different licensing question from FUSE, and one reason the FUSE implementation comes first.