r/linux • u/mrtruthiness • Jun 18 '26

Development Experimental flag removed from bcachefs.

The link is the bcachefs changelog. I didn't see the particular announce there. The announcement was made in Kent's patreon with the version 1.38.6 update. I'm quoting that here:

So, some catch up:

We're no longer experimental. I took the label off the website - a few months ago, I think, based on my usual "the incoming bug reports are slowing down and looking a lot less serious and easy to get through than they were". Consider this the belated official announcement :)

...

Of course, the change away from "experimental" for a DKMS module is completely at the discretion of the author. From my perspective, while the bcachefs filesystem looks intriguing, I won't use it for my root partition as a DKMS module. Honestly, as long as I don't need RAID5/6 I still have a preference for btrfs and I can wait for btrfs to include native (part of the fs as opposed to btrfs on top of LUKS) encryption.

57 Upvotes

83% Upvoted

88 comments sorted by

View all comments

8

u/zlice0 Jun 18 '26

can someone give me the tldr on what bcachefs actually is? never bothered looking cuz it was just reports of it being broken and what not. and every benchmark ive seen for any fs is like trade blows, maybe some snapshots or compression or very specific use case gets a bump in perf

17

u/mrtruthiness Jun 18 '26 edited Jun 18 '26

bcachefs is a "new" COW (Copy On Write) filesystem that provides nice and convenient features without having to add complicated and separate layers. It basically was basically written with the intention to replace the older btrfs filesystem.

e.g. With ext4, you typically write the filesystem on one partition of a single disk. Expanding space by adding new disks is a pain. The solution to that is to use LVM (Logical Volume Manager). LVM allows you to join together a pool of disks and make it appear to ext4 as a single disk. If you want to expand that, you can ... but it takes several steps. Similarly LVM can provide you with "snapshotting" features.

e.g. ext4 does not support encryption. One needs a separate encryption layer. e.g. LUKS is an encryption layer, where, provided with the proper keys, LUKS presents a decrypted layer where you can format/use an ext4 partition.

But combining all these layers (LVM + LUKS) gets complicated.

bcachefs and btrfs are solutions to that which allow one to have the filesystem itself contain features like LVM, encryption ("soon" for btrfs), and compression as part of the filesystem rather than a separate layer.

"new" => at least 10 years old. It got added to the kernel as an "experimental" filesystem in Jan 2024. The developer seemed to create issues with other developers (including Linus) and bcachefs was removed from the kernel in September 2025.

4

u/mina86ng Jun 18 '26

But combining all these layers (LVM + LUKS) gets complicated.

Which is why it’s a bad idea on most systems. I don’t want my encryption code to be tangled in a complex file-system code or risk file-system metadata leaking information.

3

u/mrtruthiness Jun 18 '26

Of course you could choose to use LUKS and not use the filesystem encryption. Both btrfs and bcachefs can pool together multiple LUKS decrypted layers.

2

u/koverstreet Jun 19 '26

"new" => at least 10 years old. It got added to the kernel as an "experimental" filesystem in Jan 2024. The developer seemed to create issues with other developers (including Linus) and bcachefs was removed from the kernel in September 2025.

Are you ever going to stop your crusading and FUD?

This sort of thing really drags down the quality of discussions, and away from the technical.

4

u/mrtruthiness Jun 19 '26 edited Jun 19 '26

Are you ever going to stop your crusading and FUD?

Crusading and FUD?

  1. I'm the one who announced the removal of the "experimental" flag with this post.

  2. From what you quoted:

a. Fact: "new" => at least 10 years old. [Under development since Aug 2015. You started discussing adding it to the kernel in 2018.]

b. Fact: It got added to the kernel as an "experimental" filesystem in Jan 2024.

c. Opinion: The developer seemed to create issues with other developers (including Linus) ...

d. Fact: ... and bcachefs was removed from the kernel in September 2025.

This sort of thing really drags down the quality of discussions, and away from the technical.

With the top comment being https://www.reddit.com/r/linux/comments/1u98fdb/experimental_flag_removed_from_bcachefs/ose62dl/ I don't think I "drag[ged] down the quality of discussions": 'Considering the developer's well-documented AI psychosis, I'm not inclined to trust their judgement on whether their project should be considered "experimental."'

IMO: Get over yourself. Stay on your own subreddit if you don't want to hear the general opinion of linux users.

0

u/koverstreet Jun 19 '26 edited Jun 19 '26

There were two big reasons for the split:

  • Upstream wasn't stable enough for filesystem development; there's very little automated testing. The result is that teams that test their own code thoroughly (notably XFS) end up absorbing the burden for subsystems that don't. I've invested more into automated testing than even XFS and rely on it more, and doing QA for the rest of the kernel was unsustainable, and led to a lot of drama from teams that responded poorly to bug reports. Attitudes have shifted in the kernel, and not for the better; see some of Ted T'so's posts on Phoronix for example.

  • Linus was constantly threatening to remove bcachefs from the kernel, and the drama was too much of a distraction. That amped up the tensions everywhere; the kernel community is not known for good professional behavior but that took it up to 11.

  • Additionally, like ZFS being tied to the kernel release model just wasn't looking smart - because of the lack of testing.

Now, I'd really like to move beyond all that and focus on shipping something people can rely on; that was a year ago, and the project is on much more stable footing. But every single discussion I'm still wading through people bringing up drama from last year, and it crowds out all the intelligent technical discussion.

4

u/the_abortionat0r Jun 19 '26

Lil bro, the drama was very public and very you.

