It's Looking Like Bcachefs Won't Be Merged For Linux 6.5

[kreijack]

I would like to see a summary. Reading LKML is difficult if you aren't used to it!

Can anyone summarize the discussion? It seems Kent had some differences with a few developers.

There's some people complaining sbout the non-bcachefs changes, as usual.

I would like Bcachefs getting mainlined and more talented developers get involved into this interesting filesystem.

My understanding is that there are several issues:
1) for merging, there is a consensus about separating the "non specific bcachefs" changes, that may impact other kernel subsystem, and the bcachefs specific code.
2) nobody can enter in the details of the specific code of bcachefs; but this is not a big deal
3) someone describes Kent as be "too combative" on the bcachefs dependencies [1]; this is source of friction with other developers [4]
4) more important, there is not enough interest to pay developers for working on bcachefs [2]; this point is better explained by the "Theodore Ts'o" post [3];

Prerequisite for merging bcachefs is that the "non specific bcachefs" changes where reviewed and accepted; this is the bottleneck considering 3) also.
Then it can be considered the inclusion of bcachefs.

[1] https://lore.kernel.org/lkml/2023070...9@perftesting/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://lore.kernel.org/lkml/[email protected]/
[4] https://lore.kernel.org/lkml/[email protected]/

[cynic]

"The COW filesystem for Linux that won't eat your data".

well, this is definitely not a friendly way to begin with

I know little about bcachefs, but the most things I've read about bcache were attack against btrfs (like the title).

I don't like who spit on competitors to shine.

[F.Ultra]

So get him to take out an insurance policy and get a restraining order filed prohibiting him from being with 500m of a bus. Problem solved!

The bus "death" arguments are always a logical fallacy. Take mitigating steps, but if any of the core btrfs devs were hit by a bus there would be major hiccups. These projects are all major code bases, even with multiple maintainers I can safely say that any one of them being removed would cause issues as the other would not be intimately familiar with that persons code.

If it does get mainlined and Kent expires in the great garbage collector of life, things will carry on. If the file system gains traction then someone will step up to maintain it. If it does not then it will be removed (probably reasonably quickly).

I mean heck ReiserFS is still in tree (though scheduled for removal in 2025) and its key founder has been in jail for how long now?

This smells more of children in the sandbox arguing over buckets to build the biggest castle. Its more personal than technical.

it is not a logical fallacy, the use of projects that have several times the number of developers and maintainers as contra-examples is though. If it goes into the Kernel it is not as easy to remove it as you seem to think, once added it becomes a responsibility of the Kernel team to keep it alive and working. Just look at how many years it have taken to plan the obsolescence of other parts that they desperately want to get rid of.

It gaining traction can still mean zero new devs, the vast majority of users are not devs nor do they pay for devs. And it gaining traction without new devs/maintainers is the nightmare edition since that makes it even harder to remove later.

Worse yet is that it also requires patches all over the place, those patches also have to be maintained and can and will have impact on other systems.

ReiserFS is a bad example because even with Hans in jail his entire company (he employed lots of devs) continued to work on it for years. It sounds more like you haven't really grasped what it means and what it takes to maintain a huge project like the Linux kernel.

[timofonic]

My understanding is that there are several issues:
1) for merging, there is a consensus about separating the "non specific bcachefs" changes, that may impact other kernel subsystem, and the bcachefs specific code.
2) nobody can enter in the details of the specific code of bcachefs; but this is not a big deal

I see there's need of more developers in the Linux filesystem part, I think so.

Are those changes justified? Can they be beneficial to the Linux fs/vfs subsystem?

3) someone describes Kent as be "too combative" on the bcachefs dependencies [1]; this is source of friction with other developers [4]

The same happened to Wireguard in certain way. Am I right?

I see there's kind of ego wars there too, nothing unusual on extremely big projects like this.

Nobody's perfect. Hens Reiser was an asshole before killing his wife and he was able to get merged his filesystem. Kent is doing *A LOT* of work and maybe sees too much conservative resistance in Linux kernel development?

4) more important, there is not enough interest to pay developers for working on bcachefs [2]; this point is better explained by the "Theodore Ts'o" post [3];

