Kent Overstreet declares bcachefs “no longer experimental” with version 1.38.6

Kent Overstreet just flipped a status switch for bcachefs. In a new post, the bcachefs boss announced version 1.38.6 of the Linux filesystem, calling it “the performance release” and saying the project is no longer experimental, noting he had dropped the experimental tag at some unspecified time earlier.

On paper, 1.38.6 is “just” a point release. But the meaning is bigger than the number: it is only the second release this year that Overstreet described on his Patreon blog, and his latest post is the belated official announcement that bcachefs is now in the mainstream lane. His prior mention of a release was a brief note on version 1.37 in mid-March, and even that got overshadowed by a separate Patreon announcement, where he said his AI coding assistant PoC was conscious and female. The timeline matters because it shows two competing pressures inside the project: moving fast enough to ship, and controlling the quality of contributions in an era where LLMs can draft code at scale.

If you want to understand what actually changed in 1.38.6, you cannot just look at the filesystem version number in isolation. The bcachefs Git repo is busy, so the accompanying bcachfs-tools repo is easier to read. Starting with January’s 1.35.0, bcachfs-tools shows 18 releases so far this year. Strictly speaking, the version number applies to the utilities rather than the filesystem module itself, but an additional datapoint complicates that tidy distinction: checking a Debian APT repository shows that the kernel DKMS module has a matching version number, and neither the blog post nor the changelog distinguishes between tools and filesystem module.

According to the changelog, this version bumps the number of devices in a filesystem to 255, and includes fixes for half a dozen bugs. More importantly for anyone who cares about throughput and latency, it identifies another six performance optimizations. One highlights the Reconcile operation, previously called “rebalance,” as faster and more parallel. Another states that erasure coding is “in use and seems to be working quite well,” which is a significant operational capability, since erasure coding is typically where storage systems try to trade compute and space efficiency for resilience.

The post also ties performance changes back to documentation updates and deployment reality. Overstreet references an updated handbook, “bcachefs Principles of Operation [PDF],” with the current revision from April, plus a “Getting Started” guide. He also notes that the major distributions he has checked now enable kernel Rust support. That matters because bcachefs is not only a storage engine. It is also a long-term experiment in how much kernel-adjacent filesystem work can be written in Rust, and what it costs to do it safely.

Overstreet says work has already started converting the filesystem and tools into Rust. “The bcachefs userspace code has already been converted to Rust,” his post says, with work that included safe Rust interfaces for the core btree iterator API and quite a bit of utility code. The next release, he says, will pull these bindings into the DKMS module, and then the project will start converting core code. In the Phoronix forums, Overstreet adds color on the hard parts: he does not know how long it will take for it to be fully Rust, and converting the journal to safe Rust “will be… interesting.” His estimate is roughly “~50% Rust this year,” with timing dependent on deploying a mixed C/Rust DKMS module.

This is where the political economy of software supply chains shows up. Overstreet expresses skepticism toward AI-authored code contributions, saying he is not against AIs but has started to see “lazy patch submissions/bug reports” where someone is asking an LLM to do all the work, “and that’s not ok.” That is not just a vibe check. It’s a quality-control strategy for a project trying to move out of “experimental” territory while the cost of sloppy contributions has fallen dramatically.

And then there are the performance numbers, which he frames cautiously. In the Patreon post, Overstreet explains testing on an Epyc 9454 with 48 Zen4 cores. He says 1.38.6 pushes 16.5 GB/sec through dbench with 48 clients, versus 16 GB/sec for XFS. For 4k random writes with fio, bcachefs is hitting 700k iops, versus 1 million for XFS. He also notes bcachefs does much more work than XFS, and the source text highlights that this makes the values feel more plausible because he is not claiming vastly superior results.

For executives and boards, the “why now” is the convergence of three things: a maturity signal (no longer experimental), an engineering roadmap that assumes kernel Rust can be operationalized via DKMS, and an explicit governance stance against low-effort AI patches. The strategic stakes for peers are straightforward: if bcachefs can keep earning trust through performance releases and safe Rust progress, it pressures incumbent storage stacks and changes how teams think about rewriting critical infrastructure. It also keeps alive the long-running question of kernel acceptance, since bcachefs has been booted out of the Linux kernel due to a personality clash between Overstreet and Torvalds, and the end-of-story sentiment in the source is that one day it may be merged again. Perhaps as the kernel’s first filesystem implemented in Rust.