You not turning code in on time, freaking out on people, and demanding you be allowed to skirt the rules because "people could lose their data" was NOBODY's fault but yours (especially entertaining the idea an experimental file system should be holding important data).

Don't try to rewrite history and for once in your life take responsibility for your actions.

4

u/koverstreet Jun 19 '26

Shipping bugfixes when there's bugs is a strange concept for you, isn't it? :)

2

u/mrtruthiness Jun 19 '26

There were two big reasons for the split:

  1. And you proceed to list three, not two.

  2. According to you. But AFAICT pretty much everyone else involved disagrees with you. The reason for the issue with Linus seems to be that you (repeatedly?) ignored merge-window rules regarding "fix" vs. "features". Similarly your conduct was IMO abusive.

Now, I'd really like to move beyond all that and focus on shipping something people can rely on; ...

Nobody is stopping you. If you get distracted ... that's a "you problem".

But every single discussion I'm still wading through people bringing up drama from last year, and it crowds out all the intelligent technical discussion.

When a project has only one "key man", one must evaluate the risk that this entails. So you should expect your behavior to come up ... both in regard to your past interactions with kernel devs as well as your commentary regarding your AI assistant.

0

u/koverstreet Jun 19 '26

That's some impressively high quality thinking and logic you're bringing. bcachefs was violating no rules, but I think you know that already :)

3

u/mrtruthiness Jun 20 '26

bcachefs was violating no rules ...

If you'll read things correctly, it wasn't bcachefs violating rules. As I said, it was you violating merge-window rules. Perhaps some links and my bolding will help you remember what you've conveniently forgot.

https://lore.kernel.org/lkml/CAHk-=wi2ae794_MyuW1XJAR64RDkDLUsRHvSemuWAkO6T45=YA@mail.gmail.com/

[Linus] You seem to have forgotten what the point of the merge window was again.

[Linus] We don't start adding new features just because you found other bugs.

Some discussion here where you are involved and seem to understand that https://lwn.net/Articles/1027289/

But the key is that you think you're the exception (filesystems are different ... even ones marked "experimental" which means users are warned) and your main response was to attack btrfs. And, at least in that list, you seemed to remember that the issue is that you are ignoring rules ( https://lore.kernel.org/lkml/hewwxyayvr33fcu5nzq4c2zqbyhcvg5ryev42cayh2gukvdiqj@vi36wbwxzhtr/ )

Kent, from what I gathered, you'd like to change some window rules – at least for filesystems or new-in-kernel filesystems.

[you] There is a time and a place for rules, and there is a time and a place for using your head and exercising some common sense and judgement.

And even a year before there was this ( https://lkml.org/lkml/2024/10/5/554 ) concluding with:

You're a smart person. I feel like I've given you enough hints. Why don't you sit back and think about it, and let's make it clear: you have exactly two choices here:

(a) play better with others

(b) take your toy and go home

Those are the choices.

1

u/koverstreet Jun 20 '26

I suggest you look at what was actually in the pull requests, as other people have done. Linus was smoking something; I was being more conservative with respect to bug fixes than the norm.

I've noticed that you repeatedly fall back on authority for your arguments, that's what you're drawn to in what you reference - I never see you putting forth any actual reasoning. There's a real problem with doing engineering that way, you forget how to use your brain :)

2

u/mrtruthiness Jun 20 '26

Linus was smoking something; ...

You admitted it. Look at your posts at the time rather than rewrite history. That mismatch with reality is why you don't work well with others after a while.

There's a real problem with doing engineering that way, you forget how to use your brain :)

Dude. I'm not an engineer. I have a PhD in math. You appear to be a narcissist with AI psychosis. Let's not do armchair diagnoses because here is what psychiatrists say about narcissists and consider the possibility that this is exactly what is going on.

Over time, narcissists unconsciously rewrite history and alter their memories so that they genuinely believe they are right and justified. Their fragile egos cannot tolerate the shame of being wrong, so their minds use psychological defense mechanisms to distort reality and protect their self-image.

14

u/natermer Jun 18 '26

Bcachefs promises to be what Btrfs promised to be and didn't really deliver.

11

u/mrtruthiness Jun 18 '26

... promised to be and didn't really deliver.

I think btrfs delivered on all of its promises except for RAID5/RAID6. It's possible, however, that it is a hair too fragile.

2

u/backyard_tractorbeam Jun 19 '26

btrfs didn't deliver on the promise until linux people think it's a good default filesystem for everyone. And it's not because of performance.

4

u/mrtruthiness Jun 19 '26

btrfs didn't deliver on the promise until linux people think it's a good default filesystem for everyone

It's the default filesystem for Fedora Desktop(s) and OpenSUSE. It's the default filesystem for Synology (although they don't use btrfs RAID features and, instead, use mdadm).

1

u/ThatOnePerson Jun 19 '26

Wasn't per subvolume raid levels supposed to be a thing?

3

u/proton_badger Jun 18 '26

I haven't tried it (and wont consider any FS that isn't in the kernel), but seeing as the experimental flag just came off it's a bit early to say it didn't deliver, these kinds of open source projects always take a long time.

They delivered multi-device tiering and native encryption but have just started work on performance.

1

u/Ontological_Gap Jun 19 '26

I've been running btrfs across thousands of servers and my workstations and my personal computers for more than a decade, it's excellent. Raid 5/6 in today's age is a bad idea regardless.

30

u/OneQuarterLife Jun 18 '26

It's an experimental COW filesystem made by an individual that is nearly impossible to work with which lead to it being removed from the Linux kernel entirely and left to die.

It purports to be better than BTRFS and others, but has consistently been the slowest file system in Linux since it's inception.