That's very usual! There's never enough interest unless there is something interests the big corpos.

Prerequisite for merging bcachefs is that the "non specific bcachefs" changes where reviewed and accepted; this is the bottleneck considering 3) also.
Then it can be considered the inclusion of bcachefs.

[1] https://lore.kernel.org/lkml/2023070...9@perftesting/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://lore.kernel.org/lkml/[email protected]/
[4] https://lore.kernel.org/lkml/[email protected]/

What so evil about that non-bcachefs stuff? Are they abusing some developer while doing it? Are they afraid of change? Does it improve these parts or not?

Am I too stupid to understand Bcachefs is vaporware and not so good compared to other filesystems such as Btrfs and ZFS or what?

[Quackdoc]

Id like to see someone commit to investing in bcachefs as a co-maintainer, even if it's only conditional, hanging on the fact that it will only happen if bcachefs gets merged.

kent has always been somewhat controversial on LKML. after reading the past few mails though, IMO it's hard to not side with kent the first thing Hellwig did was accuse kent of starting a fight? what? he gets accused of waving a big red flag when he makes rebuttals, he's still treated as the bad guy saying he devoles into "ad hominem attacks" and "raising an army of little kents". and then james says "I never said or implied "bad person". which is explicitly what he did.

ofc kent is not without blame saying things like this is IMO out of line too even if he may be right,

Look, the main thing I want to say is - I'm not at all impressed by this
continual evasiveness from you and Jens. It's a bug, it needs to be
fixed.

We are engineers. It is our literal job to do the hard work and solve
the hard problems, and leave behind a system more robust and more
reliable for the people who come after us to use.

but it's absurd that it seems like 1/4th of the people on this email refuse to even try to treat kent with a shred of respect despite his trying to keep it on topic, I'd be pretty hostile too if I'd kept getting attacked out of left field. Kent isn't innocent here, but he is far from the only aggressor. this is a dance by both sides

[fitzie]

This is so ridiculous, given that any point release can cause all kind of nightmares with any kernel function or hardware (and sometimes does) due to everything being utterly untested and potentially rolled out immature. If this isn't a red flag that this development model with one main branch and only ~six weeks of "rcs" before declaring something "stable" (lol) isn't just totally stupid by design...

linux is a product of commercial interests that are happy to fund their features and performance goals, but not willing to fund the deep set of developers needed to make it a robust kernel. this is exactly why "critical" deployments, like aws, facebook, google, android, yacto, rhel, have such a long stabilization period. when the upstream kernel development tried to do this, it just didn't work at all, we had 2.4 out there with insane amounts of backports, much of it iffy, and a release cycle from h*ll. we're much better now, but it really is crazy to use "stable kernels" without letting things shake out. I will usually wait until x.y.5 before I touch it, and quickly go to x.y.12 and then just hold there unless there's a specific issue I need addressed. the stable tree is a sausage factory most people (even kernel developers) don't go near.

[vladpetric]

Just another year of ZFS for me at least ...

[timofonic]

Id like to see someone commit to investing in bcachefs as a co-maintainer, even if it's only conditional, hanging on the fact that it will only happen if bcachefs gets merged.

kent has always been somewhat controversial on LKML. after reading the past few mails though, IMO it's hard to not side with kent the first thing Hellwig did was accuse kent of starting a fight? what? he gets accused of waving a big red flag when he makes rebuttals, he's still treated as the bad guy saying he devoles into "ad hominem attacks" and "raising an army of little kents". and then james says "I never said or implied "bad person". which is explicitly what he did.

ofc kent is not without blame saying things like this is IMO out of line too even if he may be right,



but it's absurd that it seems like 1/4th of the people on this email refuse to even try to treat kent with a shred of respect despite his trying to keep it on topic, I'd be pretty hostile too if I'd kept getting attacked out of left field. Kent isn't innocent here, but he is far from the only aggressor. this is a dance by both sides

It seems Linux kernel development is too corporativized, to say it lightly...

[Quackdoc]

It seems Linux kernel development is too corporativized, to say it lightly...

rather then that, it's just typical devs doing typical things

[timofonic]

rather then that, it's just typical devs doing typical things

Would you like to explain? I'm interested in that no code part of software development...