A modern filesystem engineered with AI, verified through relentless testing, and released under the MIT License.
Section 01
Modern general-purpose filesystems are extraordinary engineering — and enormous. ext4, XFS, and Btrfs each carry tens to hundreds of thousands of lines to serve every workload on every device. That breadth is a feature for a general OS, and a cost for a removable flash card that only ever holds photographs and video.
Complexity is not free. Every feature is surface area to maintain, audit, and get wrong under power loss. The card in a camera does not need quotas, online defragmentation, or a competing allocator for every access pattern. It needs to write a file once, verify it, and survive the moment the battery dies.
Slim64FS treats simplicity as an engineering strategy rather than a slogan. AI made disciplined reduction practical: a human architect set the constraints, AI implemented against them, and the design was held to a single question — does this earn its place for the target workload? What did not, was cut.
This is not a criticism of its predecessors. ext4, XFS, and Btrfs solve a harder, broader problem with decades of hard-won correctness. Slim64FS solves a narrow one, deliberately, and tries to prove it.
Section 02
Every line of the filesystem answers to five rules. They are integrity doctrine, not style preferences.
Minimize the exposure window. Write once, write fast, go idle. The shorter the time data is in flight, the less a power failure can take.
A block commits whole, with a valid CRC32C, or it never existed. No partial writes, no orphaned metadata, no ambiguous state.
Every operation writes in a fixed order: data blocks first, the metadata pointer switch last, and a dual-slot checkpoint publishes the result. A crash at any point lands on the last committed state — never an ambiguous one. (Born as “anticipatory sequencing”; crash testing matured it into checkpointed recovery.)
Hardware-accelerated and nearly free on modern x86/ARM, sized to outrun the bit-rot ceiling of the target media. Stronger checksums buy nothing the silicon can still honor.
File data is written once, at its final location — no write-ahead copy, no double-write amplification eating flash endurance. Metadata safety comes from shadow tables, dual-slot commits, and a tiny per-directory intent log that is discarded at every checkpoint — bounded scaffolding, not a journal in the data path.
Section 03
Yes — AI wrote a filesystem. The interesting part is how it was kept honest.
Filesystems are hard, and the author is candid that he could not write one alone. What changed in 2025–2026 was that a capable model, held under strict human governance, finally could — provided the governance never slipped.
The loop was deliberate: a human architect authored the specification and constraints; AI implemented against them; a human reviewed and tested every result with real tools (xfstests, crash injection, physical media); and then the finished code was handed to multiple independent AI auditors for adversarial review.
The review standard was deliberately hostile — the cooldude@kernel.org
worldview: evidence over assertion, NOTRUN ≠ PASS, no hand-waving.
That standard, not a feature list, is what kept an AI-built system from drifting
into plausible-looking nonsense.
The result is a codebase whose provenance is fully stated: AI-generated from human specifications, human-validated, and independently AI-audited. Nothing about that is hidden — it is the methodology.
Section 04
A small stack with no surprises. Applications never see Slim64FS directly; they speak POSIX, the kernel speaks to a FUSE frontend, and the frontend drives the on-disk format.
On-disk format V9 (0x00090002). 4 KiB blocks, 128-byte
inodes, every metadata structure CRC32C-protected; the allocation bitmap and inode
table are mirrored to shadow slots and published by a dual-slot commit.
Full layout in FORMAT.
Section 05
Feature creep dies when every decision must serve a named, demanding user. Two workloads and one hostile reviewer governed this filesystem — every gate in the next section is named after one of them.
Jay shoots 7,500 frames in a day in the Serengeti. The constraint is brutal in its simplicity: photo #7,500 must save as fast as photo #1. No directory rot, no slow-down as the card fills.
Chris films 8K on a $15,000 body. The constraint: if the rig dies mid-shoot, the footage already written must not corrupt. Sustained throughput with hard durability at every fsync.
cooldude has reviewed filesystems since before journaling was fashionable and uses Emacs as his shell. The constraint: evidence over assertion. NOTRUN ≠ PASS, no hand-waving, and every claim must trace to a committed artifact — or it does not get made.
Engineering against Jay and Chris turned vague goals into measurable gates; reviewing against cooldude kept the evidence honest. Repeatedly, the question "does this help Jay or Chris — and would cooldude believe it?" deleted a feature before it could be born.
Section 06
Slim64FS is measured against the named workloads above rather than synthetic micro-benchmark spam. The numbers below are the actual gate results.
7,500 × 1 MB files, create/delete cycles. FUSE loopback on tmpfs.
| Metric | Result | Threshold | Verdict |
|---|---|---|---|
| Per-file latency p50 | 9.20 ms | — | PASS |
| Per-file latency p95 | 10.86 ms | — | PASS |
| Per-file latency p99 | 12.02 ms | < 50 ms | PASS |
| Mount time drift (before→after) | 161→162 ms | no drift | PASS |
1 MB chunks, fsync every 8 MB, 30 s sustained. FUSE loopback on tmpfs.
| Metric | Result | Threshold | Verdict |
|---|---|---|---|
| Sustained throughput | 192.7 MB/s | > 60 MB/s | PASS |
| fsync latency p99 | 14.39 ms | < 20 ms | PASS |
| Device | Class | Capacity | Jay | Chris | Drop sim |
|---|---|---|---|---|---|
| Samsung FIT | USB 3.x | 119.5 GB | PASS | PASS | loopback |
| UHS-I SD card | SD | 119.1 GB | PASS | PASS | 12/12 |
| WD Black SN850X | USB-NVMe | 4 TB | PASS | PASS | 12/12 |
| CFexpress Type B | CFexpress | — | not tested | not tested | no hardware |
Drop simulation: SIGKILL mid-write across crash windows W3–W6 × 3 seeds (12 trials/device); zero corruption-class findings. Detail: media matrix · Jay gate · Chris gate.
Section 07
The filesystem is not trusted because it was written carefully. It is trusted because it was attacked, repeatedly, and the attacks are reproducible.
Pulled straight from the committed, unredacted logs — not summary
claims. Every number below traces to a file in logs/ or docs/.
6 of 71 xfstests FAILs and all 12 NOTRUNs are documented with root cause and repro commands — nothing is hidden behind a summary number. NOTRUN rationale →
Crash matrix results → · xfstests legitimacy report → · media matrix →
Section 08
The same model family that writes well does not necessarily review well. So the finished code was handed to seven frontier models — trained on different corpora, with different blind spots — and asked to break it.
No single model caught everything. They converged on the highest-severity class (malformed-image hardening) yet each surfaced issues the others missed — and several "critical" findings were refuted as misframed against the durability model. Every finding is recorded with its disposition: fixed, invalid, by-design, or deferred. Diversity of reviewers, not volume of review, is what closed the gaps. Fable 5 then returned for a second, deeper pass (V14.1, July 2026): 13 security findings — all fixed and re-verified against the full gate suite — plus 12 performance findings; the three biggest (release build flags with hardware CRC dispatch, debug verification in hot paths, whole-bitmap flush per allocation) landed alongside the first four. ChatGPT 5.6 then audited independently (V14.1.1, 2026-07-10): 13 security findings plus 11 performance findings, four of the cheapest and highest-confidence fixed same-day — including a fail-closed mount guard against a corrupted image silently presenting a non-empty directory as empty — netting the first LOC-negative pass in the project's history.
Section 09
Slim64FS core is 7,507 lines of code across 20 source files
(cloc v1.98; 8,800 physical lines by wc -l src/*.c src/*.h) —
tiny for a CRC-verified, recoverable filesystem. The numbers speak; no insults required.
Key: ✅ best in group · ❌ worst in group · — neutral / not applicable. Full per-property notes and rationale: filesystem shootout →.
| Property | Slim64FS | FAT32 | exFAT | ext2 |
|---|---|---|---|---|
| Crash safety (power-loss proof) | ✅ | ❌ | ❌ | — |
| Integrity (checksums on metadata) | ✅ | ❌ | — | — |
| Dual-slot atomic commit | ✅ | ❌ | ❌ | ❌ |
| Max volume size | — (8 EiB) | ❌ (2 TiB) | ✅ (128 PiB) | — (32 TiB) |
| Max file size | — (volume size) | ❌ (4 GiB−1) | ✅ (128 PiB) | — (~2 TiB) |
| Hard links | ❌ | ❌ | ❌ | ✅ |
| Symbolic links | ✅ | ❌ | ❌ | ✅ |
| POSIX permissions | ✅ | ❌ | ❌ | ✅ |
| Timestamp precision | — | ❌ | ✅ | — |
| Timestamp range | ✅ | — | — | ❌ |
| License freedom (royalty-free) | ✅ | — | ❌ | ✅ |
| Camera / removable-flash fit | ✅ | — | — | ❌ |
| Tally — ✅ wins | 7 | 0 | 3 | 4 |
| Tally — ❌ worst | 1 | 8 | 3 | 2 |
Slim64FS's single ❌ (hard links) is irrelevant to the target use case — camera/flash media has no hard-link workflows. FAT32's 8 ❌ marks reflect its age and persist only through universal hardware support; exFAT trades integrity for raw capacity; ext2 shares the permissions win (adding ACLs) but was designed for spinning disk, not flash.
Slim64FS deliberately accepts limits a general-purpose FS does not — 258 extents/file, directory depth 16 — in exchange for an O(1), auditable design.
Section 10
Everything is committed, unredacted, and on this site.
Section 11
Slim64FS is source-first. Clone, build, and the tools land in minutes.
git clone https://github.com/slim64fs/slim64fs
cd slim64fs
sudo apt install gcc libfuse3-dev # Debian/Ubuntu
make # builds tools + FUSE binary
make test # unit tests
make verify # baby_xfstestsRequires Linux and libfuse3. Tagged release tarballs with SHA-256 checksums will accompany the first versioned release.
mkfs.slim64fs | format a device or image |
slim64fs-fuse | mount via FUSE |
slim64fs-check | read-only integrity check |
slim64fs-fsck | full fsck with repair |
slim64fs-info | superblock & geometry |
mount.slim64fs | mount helper |
Released under the MIT License.
Section 12
Issues are welcome. Pull requests are welcome. Bug reports — especially reproducible ones against the durability contract — are genuinely appreciated. The whole history, including the failures, is public.
View on GitHubSection 13
Section 14
From a 2003 prediction about exFAT to a publicly released, audited filesystem.
Full history with line counts per phase: version timeline.