Bcachefs removed from the mainline kernel [LWN.net]

Risks

Posted Sep 30, 2025 10:30 UTC (Tue) by patrakov (subscriber, #97174) [Link] (6 responses)

Before Bcachefs getting mainlined, one had to get the whole kernel source tree from the Bcachefs author. This happened because this filesystem relied on changes in other subsystems, and was not just a self-contained add-on. Upon upstreaming, the required changes were applied to these subsystems, making Bcachefs self-contained, and then it was split out as a module that can be compiled via DKMS.

Here I see the risk of the mainline kernel reverting the changes in other subsystems, because they might no longer have an in-tree user. Am I paranoid? What's the Bcachefs project's position on this risk if it is material - are they going to adapt, or go back to telling the user to compile their tree, as opposed to compiling just their module against an existing kernel?

Risks

Posted Sep 30, 2025 16:45 UTC (Tue) by georgh-cat (guest, #158897) [Link]

That's exactly my thought as well, and the kind of conversation that is impossible in phoronix (but it should)

Risks

Posted Oct 1, 2025 1:07 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

As a concrete example, there are now no in-kernel users for start_removing_user_path_at() (recently renamed from user_path_locked_at()).
I wonder how long until someone decides to remove that because there are no users.

Risks

Posted Oct 2, 2025 12:34 UTC (Thu) by aakef (subscriber, #38030) [Link]

It is a bit sad, adding a bcachefs-updates dkms module with features that would appear in the next kernel version would have been simple. I.e. the entire _final_ way to upset Linus and everyone else in kernel community was absolutely not needed. Bcachefs could have stayed in kernel and bcachefs-updates could had all the features/fixes that upstream thought is required. And no issue with functions/exports that might get removed now.

Risks

Posted Oct 1, 2025 10:08 UTC (Wed) by tux3 (subscriber, #101245) [Link] (2 responses)

Well, there is precedent there, so I wouldn't be entirely surprised.

ZFS's compatibility layer used to call kallsyms_lookup_name (years before that was unexported).
They managed to remove all uses of it, although my slightly caricaturistic view of ZFS is that of a monolith that transcends all layer boundaries and is more than happy to implement their own deeply integrated features (ARC, etc) instead of importing an existing interface. That's not how I see bcachefs, although it does have plenty of integrated features.

And sometimes it's not an option. Systemtap wouldn't be viable if it could only lookup exported symbols, so they hack around it with the kernel text base and relocations:
> We do this under protest. The kernel ought expose this data to
> modules such as ourselves, but instead the upstream community
> continually shrinks its module-facing interfaces, including this
> stuff, even when users exist.
> PR26074: as of kernel 5.7+ / commit 0bd476e6c671 and under further
> protest, we must also send the address of kallsyms_lookup_name and
> kallsyms_for_each_symbol.

Hard to predict whether bcachefs will be given the "ZFS treatment", but I imagine there's three paths in response.
Try to workaround the missing symbol, go back in tree, or fight a cat-and-mouse game to keep DKMS.

systemtap kallsyms_lookup_name

Posted Oct 1, 2025 21:47 UTC (Wed) by gioele (subscriber, #61675) [Link] (1 responses)

> And sometimes it's not an option. Systemtap wouldn't be viable if it could only lookup exported symbols, so they hack around it with the kernel text base and relocations:
>> We do this under protest. The kernel ought expose this data to
>> modules such as ourselves, but instead the upstream community
>> continually shrinks its module-facing interfaces, including this
>> stuff, even when users exist.
>> PR26074: as of kernel 5.7+ / commit 0bd476e6c671 and under further
>> protest, we must also send the address of kallsyms_lookup_name and
>> kallsyms_for_each_symbol.

In case anybody is wondering where this text comes from (I could not find any references to this passage via Google Search or DuckDuckGo), it is from `[systemtap]/staprun/staprun.c` (<https://sourceware.org/git/?p=systemtap.git;a=blob;f=stap...>). The PR mentioned in the comment can be seen at <https://sourceware.org/git/?p=systemtap.git;a=commit;h=1e...>.

systemtap kallsyms_lookup_name

Posted Oct 3, 2025 10:11 UTC (Fri) by ferringb (subscriber, #20752) [Link]

System tap wasn't causative, but zfs presumably was. https://lwn.net/Articles/813350/ . If you're non GPL but using a side door to access symbols that are GPL limited... Etc.

Decision process

Posted Sep 30, 2025 12:44 UTC (Tue) by daeler (subscriber, #130460) [Link] (3 responses)

Just curious, no judgement: How is this decision made? Can Linus just decide that he removes something from the kernel?

Decision process

Posted Sep 30, 2025 12:56 UTC (Tue) by corbet (editor, #1) [Link]

Yes, Linus can make that kind of decision. He doesn't just do it on his own, though; there was a long series of public and private discussions that led up to this one.

Decision process

Posted Sep 30, 2025 12:57 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> Can Linus just decide that he removes something from the kernel?

Linus (just like everyone else with the Linux sources, can add or remove anything he wants.

Of course, nobody else is forced to get "Linux" from him directly. Indeed, the vastly overwhelming majority of Linux users get their kernel from someone else, with features, drivers, and fixes not present in, or removed outright from, Linus's Linux.

Decision process

Posted Sep 30, 2025 13:37 UTC (Tue) by Lionel_Debroux (subscriber, #30014) [Link]

Note that things go the other way round as well: security fixes available in Linus' Linux but missing from other kernels because the backporting process didn't occur for some reason (difficulty, interest, etc.).
The older a third-party kernel version is, the more it is likely to be missing both backports for security fixes, and vulnerabilities in code introduced in newer versions but not backported to the given third-party kernel (some vendors perform large amounts of backports to their franken-kernels).

I think this was the right thing

Posted Sep 30, 2025 15:41 UTC (Tue) by DemiMarie (subscriber, #164188) [Link] (46 responses)

I don’t think that experimental filesystems belong upstream. The need to get fixes out super quickly to recover user’s data does not mix well with the upstream kernel’s release cycle. Once a filesystem has settled down and emergency fixes are less likely, upstreaming makes a lot more sense.

The only exception I can think of is if recovery is handled almost entirely in userspace, which is not tied to the kernel release cycle.

I think this was the right thing

Posted Sep 30, 2025 15:45 UTC (Tue) by intelfx (subscriber, #130118) [Link]

The problem is that according to Linus' et al. philosophy (which subsequently dictates their actions), everything belongs upstream and out-of-tree modules kinda sorta "do not exist". No changes to kernel internals are accepted (or, conversely, refused) to accommodate out-of-tree modules, and the mentioned people are kind of very vocal in asserting that.

So if you're developing something that "does not belong upstream", the second you need an in-kernel API modified to suit your code (or, conversely, the second an in-kernel API is modified in such a way that harms your code) — you are SOL.

I think this was the right thing

Posted Sep 30, 2025 17:29 UTC (Tue) by roryi (subscriber, #25099) [Link] (43 responses)

It was very clearly marked as being experimental, though. I find it hard to understand who could possibly be using an experimental filesystem in a bleeding-edge kernel for important data without backups. And, honestly, it feels like there's potentially a more serious problem here than any of the much-aired interpersonal issues.

Has someone been actively recommending use of bcachefs to naive end users? Is there such a thing as a meme filesystem - and if so, has bcachefs somehow become one? Is there a rogue forum poster / youtuber / tiktoker out there tricking people into such risky behaviour without realising the implications?

I think this was the right thing

Posted Sep 30, 2025 18:30 UTC (Tue) by GNUtoo (guest, #61279) [Link] (1 responses)

> It was very clearly marked as being experimental, though. I find it hard to understand who could possibly be using an experimental filesystem in a bleeding-edge kernel for important data without backups.

It is also not a binary situation.

I do use a filesystem that is not as stable as ext4 for data that can be re-created (basically my root filesystem, most of the configuration needed to recreate it is in git, and the rest can either be recreated fast or it is on a separate ext4 filesystem), because I also need some more advanced features that ext4 doesn't provide (reflinks, and maybe subvolumes).

Now the real questions to understand if it is worth the risk for me are things like:

- How long a re-installation takes
- How frequent will the data loss be

And of course the filesystem features, resources consumption, availability, etc are also taken into the equation.

If I've too frequent data loss, I might try another filesystem instead, and any improvement in reliability is good.

But even with backups, there is some risk involved as I might have an older backup, it might crash at exactly the wrong moment before I do a git push, etc.

So improving the reliability is always good, though it can have costs too.

So personally I see things more in a scale like with ext4 probably being the most stable if used properly (frequent fsck), BTRFS being less stable, and NILFS2 even less stable. Though this is highly subjective as this also includes from personal experience (your mileage may vary) and it is even scattered over time (things do evolve).

I think this was the right thing

Posted Oct 1, 2025 11:25 UTC (Wed) by Sesse (subscriber, #53779) [Link]

> I also need some more advanced features that ext4 doesn't provide (reflinks, and maybe subvolumes).

You don't mention it, but it's possible that xfs would be a good fit for you. It supports reflinks but not subvolumes (and also a few niceties like online fsck), and has a generally good track record. (It used to give me problems with its journal recovery back in 1999, but those days are long gone.)

I think this was the right thing

Posted Sep 30, 2025 20:53 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link] (37 responses)

I think you've got this entirely backwards.

A good fraction of the bcachefs users are using it because they've been burned and lost entire filesystems on btrfs, and needed something more reliable - they've found bcachefs to be that.

"Meme filesystem"? Seriously? I'm just trying to get users a modern filesystem that's actually bulletproof - and succeeding, aside from upstream drama.

I think this was the right thing

Posted Oct 1, 2025 1:03 UTC (Wed) by ebiederm (subscriber, #35028) [Link] (17 responses)

You have a mode where you simply do not comprehend what other people say to you. That mode causes problems when interacting with other people.

I hope this split from the mainstream kernel takes some of the pressure off and allows you to make progress.

I think this was the right thing

Posted Oct 1, 2025 3:09 UTC (Wed) by buck (subscriber, #55985) [Link] (9 responses)

I don't think anything in Mr. Overstreet's comment warranted the ad-hominem reply. He merely proposed that happy bcachefs users were not generally there because they were swept up by the latest fad but had instead found something they calculated was a better guarantor of their data availability and integrity than the alternatives, as a counterpoint to supposing anybody using bcachefs was unserious. In taking up for his users, i don't see any hint of bad faith or disparagement of anything else, except for the oblique implication that there are filesystems that some users consider less reliable than his but not even hinting which they might be.

(Note: I am not a bcachefs user. I may also be unserious, but not this time.)

I think this was the right thing

Posted Oct 1, 2025 8:00 UTC (Wed) by Nikratio (subscriber, #71966) [Link] (1 responses)

With "the oblique implication that there are filesystems that some users consider less reliable than his but not even hinting which they might be", do you mean "they've been burned and lost entire filesystems on btrfs"?

If you look at other communication, you'll find that Kent is generally unable to discuss something without immediately disparaging other developers, filesystems, or packagers.

I think this was the right thing

Posted Oct 14, 2025 11:13 UTC (Tue) by taladar (subscriber, #68407) [Link]

Having read many of the discussions on this bcachefs issue here on LWN I have only ever seen Kent be professional while many others seemed to personally attack him.

I think this was the right thing

Posted Oct 1, 2025 11:01 UTC (Wed) by josh (subscriber, #17465) [Link] (4 responses)

> warranted the ad-hominem

"ad-hominem" does not apply to the comment you're responding to. It applies when you dismiss someone's argument not because it's false but because of some unrelated property of themselves. It doesn't describe comments on someone's personal issues that are not being used to dismiss someone's arguments. In particular, ad-hominem doesn't typically apply to meta-commentary on someone's argumentative style and raising issues with it. "X is obnoxious behavior that makes it really annoying to try to talk to you" is not typically ad-hominem.

For instance (two entirely made-up examples with intentionally zero subtext):

"Your argument is incorrect because your shirt is wrinkled and therefore you are insufficiently fastidious to be taken seriously about this" is an ad-hominem.

"You have a habit of wringing your shirt with your hands, perhaps because you're nervous, which leads you to go on stage with a wrinkled shirt, and you might want to work on that" is not an ad-hominem. Note in particular that it is not attacking someone's argument by making an unrelated personal observation; it's telling someone that there's a problem they have that is affecting how they come across to others, and suggesting that they fix it.

I think this was the right thing

Posted Oct 2, 2025 2:23 UTC (Thu) by buck (subscriber, #55985) [Link] (3 responses)

I bow to your mastery of rhetoric.

I was not classically educated and was being a rube, trying to sling some Latin, trying to avoid saying, "personal", but turns out i made a more offensive accusation.

Sorry

Still seems to me some folks were overreacting to Mr. Overstreet's one comment that had been posted (as of the time i wrote anyway), which, prima facie, did not seem like a dig at anybody or their work. Is there some rationale for not addressing his comment on the merits? Maybe i'm just being obtuse, sorry

I think this was the right thing

Posted Oct 2, 2025 11:00 UTC (Thu) by ferringb (subscriber, #20752) [Link] (2 responses)

> Still seems to me some folks were overreacting to Mr. Overstreet's one comment that had been posted (as of the time i wrote anyway), which, prima facie, did not seem like a dig at anybody or their work. Is there some rationale for not addressing his comment on the merits? Maybe i'm just being obtuse, sorry

An example of the context you're missing is https://lwn.net/Articles/1035736/ . That includes examples of what you think folks should do, and kernel folk commentary it's long since been doing. LKML ain't exactly the nicest place, for them to level a CoC, let alone someone's entire project being ejected from the kernel, this isn't something that is because of a one off.

When you're going through that thread, I suggest you pay attention to the harassment of the debian dev (*again*). That's deeply unacceptable, and I suspect overstreet- in a year from now after this latest incident- will hope that there isn't someone doing exactly what he's been doing to others.

I think this was the right thing

Posted Oct 2, 2025 12:54 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (1 responses)

Oh boy.

> An example of the context you're missing is https://lwn.net/Articles/1035736/ . That includes examples of what you think folks should do, and kernel folk commentary it's long since been doing. LKML ain't exactly the nicest place, for them to level a CoC, let alone someone's entire project being ejected from the kernel, this isn't something that is because of a one off.

Others have noted that incident was on the whole rather tame, even for what passes on LKML today (I'm reading the news on Phoronix right now, and - oh boy, the level of toxicity really hasn't changed) - and that screwup had pretty far reaching consequences.

And re: Debian, I was talking about issues bcachefs has had with release process, and you're somehow painting that as harassment?

That's pretty unbelievable.

Look, I think the actual harassment going on here is pretty clear, and it crowds out all the actual technical discussions we could be having.

I think this was the right thing

Posted Oct 2, 2025 23:36 UTC (Thu) by ferringb (subscriber, #20752) [Link]

I just want to point out the blatantly obvious here; you're arguing against my advice that people just read your damn posts and interactions. OP asked why people respond this way, why they don't engage in your arguments; that thread demonstrates why there is the communal pattern.

If you don't think people should read your flamewars to understand the interaction, don't flamewar.

> And re: Debian, I was talking about issues bcachefs has had with release process, and you're somehow painting that as harassment?
> That's pretty unbelievable.

https://lwn.net/Articles/1035890/ (people should read it in full). Also your general justification for taking unrelated, deeply pointless and technically unproductive, potshots/attacks: https://lwn.net/Articles/1035878/

> I think the actual harassment going on here is pretty clear,

Few things that harassment isn't:
* People disagreeing with your posts and behavior within a community, and engaging you disagreeing.
* Linking your own posts were you are attacking others
* Suggesting people read your thread interactions and make up their own damn mind (in particular, reading in full rather than just the 2 examples I gave as a synopsis).

This is a good stopping point; as I said, folks should just read https://lwn.net/Articles/1035736/ .

I think this was the right thing

Posted Oct 3, 2025 4:22 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> He merely proposed that...

Imagine A and B are debating question X together.

C is around. He overhears and misunderstands a small bit, which reminds of topic Y. He joins A and B and "merely proposes" Y for 2 minutes.

But the connection between topic X and Y is tenuous and topic Y is of interest to neither A nor B. By sheer "coincidence", topic Y also allows C to brag a fair bit and to disparage some stuff done by others for some bonus points.

This sort of situation is not unusual, especially after a few drinks. I bet most people have seen it at least once.

But now, imagine C does this sober and in many of his social interactions. Like a "mode"?

PS: it becomes even more fun when it snowballs with D, E and F overhearing incomplete and different parts of Y and joining the (lack of) "conversation". Now this is almost comedy material. Or drama - often closer to each other than we think.

Here too, please stop

Posted Oct 3, 2025 4:30 UTC (Fri) by jake (editor, #205) [Link]

[ also not aimed at marcH only ]

This sub-thread lost whatever value it once had, can we please just let it rest?

thanks,

jake

I think this was the right thing

Posted Oct 1, 2025 10:48 UTC (Wed) by paulj (subscriber, #341) [Link] (6 responses)

I've besought Kent to stop posting a few times. He just can't help himself it seems. He appears to be unable to promote bcachefs without throwing digs (subtle and not so subtle) at other kernel developers. He seems unaware that he is doing this, or else of the effect of this style of communication.

Please Kent... just don't talk about other kernel subsystems, other people's kernel code (inc. kernel code generally). And... given you struggle with not pushing down on others (directly or indirectly)... just stay off forums. Please.

I think this was the right thing

Posted Oct 2, 2025 6:25 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

It's not happening :)

I think this was the right thing

Posted Oct 2, 2025 23:15 UTC (Thu) by neggles (subscriber, #153254) [Link] (1 responses)

As in, you're not going to stop posting/responding to bait in comment/ML threads? that doesn't really seem like something to be proud of, especially considering the resulting harm to bcachefs and its users

Imagine how much more development work you could get done if you didn't waste time "talking shit" (for lack of a better phrase)

I think this was the right thing

Posted Oct 3, 2025 0:18 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link]

On a subject as heated as... nearly everything bcachefs has been lately, there's often no firm line between 'bait' and legitimate discussions.

You can wish that all the offtopic, trollish stuff would just go away (and believe me I do), but ignoring it won't make it so. Ignoring it would only work if we had heavy handed moderators that could take that on, and I don't think we want that either.

And like I said, there's generally no real firm line between 'bait' and legitimate discussion, so you'd be leaving aside a lot of potentially productive discussion.

People talk a lot about abstract 'harm' these days too, and I don't see any actual justification for that.

Anyways, I took the prior comment as a wish that I would just stop appearing in public and do nothing but write code for everyone else to use. And to that I say - hell no :)

I think this was the right thing

Posted Oct 7, 2025 16:16 UTC (Tue) by nye (subscriber, #51576) [Link] (2 responses)

> I've besought Kent to stop posting a few times. He just can't help himself it seems

FWIW I've considered muting you for your frequent, typically baseless, and often unpleasant personal attacks, mostly against Kent. It's clear that you personally hate him for some reason; I think this is clouding your judgement.

> just stay off forums. Please

Indeed...

I think this was the right thing

Posted Oct 7, 2025 16:26 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

It's the opposite. I want Kent to succeed in making bcachefs a really good, modern, stable, self-integrity-checking FS available in Linux.

https://lwn.net/Articles/1027605/
https://lwn.net/Articles/1036511/
https://lwn.net/Articles/1036170/

I think this was the right thing

Posted Oct 7, 2025 19:08 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link]

Well, just dial back on the unsolicited advice, then :)

Whenever there's chaos and drama, everyone sizes on that and assumes the sky is falling and shows up with all sorts of funny, very instantly worded "advise".

It makes it hard to bring the focus back to productive technical conversations, where it needs to be.

Trust me, I'm the one writing you all a better filesystem, and I've got this :)

Now that kernel community and Linus drama are behind us, things are operating much more smoothly. Usage jumped up with the announcement of DKMS packages; some new bug reports but nothing serious.

We should still be on track for lifting the experiment label by the end of the year, and I'm enjoying nice quite days of just getting work done.

Lately that's been a big codebase reorg (súbdirs!) so new people can find their way around, and rebalance_v2 is nearly done.

Good stuff is coming, be patient :)

I think this was the right thing

Posted Oct 1, 2025 4:23 UTC (Wed) by rolexhamster (guest, #158445) [Link] (18 responses)

A good fraction of the bcachefs users are using it because they've been burned and lost entire filesystems on btrfs, and needed something more reliable - they've found bcachefs to be that.

It's easy to state the above, but the usual "citation needed" caveat applies.

Is there evidence to concretely state that, right now, btrfs (as of linux kernel 6.17) is less stable / more fragile than bcachefs (as of the DKMS version today) ?

This isn't about the historical (in)stability of btrfs at its development stage compared to (in)stability of bcachefs at the equivalent point in its development stage. This is also not about differences in feature sets.

This is about how things stand right now, as in is btrfs or bcachefs more reliable today, for plain non-fancy desktop usage.

(Disclaimer: I don't use btrfs or bcachefs. All my systems are on ext4, mainly due to inertia).

I think this was the right thing

Posted Oct 1, 2025 5:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Apparently people still don't trust btrfs's own advanced RAID modes: https://btrfs.readthedocs.io/en/latest/Status.html I absolutely got burned by it when booting degraded arrays and trying to reassemble them.

Another thing, btrfs support for multi-device setups is still not great, while bcachefs shines there. It's possible to configure complex cache hierarchies, so that most data is stored on fast SSDs and only periodically migrated to slower HDDs: https://bcachefs.org/Caching/

I think this was the right thing

Posted Oct 1, 2025 10:12 UTC (Wed) by gdamjan (subscriber, #33634) [Link]

meanwhile, bcachefs didn't mount a single device filesystem when kernel version (and bcachefs version) changed. luckily it wasn't the root device but an auxiliary one.

I do like to see the bcachefs project succeed, but its glory seems to me to be greatly exaggerated.

I think this was the right thing

Posted Oct 1, 2025 10:21 UTC (Wed) by ferringb (subscriber, #20752) [Link]

> Apparently people still don't trust btrfs's own advanced RAID modes: https://btrfs.readthedocs.io/en/latest/Status.html I absolutely got burned by it when booting degraded arrays and trying to reassemble them.

I hope you're not referring to raid5/6... which should frankly be behind CONFIG_BTRFS_EXPERIMENTAL since it is *just* for experimental/development use. The design lacks protections against the write hole problem, something upstream has tried to inform people of but seems to frequently get ignored. Quoting:

---
The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.
---

The duplication functionality (raid1/c2, c3, etc) works fine and is what people use.

I think this was the right thing

Posted Oct 2, 2025 6:34 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (14 responses)

> Is there evidence to concretely state that, right now, btrfs (as of linux kernel 6.17) is less stable / more fragile than bcachefs (as of the DKMS version today) ?

The first thing to be aware of is that we don't have the kind of hard numbers on filesystem reliability that we'd like, no one does. For determining if a filesystem is 99.9%, 99.99%, etc. reliable - you'd really need telemetry.

So we have to go off of anecdotal data.

All that does in fact point to that:

- yes, btrfs does indeed still have reliability problems, and no one seems to know how to debug them

- bcachefs has been shaping up _fast_, and I think the userbase is big enough that I can conclusively say it's less fragile than btrfs. We simply haven't been seeing unrecoverable issues at any stage of development - barring ~1 or 2 extreme outliers that were solved quickly - and we seem to be pretty well past stability issues in general.

I think this was the right thing

Posted Oct 2, 2025 15:07 UTC (Thu) by rolexhamster (guest, #158445) [Link] (13 responses)

So we have to go off of anecdotal data.

Okay, where? As in what specific bug reports on, say, kernel bugzilla or LMKL.

All that does in fact point to that: ...

Anecdotes are not reliable facts, though to give you the benefit of the doubt, the above may have been an unfortunate or unintended choice of words.

At the same time, one cannot rely on anecdotes to say that btrfs is in worse/better shape than bcachefs. Relying on anecdotes to make an argument sounds more like FUD.

... I can conclusively say [bcachefs is] less fragile than btrfs.

How, quantitatively? Going off vibes is not the same as actually measuring the number of corruptions, crashes, failed recoveries, etc. There needs to be a concerted side-by-side comparison (such as stress testing, deliberate random corruption, etc), similar to what Backblaze does with hard drive reliability measurements.

Back when development of bcachefs started (as in ~10 years ago), there were a lot of lingering questions on the reliability of btrfs. At that point in time, these questions were a fair motivation for aiming to create a better file system. However, since then btrfs has improved and now has the advantage of being stabilised (except RAID5/6) for a far longer time period than bcachefs.

I think this was the right thing

Posted Oct 2, 2025 15:16 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (12 responses)

Look, if you're trying to argue btrfs is fit for purpose, you're smoking something.

https://news.ycombinator.com/item?id=45432749
https://news.ycombinator.com/item?id=45428033
https://news.ycombinator.com/item?id=45429813

This is just from the most recent hacker news filesystem thread where btrfs came up, which took me about 5 minutes. If I spent an afternoon I could find you hundreds of user reports like this.

I think this was the right thing

Posted Oct 2, 2025 15:33 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

One of the first posts on that yc story, from someone who has long sponsored you apparently, has this:

> From a long time (and now former) sponsor: if these posts are actually from you, please stop.

If btrfs sucks and has many issues, users and others will notice. As a dev of a filesystem in a similar space, you should of course take note and learn what you can from those issues. But... is it really helping you to be out there posting in various forums about how bad btrfs is and how much better your fs is?

I think this was the right thing

Posted Oct 2, 2025 16:22 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (6 responses)

> If btrfs sucks and has many issues, users and others will notice. As a dev of a filesystem in a similar space, you should of course take note and learn what you can from those issues. But... is it really helping you to be out there posting in various forums about how bad btrfs is and how much better your fs is?

Excuse me? Follow the thread back to see where this started: bcachefs was called a "meme filesystem", and I was just explaining that there's a real demand for something better than btrfs.

_Every single time there's a bcachefs thread_ this happens. I start out explaining "yes, btrfs really does have issues, bcachefs really is delivering something better" and then people coming out swinging accusing me of attacking btrfs.

You're just trolling.

Let's stop here

Posted Oct 2, 2025 16:26 UTC (Thu) by jake (editor, #205) [Link] (1 responses)

[ Not directed at Kent only, by any means ]

This sub-thread does not seem to be going anywhere useful for anyone. Can we please stop it here?

thanks,

jake

Let's stop here

Posted Oct 2, 2025 17:06 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link]

Thanks Jake, I appreciate it.

I think this was the right thing

Posted Oct 3, 2025 2:47 UTC (Fri) by interalia (subscriber, #26615) [Link] (3 responses)

> bcachefs was called a "meme filesystem"

I just want to say that that wasn't how I read it in context and I think you may have overreacted. The subthread was started by DemiMarie:

> I don’t think that experimental filesystems belong upstream. [snip] The need to get fixes out super quickly to recover user’s data does not mix well with the upstream kernel’s release cycle.

In reply, roryi said:

> It was very clearly marked as being experimental, though. I find it hard to understand who could possibly be using an experimental filesystem in a bleeding-edge kernel for important data without backups. [snipped]

> Has someone been actively recommending use of bcachefs to naive end users? Is there such a thing as a meme filesystem - and if so, has bcachefs somehow become one? Is there a rogue forum poster / youtuber / tiktoker out there tricking people into such risky behaviour without realising the implications?

I understood this reply to DemiMarie to be saying: "bcachefs was okay being upstream, because it was clearly marked as experimental. I would normally expect anyone using a filesystem marked as such in the most recent kernels would only be using it with backups, or with expendable data."

I don't think roryi was asserting that bcachefs IS a meme filesystem. In response to DemiMarie talking about data recovery they were asking if numerous users had somehow used a newer experimental filesystem without precautions, and IF so asking how they came to do so, finally asking speculatively if use of a new experimental filesystem somehow became a social media thing and thus encourage inexperienced users to do so. I thought it was a slightly odd thing to ask but I didn't consider it to be denigrating bcachefs's actual technical quality, so the entire subthread after that became an overreaction.

I think this was the right thing

Posted Oct 3, 2025 3:29 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

Well, if you'd like my take on who was actually using it: serious users, who were doing their homework first, would often come by the IRC channel (or Reddit) and ask if it was ready for use.

Up until recently (~6 months ago?), it seemed I was perpetually telling the people who sounded less risk averse to "check back in six months"; this included people who had been bit by recent data loss on btrfs even when we'd hit the point where similar data loss was going to be unlikely on bcachefs (that's never been much of a concern on bcachefs, although we used to have a lot of "downtime event" bugs, until those were worked through).

There have been a few people who clearly ignored the experimental label and jumped in much too early and ended up unhappy and disgruntled, but - the people who ended up the most disgruntled are also the ones who like to tout their storage industry experience, so can't say I feel much for those guys :)

Generally speaking it's been a lot of younger hobbyists/tinkerers, or older people with spare machines who know exactly why we need this and have been investing significant amounts of time QAing and beating on it.

And for all the people I can talk because I've been interacting with, I should also mention there's a much larger userbase who hasn't been pushing all the various features quite as hard for whom it's been working just fine.

So there's a good mix. Some people are legitimately using bcachefs in production - less critical or less demanding scenarios - some are testing the limits, some people are putting it onto any old junk and running real workloads (!).

Especially in the last six months, it's gotten sufficiently solid that the "people running it on random junk with real production workloads crown" have been coming up with all kinds of stories of it quietly and happily humming along through dying hardware and god knows what else that people seem fairly confident would have rather upset btrfs or even ZFS.

So I don't think there's any reason for people to be taking special precautions at this point. The only special precaution you ever needed to take was "if it wedges itself, be patient and feed us logs/metadata dump so we can get you bugfixes", and even that's pretty much stopped and the bugs have become pretty mundane.

I think this was the right thing

Posted Oct 3, 2025 4:18 UTC (Fri) by interalia (subscriber, #26615) [Link] (1 responses)

That's fine and all Kent, but I didn't ask about bcache's current users and maturity.

Rather than diverting my post into discussion of that, I'd be more interested in an acknowledgement that you might have misinterpreted what roryi said, or reasons why you think your interpretation was indeed correct if there was further context or subtext I didn't see.

Please, stop

Posted Oct 3, 2025 4:25 UTC (Fri) by jake (editor, #205) [Link]

[ again, this is not only aimed at interalia ]

This sub-thread is really not going anywhere very useful for anyone.

Please end it here.

thanks,

jake

I think this was the right thing

Posted Oct 2, 2025 15:47 UTC (Thu) by rolexhamster (guest, #158445) [Link] (1 responses)

if you're trying to argue btrfs is fit for purpose, you're smoking something.

Really Ken? The above response is quite disrespectful and dismissive.

My aim here is to have an intelligent (and polite) conversation about various potential merits/demerits of btrfs and bcachefs. As I've stated before, I don't use either btrfs or bcachefs, so all the questions and observations I have made are coming from a 3rd party point of view.

I think this was the right thing

Posted Oct 2, 2025 16:17 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link]

Why not do me the courtesy of getting my name right?

I think this was the right thing

Posted Oct 7, 2025 0:03 UTC (Tue) by Kamilion (guest, #42576) [Link] (1 responses)

Uh.... why do I see zero references to btrfs-recovery in any of these?

They're great anecdotes, but my realworld experience has been that most other filesystems have no recovery tools at all.
And I don't mean, "fix the filesystem", I mean, "other catastrophic failure occurred."

I've had a *lot* of spindles die, and have always been able to ask btrfs to drop the disk out of the array *before* any further problems occurred.

What other filesystem can even *do* that safely?

As far as I know, the only recovery tools for ext2/3/4, xfs, and the microsoft filesystems, other than testdisk, are commercial software.
Those hacker news posts are full of doing very silly things which will also break most recovery tools. Tossing md in the mix makes it nearly unrecoverable. lvm metadata loss has eaten more arrays than I can count in the field, which is why we ditched it a decade ago. Tradeins and RMAs went down significantly afterwards.

So far, I have *never* encountered an operational spindle that btrfs-recover could not extract customer data from.

*everything fails*. Having a path for recovery after failure is priceless. btrfs gigablocks are such a simple concept writ large that contribute to that path's viability.

XFS's correctness tests are quite nice and all, but if the on-disk structures present a problem to recover from without mounting, it's a major issue for deployments hosting unique data.

For every list of people having problems you can search up in 5 minutes, there's another batch of us who have found it reliable, and we are largely silent, busy doing our workloads.

I think this was the right thing

Posted Oct 14, 2025 11:25 UTC (Tue) by taladar (subscriber, #68407) [Link]

Most filesystems "can't" drop a disk out of an array before a problem occurs because RAID is completely out of scope for them, that is what mdraid or hardware RAIDs or LVM are used to solve with those.

When code should be upstream

Posted Oct 3, 2025 5:53 UTC (Fri) by DemiMarie (subscriber, #164188) [Link] (1 responses)

A more accurate version of what I wrote: Given my current understanding, I believe that code does not belong upstream if it is likely to need new features on an emergency basis. It is also my understanding that bcachefs is still in this phase. However, I hope that it is not in this phase forever! I want bcachefs to be upstream. Although I don’t use it right now, there is a nonzero chance that I will use it in the future. I might even contribute code someday if a project I am working on requires it. However, I think that having bcachefs be a DKMS module is the best for now.

As a potential user, I will add that I would be fine with falling back to offline userspace fsck if there is something kernel fsck can’t correct. If the choice is between an upstreamed bcachefs and between bcachefs always being able to recover from errors online, I would be much happier with the former. I absolutely care about getting my recent work back, but I’m willing to accept downtime to do it.

When code should be upstream

Posted Oct 3, 2025 7:50 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link]

> As a potential user, I will add that I would be fine with falling back to offline userspace fsck if there is something kernel fsck can’t correct. If the choice is between an upstreamed bcachefs and between bcachefs always being able to recover from errors online, I would be much happier with the former. I absolutely care about getting my recent work back, but I’m willing to accept downtime to do it.

This really isn't something we can force on people; it's outside the normal workflow, so if you have to fall back to the latest userspace fsck it generally means you have to boot from a recovery image.

Having all the normal recovery code available in userspace is incredibly useful as a debugging aid - it was never intended to be something users would be expected to run because we can't ship repair code as part of the filesystem. That puts everyone in a difficult position.

Besides the additional deployment challenges, if we're ever in tricky recovery scenarios it's not ideal because it removes the ability to do a dry run repair-and-mount where the user can then verify (by looking at the filesystem contents) that everything worked as expected.

> Given my current understanding, I believe that code does not belong upstream if it is likely to need new features on an emergency basis. It is also my understanding that bcachefs is still in this phase. However, I hope that it is not in this phase forever!

Keep in mind that feature development is not going to stop when the experimental label is lifted.

The rate at which we need to deploy bugfixes and the complexity of those bugfixes has already slowed down dramatically from what we were seeing midway through the 6.16 cycle, as expected.

But code is never perfect, so we need defense in depth.

It's that "defense in depth" that has been missing from a lot of the thinking and discussions on how we stabilize, ship and support a filesystem. That means good automated testing, good QA by an involved community, and it also means a functioning pipeline for getting fixes out quickly when required.

Good defense in depth means that every stage of defense catches as much as it can; it starts with having a good clean codebase with good assertions, where complex bugs shouldn't happen often and bugs should be caught quickly by large automated test suite with good test coverage. But we never plan on any one stage catching everything... with everything that has to work, we have backups, and redundancies, and failsafes.

Back before we had good automated testing, and when codebases were more fragile, we were much more afraid to deploy complicated bugfixes than we are today. If you compare how ext4 handles code freezes vs. more modern codebases, you can see that in action; the risk of a bad bugfix doing more damage was very real.

But more modern QA means we can validate code quicker and more effectively, and when the situation calls for that we can and should use that for shipping bugfixes to ensure user access to data with minimal downtime, when we can do so safely.

And modern filesystems are much more complex today, so we need to be using all the tools in our toolbox.

I think this was the right thing

Posted Oct 3, 2025 9:04 UTC (Fri) by jmalcolm (subscriber, #8876) [Link]

> I find it hard to understand who could possibly be using an experimental filesystem in a bleeding-edge kernel for important data

I have been using bcachefs since it was added to mainline Linux. I was cautious at first but have moved more an more systems to it. I have it as the root filesystem on some of them, including the laptop I am typing on.

> without backups

Ok. Where did that come from? I did not say "without backups".

That said, I have not needed backups. I have not had any data loss. The filesystem has been great.

Sadly, I now have to worry that this machine will stop working when my distro ships kernel 6.18 (I am on 6.16 now).

I think this was the right thing

Posted Oct 1, 2025 14:55 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

Experimental stuff in the kernel has to be selected on purpose, it isn't included willy-nilly. Downstream (i.e., distributions) should never enable that stuff. Open Source 101.

end of Linux

Posted Oct 1, 2025 19:55 UTC (Wed) by snajpa (subscriber, #73467) [Link] (1 responses)

this marks end of Linux as the one project everyone agrees on and contributes to - it might take decades for any new kernel to overtake Linux, but it’s coming now

because this marks the end of Linux as a common go to project where operating systems research is realized, as it is clearly not for everyone with the skill anymore

I’m glad that this happened

end of Linux

Posted Oct 1, 2025 19:57 UTC (Wed) by mb (subscriber, #50428) [Link]

>this marks end of Linux as the one project everyone agrees on

This is really funny.
Are you new to Linux? :)

What about missing (diabled) functionality?

Posted Oct 2, 2025 14:06 UTC (Thu) by geert (subscriber, #98403) [Link]

After the removal of bcachefs, the following options are no longer enabled in my .config (they were selected by BCACHEFS_FS before):
XARRAY_MULTI
CLOSURES
MIN_HEAP

Missing CLOSURES and MIN_HEAP are easy to handle, as the bcachefs module can just include a copy.
But XARRAY_MULTI has a big impact on how xarray works, and can't easily be bolted-on from a module.
How does DKMS handle that?

XARRAY_MULTI is also selected by a few other options (e.g. HUGETLB_PAGE, TRANSPARENT_HUGEPAGE, and ZONE_DEVICE), so most distro kernels on x86 may have it.