Bcachefs may be headed out of the kernel
65 comments
·July 4, 2025criticalfault
pmarreck
This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time.
It's a damn shame too because bcachefs has some unique features/potential
Pet_Ant
Why take it out of the kernel? Why not just make someone responsible the maintainer so they can say "no, next release" to his shenanigans? It can't be the license.
tliltocatl
Maintainers aren't getting paid and so cannot be "appointed". Someone must volunteer - and most people qualified and motivated enough are already doing something else.
timewizard
Presumably there would be an open call where people would nominate themselves for consideration. These are problems that have come up and been solved in human organizations for hundreds of years before the kernel even existed.
nolist_policy
Kent can appoint a suitable maintainer if he wishes. That's his job, not Linus'.
criticalfault
This is for me unclear as well, but I'm saying I wouldn't hold it against Linus if he did this. And based on Kent's behavior he has full right to do so.
A way to handle this would be with one person (or more) in between Kent and Linus. And maybe a separate tree only for changes and fixes from bcachefs that those people in between would forward to Linus. A staging of sorts.
ajb
Yeah.. the thing is, suppose Kent was 100% right that this needed to be merged in a bugfix phase, even though it's not a bug fix. It's still a massive trust issue that he didn't flag up that the contents of his PR was well outside the expected.
That means Linus has to check each of his PRs assuming that it might be pushing the boundaries without warning.
No amount of post hoc justification gets you that trust back, not when this has happened multiple times now.
NewJazz
He mentioned it in his PR summary as a new option. About half of the summary of the original PR was talking about the new option and why it was important.
https://lore.kernel.org/linux-fsdevel/4xkggoquxqprvphz2hwnir...
chasil
So the assertion is that users with (critical) data loss bugs need complete solutions for recovery and damage containment with all possible speed, and without this "last mile" effort, stability will never be achieved.
The objection is the tiniest bug-fix windows get everything but the kitchen sink.
These are both uncomfortable positions to occupy, without doubt.
koverstreet
No, the assertion is that the proper response to a bug often (and if it's high impact - always) involves a lot more than just the bugfix.
And the whole reason for a filesystem's existence is to store and maintain your data, so if that is what the patch if for, yes, it should be under consideration as a hotfix.
There's also the broader context: it's a major problem for stabilization if we can't properly support the people using it so they can keep testing.
More context: the kernel as a whole is based on fixed time tables and code review, which it needs because QA (especially automated testing) is extremely spotty. bcachefs's QA, both automated testing and community testing, is extremely good, and we've had bugfix patchsets either held up or turn into flamewars because of this mismatch entirely too many times.
NewJazz
I don't think you need to or should be participating in these threads. It simply isn't good for your mental health, but more importantly I think you have better ways to spend your time.
koverstreet
Oh my. Got any other prescriptions for me? :)
It's a bcachefs thread, and I'm the resident bcachefs expert, so.... :)
I'm not terribly invested in these threads, the actual decisionmaking happens elsewhere. But they are a good opportunity to educate people on the whole process of shipping a filesystem, talk about what we're doing, what our priorities are, all that jazz.
dralley
I donate to Kent's patreon and I'm very enthusiastic about bcachefs.
However, Kent, if you read this: please just settle down and follow the rules. Quit deliberately antagonizing Linus. The constant drama is incredibly offputting. Don't jeopardize the entire future of bcachefs over the silliest and most temporary concerns.
If you absolutely must argue about some rule or other, then make that argument without having your opening move be to blatantly violate them and then complain when people call you out.
You were the one who wanted into the kernel despite many suggestions that it was too early. That comes with tradeoffs. You need to figure out how to live with that, at least for a year or two. Stop making your self-imposed problems everyone else's problems.
thrtythreeforty
I did subscribe to his Patreon but I stopped because of this - vote with your wallet and all that. I would happily resubscribe if he can demonstrate he can work within the Linux development process. This isn't the first time this flavor of personality clash has come up.
Kent is absolutely technically capable of, and has the vision to, finally displace ext4, xfs, and zfs with a new filesystem that Does Not Lose Data. To jeopardize that by refusing to work within the well-established structure is madness.
NewJazz
Seriously how hard is it to say "I'm unhappy users won't have access to this data recovery option but will postpone its inclusion until the next merge window". Yeah, maybe it sucks for users who want the new option or what have you, but like you said it is a temporary concern.
msgodel
The older I get the more I feel like anything other than the ExtantFS family is just silly.
The filesystem should do files, if you want something more complex do it in userspace. We even have FUSE if you want to use the Filesystem API with your crazy network database thing.
heavyset_go
Transparent compression, checksumming, copy-on-write, snapshots and virtual subvolumes should be considered the minimum default feature set for new OS installations in TYOOL 2025.
You get that with APFS by default on macOS these days and those features come for free in btrfs, some in XFS, etc on Linux.
yjftsjthsd-h
I mean, I'd really like some sort of data error detection (and ideally correction). If a disk bitflips one of my files, ext* won't do anything about it.
timewizard
> some sort of data error detection (and ideally correction).
That's pretty much built into most mass storage devices already.
> If a disk bitflips one of my files
The likelihood and consequence of this occurring is in many situations not worth the overhead of adding additional ECC on top of what the drive does.
> ext* won't do anything about it.
What should it do? Blindly hand you the data without any indication that there's a problem with the underlying block? Without an fsck what mechanism do you suppose would manage these errors as they're discovered?
anonnon
> The older I get the more I feel like anything other than the ExtantFS family is just silly.
The extended (not extant) family (including ext4) don't support copy-on-write. Using them as your primary FS after 2020 (or even 2010) is like using a non-journaling file system after 2010 (or even 2001)--it's a non-negotiable feature at this point. Btrfs has been stable for a decade, and if you don't like or trust it, there's always ZFS, which has been stable 20 years now. Apple now has AppFS, with CoW, on all their devices, while MSFT still treats ReFS as unstable, and Windows servers still rely heavily on NTFS.
NewJazz
CoW is an efficiency gain. Does it do anything to ensure data integrity, like journaling does? I think it is an unreasonable comparison you are making.
robotnikman
>Windows will at some point have ReFS
They seem to be slowly introducing it to the masses, Dev drives you set up on Windows automatically use ReFS
leogao
btrfs has eaten my data within the last decade. (not even because of the broken erasure coding, which I was careful to avoid!) not sure I'm willing to give it another chance. I'd much rather use zfs.
milkey_mouse
Hell, there's XFS if you love stability but want CoW.
josephcsible
XFS doesn't support whole-volume snapshots, which is the main reason I want CoW filesystems. And it also stands out as being basically the only filesystem that you can't arbitrarily shrink without needing to wipe and reformat.
msgodel
Again I don't really want the kernel managing a database for me like that, the few applications that need that can do it themselves just fine. (IME mostly just RDBMSs and Qemu.)
layer8
For some reason I always read this as “BCA chefs”.
baggy_trough
No matter how good the code is, Overstreet's behavior and the apparent bus factor of 1 leave me reluctant to investigate this technology.
dsp_person
Curious about this process. Can anyone submit patches to bcachefs and Kent is just the only one doing it? Is there a community with multiple contributors hacking on the features, or just Kent? If not, what could he do to grow this? And how does a single person receiving patreon donations affect the ability of a project like this to get passed bus factor of 1?
koverstreet
I take patches from quite a few people. If the patch looks good, I'll generally apply it.
And I encourage anyone who wants to contribute to join the IRC channel. It's not a one man show, I work with a lot of people there.
null
nolist_policy
Generally you need a maintainer for your subsystem who sends pull requests to Linus.
kzrdude
today Kent posted another rc patch with a new filesystem option. But it was merged..
shmerl
May be bcachefs should have been governed by a group of people, not a single person.
mananaysiempre
Committees are good-to-acceptable for keeping things going, but bad for initial design or anything requiring a coherent vision and taste. There are some examples of groups that straddled the boundary between a committee and a creative collaboration and produced good designs (Algol 60; RnRS for n ≤ 5; IIRC the design of ZFS was produced by a three-person team), but they are more of an exception, and the secret of tying together such groups remotely doesn’t seem to have been cracked. Even in the keeping things going department, a committee’s inbuilt and implicit self-preservation mechanisms can lead it to keep fiddling with things far longer than would be advisable.
koverstreet
Actually, I think remote collaboration can work with the right medium and tools. For bcachefs, that's been IRC; we have an extremely active channel where we do a lot of collaborative debugging, design discussion, helping new users, etc.
I know a lot of people heavily use slack/discord these days, but personally I find the web interfaces way too busy. IRC all the way, for me.
But the problem of communicating effectively enough to produce a coherent design is very real - this goes back to Fred Brooks (Mythical Man Month). I think bcachefs turned out very well with the way the process has gone to date, and now that it's gotten bigger, with more distinct subsystems, I am very eagerly looking forward to the date when I can hand off ownership of some of those subsystems. Lately we've had some sharp developers getting involved - for the past several years it's been mainly users testing it (and some of them have gotten very good at debugging at this point).
So it's happening.
shmerl
In this case it's more about keeping things in check and not letting one person with an attitude to ignore kernel development rules derail the whole project.
I'm not saying those concerns are wrong, but when it's causing a fallout like being kicked out from the kernel, the downsides clearly are more severe than any potential benefits.
guerrilla
The drama with Linux filesystems is just nuts... It never ends.
msgodel
It's crazy people spend so much time paying attention to Hollywood celebrity drama.
Opens LKML archive hoping for another Linus rant.
rendaw
I'm sure there's just as much political allstar programmer fighting at google/apple/microsoft/whatever too, just this is done in public.
quotemstr
At least Kent hasn't murdered his wife
null
mschuster91
The stakes are the highest across the entire kernel. Data that's corrupt cannot (easily) be uncorrupted.
tpolzer
Bad drivers could brick (parts of) your hardware permanently.
While you should have a backup of your data anyway.
devwastaken
Good. There is no place for unstable developers in a stable kernel.
charcircuit
If Linux would add a stable kernel module API this wouldn't be a huge a problem and it would be easy for bcachefs to ship as a kernel module with his own independent release schedule.
heavyset_go
The unstable interface is Linux's moat, and IMO, is the reason we're able to enjoy such a large ecosystem of hardware via open source operating systems.
homebrewer
It would also have a lot less FOSS drivers, neither we nor FreeBSD (which is often invoked in these complaints) would have amdgpu for example.
charcircuit
I would actually posture that making it easier to make drivers would actually have the opposite effect and result in more FOSS drivers.
>FreeBSD (which is often invoked in these complaints) would have amdgpu for example.
In such a hypothetical FreeBSD could reimplement the stable API of Linux.
smcameron
No, every gpu vendor out there would prefer proprietary drivers and with a stable ABI, they could do it, and would do, there is no question about it.
I worked for HP on storage drivers for a decade or so, and had their been a stable ABI, HP would have shipped proprietary storage drivers for everything. Even without a stable ABI, they shipped proprietary drivers at considerable effort, compiling for myriad different distro kernels. It was a nightmare, and good thing too, or there wouldn't be any open source drivers.
throw0101d
> In such a hypothetical FreeBSD could reimplement the stable API of Linux.
Like it does with the userland API of Linux, which is stable:
msgodel
It's plenty easy to make drivers now, it's just hard to distribute them without sharing the source.
There is absolutely no good reason not to share driver source though so that's a terrible use case to optimize for.
josephcsible
The slight benefit for out-of-tree module authors wouldn't be worth the negative effects on the rest of the kernel to everyone else.
charcircuit
"slight benefit"? Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes. Especially for something critical like a filesystem it should never break.
>negative effects on the rest of the kernel
Needing to design and support an API is not purely negative for kernel developers. It also gives a change to have a proper interface for drivers to use and follow. Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does.
josephcsible
> Having a working system after upgrading your kernel is not just a slight benefit. It's table stakes.
We already have that, with the "don't break userspace" policy combined with all of the modules being in-tree.
> Needing to design and support an API is not purely negative for kernel developers.
Sure, it's not purely negative, but it's overall a big net negative.
> Take a look at the Rust for Linux which keeps running into undocumented APIs that make little sense and are just whatever <insert most popular driver> does.
That's an argument against a stable module API! Those things are getting fixed as they get found, but if we had a stable module API, we'd be stuck with them forever.
I recommend reading https://docs.kernel.org/process/stable-api-nonsense.html
msgodel
Does your system have some critical out of tree driver? That should have been recompiled with the new kernel, that sounds like a failure of whoever maintains the driver/kernel/distro (which may be you if you're building it yourself.)
I've been following this for a while now.
Kent is in the wrong. Having a lead position in development I would kick Kent of the team.
One thing is to challenge things. What Kent is doing is something completely different. It is obvious he introduced a feature, not only a Bugfix.
If the rules are set in a way that rc1+ gets only Bugfixes, then this is absolutely clear what happens with the feature. Tolerating this once or twice is ok, but Kent is doing this all the time, testing Linus.
Linus is absolutely in the right to kick this out and it's Kent's fault if he does so.