# 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](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.