Bcachefs Exits Experimental Status

Bcachefs leaves experimental status behind

Bcachefs has officially moved past its experimental phase. Kent Overstreet, the project leader, announced that version 1.38.6 marks a shift in the status of the filesystem. While the project has been in active development for some time, this latest update represents a milestone in its maturity. Overstreet noted that he moved away from the experimental tag some time ago, but this release serves as the formal recognition of that transition.

Performance as the primary goal

It's being framed as the performance update for the filesystem. But that's it. The versioning system currently applies to the accompanying tools, but the kernel module shares the same designation, so users will find numerous improvements in the latest code drop, including bug fixes and architectural changes that let the system handle more complexity. So the updates include several technical refinements aimed at efficiency.

Key technical updates in 1.38.6

The latest iteration brings several functional changes to the table. According to the project documentation, these additions are designed to expand the capacity and speed of the filesystem:

• The filesystem now supports up to 255 devices.
  Market Context: According to Technavio, the next-generation data storage market size is forecast to increase by USD 29.2 billion, at a CAGR of 8.08% between 2023 and 2028.
• The Reconcile operation has been optimized for better parallelism.
• Erasure coding is now functional and in use.
• Six specific performance optimizations were implemented in this version.
• Half a dozen bug fixes were included to improve stability.

The path toward Rust integration

Overstreet is pushing for a transition to Rust. The project is actively converting both the filesystem and its tools into the language, and current progress shows that the userspace code has already been moved over, which includes safe Rust interfaces for the core btree iterator API. But the long-term goal is a fully Rust implementation. This process involves a careful migration of core components like the journal.

I don't know how long it'll take for it to be fully Rust, e.g. converting the journal to safe Rust will be… interesting. But it should be ~50% Rust this year, maybe in the next few months depending on how it goes with deploying a mixed C/Rust DKMS module.

Overstreet's public forum quote highlights the measured pace of this transition. But he remains cautious about how quickly they can deploy those mixed code modules. There's a catch. The team is wary of the rise in low-quality contributions from automated tools, and they can't ignore that concern because it threatens their ability to maintain standards and trust in the process.

A skeptical eye on automation

The project leader has voiced clear skepticism regarding code submissions generated by artificial intelligence. He pointed out that he's seeing a rise in lazy bug reports and patches that appear to be the work of large language models. This shift is unacceptable. But for the maintainers, quality remains the priority over volume, and it's a firm stance against the tide of automated content that has recently begun to clutter developer workflows.

Benchmark reality checks

Performance results show how the system stacks up against existing standards. It's a mixed picture. On a test system featuring an Epyc 9454 processor with 48 Zen4 cores, the latest version hit 16.5 GB per second during dbench testing with 48 clients, while XFS reached 16 GB per second in the same environment. But testing 4k random writes with fio changed the narrative, as the project recorded 700k iops and XFS hit 1 million iops. So it's not quite there yet. These numbers reflect a system that's actively handling more overhead than its established competitors.

Finding ways to experiment

Want to test it without manual compilation? There are other options. A project called NASty offers an experimental Linux NAS operating system built around the technology, and it provides a way for you to interact with the software directly. It's moving forward. But despite past friction over its inclusion in the main Linux kernel, the project continues to advance toward a more stable future.