01 · What it is
What a filesystem is, and why it matters
A filesystem is the program that decides where every byte on your disk lives: which blocks hold your photos, how directories are laid out, what happens to your files when the power dies mid-write. ext4 and btrfs are two filesystems that ship with Linux: ext4 the long-standing default, btrfs the ambitious one with snapshots and self-healing. The kernel implements both in C, hardened over decades.
It matters for one reason that outweighs all others: durability is the one property a filesystem cannot be wrong about. A database can be slow. A filesystem that silently loses a write it claimed was saved is broken in the one way that counts. Every other quality (speed, features, cleverness) is conditional on that single guarantee.
FrankenFS is a clean-room reimplementation of both formats in Rust: it reads and writes real ext4 and btrfs disk images, mountable through FUSE, with no kernel code involved. It is also, unusually, a laboratory: the real formats, but with experimental commit protocols and repair machinery bolted on, so new ideas can be tested against production disk layouts without rebooting a kernel.
02 · Why build it
Why rewrite it in Rust?
The maintainer, Jeffrey Emanuel, a solo developer building a whole suite of Rust reimplementations, gives the case in the tree itself rather than in a single manifesto. Filesystem bugs in C are memory bugs: buffer overruns, use-after-free, corrupted in-memory structures that then get written to disk as if they were truth. Rust's compiler rules out whole classes of these at build time. FrankenFS goes further than most of the suite: every first-party crate carries #![forbid(unsafe_code)], and a grep across all 421 files finds zero real unsafe code. source Only the vendored FUSE transport sits outside the ban, and the README names that boundary rather than hiding it.
There is also a research argument, and it is the more interesting one. Nobody can experiment on the kernel's ext4 without rebooting. A userspace reimplementation of the real on-disk formats lets you mount the same images your production systems use and swap the machinery underneath: a block-level concurrency protocol with merge-proof conflict resolution instead of the journal's global lock, a self-healing repair layer built on fountain codes. That is a real gap: forensics has debuggers for disk images, research has prototypes that speak no production format, and nothing lets you do both.
The counter-argument, which the project publishes against itself: its own safety scanner reports 254 unresolved critical findings on a partial run. The scan exists (almost nobody's does), and it is red. Memory safety is a claim about one failure class, not a proof of durability; the btrfs write path has a published history of silently losing data; and the kernel has crash-consistency lessons written in production outages that no amount of unsafe-free Rust can shortcut.
03 · What was built
What the project actually built
The volume is real and in the right places: 663,710 lines across 22 crates, with the mass in the MVCC concurrency engine (32,831 lines), an in-house fountain-code repair subsystem (31,572 lines, RFC 6330 implemented by hand rather than taken as a library), JBD2 journal attachment on the ext4 write path, and a ~1,866-line btrfs transaction-commit serializer. It mounts. The ext4 read path is validated against the kernel's own debugfs and dumpe2fs.
The most original artifact is the evidence apparatus, and it is pointed at the project itself. A 20,556-line negative-evidence ledger records falsified hypotheses with verdicts. A parity report prints its 97/97 feature number with an immediate self-disavowal: the number "is not an executed-test result or a readiness score." Mounted scorecards open with all-caps anti-hype warnings. And in August the ledger published a re-scoping that devalued 166 of its own benchmark rows: the same measurement swung 13.6× between two worker machines while both noise controls passed, so rows that cannot prove which host they ran on "may only fall". New rows must record their host. One scorecard proves the project's best btrfs "win" was a transport illusion: a 3.2× swing from loop-device versus file transport alone.
Evidence · CI status
What the project’s own CI said at the pin
the pin = the commit the assessment was pinned to.
- ✕The main CI (continuous integration: automated checks that run on every change) workflow was red at the assessed commit.
The uncomfortable findings
Uncomfortable finding
In May 2026 the project's own reality check found its btrfs read-write path was a silent-data-loss facade: mutations logged outcome="applied" against an in-memory tree while nothing persisted. The August repair commits name the root causes at commit granularity: a durable commit that couldn't serialize its own leaves, an out-of-space write that destroyed the data it failed to replace. Seven canonical gate commands all report not_implemented. The binding exists; the tests don't. The README tells you to use it "on data you can lose."
Uncomfortable finding
Then the governance compound. The license is MIT plus a rider naming OpenAI and Anthropic, and anyone acting for them, as forbidden parties, barred from even benchmarking or analyzing the code. The maintainer states plainly that he does not accept outside contributions for any of his projects. The rider blocks the labs; the policy blocks everyone else. The only permitted relationship with this codebase is to read it. Independent validation is zero.
04 · Where it stands
Where it stands
In our program's terms: TRL 4 in aggregate (5 to 6 for ext4 read and inspect, 4 for ext4 read-write, 3 for btrfs read-write). NODUS ring Explore. In plain English: the read lane is a real, mounted, kernel-validated tool; the write lanes are experimental with a documented history of durability breakage; the system as a whole is substantive but unproven, and the governance compound caps it there.
Technology readiness
TRL 4 on a 1-to-9 scale.
NODUS ring
MonitorExplorePilotInvest
The program’s adoption ring for this project.
Verdict key
- NODUS ring
- Explore: The default for substantive-but-unproven work.
- TRL
- Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 4.
- CI
- Continuous integration: the project’s automated checks, run on every change.
- The pin
- The exact commit the assessment was pinned to. “At the pin” means as of that commit.
Evidence tiers
- Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
- Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
- Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
- Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
- Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.
What this verdict rests on. Tier labels are the assessment packet’s own annotations.
- Tier 1 · Verified: 22 workspace members and 663,710 lines confirmed from a fresh clone;
forbid(unsafe) at every crate root. - Tier 2 · CI-observed: CI red at HEAD at the workflow-conclusion level; the specific failing jobs were not enumerated.
- Tier 3 · Maintainer claim: Nothing was compiled, mounted, or fuzzed; behavioral evidence is maintainer-executed and dated 2026-09-21/22.
- Tier 4 · External: Zero independent validation found.
- Tier 5 · Inference: The Explore ring at TRL 4.
Should you use it?
No.
The README says so itself: not production-ready for irreplaceable data, use it on data you can lose. source
Should you learn from it?
Yes.
This is the program's sharpest self-audit apparatus, and the ffs inspect path (parsers and inspection needing no mount, no durability story) is a credible wedge. The evidence discipline is the export; the filesystem is the demonstration.
What would change the verdict, in order
- the main CI green at HEAD for a sustained window, a second tagged release covering the durability work, an independent fault-injection campaign against the btrfs commit path, any softening of the no-contributions policy, and a license an evaluator can sign
- Until then, for real storage, the kernel wins on every criterion except auditability
source
05 · What it teaches
What this teaches about building with agents
The transferable lesson is one sentence the project wrote into its own doctrine: a measurement that does not name its host is valid on an unrecorded machine, never as comparable to a row measured elsewhere.
Everything else follows. The 13.6× swing between workers survived the A/A noise controls. The controls only govern noise within one run, and between-machine differences (CPU, cache, memory bandwidth) sail through them untouched. The 3.2× transport swing survived every statistical gate for the same reason: the gates were checking the wrong confound. The project's ratchet (unattributed rows may only fall, never be joined by new ones) is the mechanism that makes the confession stick instead of fading into the next benchmark table.
For anyone building with agents, the point generalizes past filesystems. Agents will happily optimize whatever benchmark you hand them and report the win; the wins will quietly depend on which machine ran, which transport carried the bytes, which build produced the binary. The fix is not better statistics. It is provenance on every number: the host, the binary hash, the transport, recorded at measurement time, with rows that lack them demoted by policy rather than by anyone's judgment. If your apparatus cannot say "this doesn't prove what I hoped," it cannot prove anything at all.