Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

[Deathcrow]

Nope, it doesn't say that at all.
For example, btrfs has a raid 5/6 write hole. The hole is there due to an error in early design, and now it is very hard to fix it. It has nothing to do with whether developers "care about user data", or not.

I really don't understand how you can read this any differently. Kent literally said they are not addressing issues. It's incredibly rude, especially since there have been so may raid56 patches, and there's still work being done for the raid stripe tree feature.

Yes, there's also design flaws, which Josef acknowledge, but it sounds like the only acceptable approach for Kent would be to throw the entire fs into the trash and help him develop bcachefs instead.

Honestly, his entire response to Josef sounds like a slap to the face and I'm not surprised that no-one wants to work with this guy.

[PuckPoltergeist]

I just read Kent's reply to Josef, and I can't find it. Can you please provide a quote?

Here is the Kent's reply, and I don't see "devs don't care" in it:
- https://lore.kernel.org/lkml/1728167...622f7e4a46f4be

The very first paragraph:

Josef, I've got to be honest with you, if 10 years in one filesystem still has a lot of user reports that clearly aren't being addressed where the filesystem is wedging itself,

This sentence says clearly to me, btrfs developers, especially this one, don't care about user data. This sentence says, there are errors, that are reported and devs don't care about.

and that really is the main reason why I'm here.

Kent must rescue the world.

I don't think there's any reason a modern COW filesystem has to be crappier in _any_ respect than ext4/xfs.

Kent can do better than all the other. Please consider that Josef was speaking about xfs/ext4 are better in some areas than btrfs and he can admit this. That's the context where Kent made crappier out of.

[PuckPoltergeist]

Kent is a single developer. He can't count on support from some teammates financed by the same company.
As such, Kent's job is harder than the job of other kernel developers.

I think it would be a bad idea if we let Linux kernel be dominated by big companies, which can finance teams of well-coordinated developers.

Kent is a rare examples of a single developer working on a big and very important project. I think that it should be expected that he will make some mistakes, even behavioral mistakes (and, in my eyes, those are most unimportant ones).
I think that it is important to give more support to such single developers, even more so when they commit to working on such an important project like BcacheFS.

Okay, and that's absolutely bullshit. Yes, Kent is a single developer in his area (bcachefs). But,

a) This is his choice. It's because of his behavior, that nobody wants to support him. As long as he offends every other developer, it's pretty understandable to me, nobody want's to spend time with this. Brian Foster has quit as reviewer after a very short time, for example.

b) Even developers from different areas can work together. That's pretty normal for linux development. Josef stated two examples explicitly in his mail. And you can read this all over the mailinglists. But again, if someone starts fights over and over again, it's clear that other devs don't want to work him. If I'm piss of other devs all the time, I can't expect help from them.

[User29]

BTW, I don't run BcacheFS on any of my machines. Which is not surprising, since I need extremely high data integrity and reliability. As Kent has said, his BcacheFS is not quite there yet, but I have high hopes for it in the future.

Everyone had high hopes, that's why the interest, the 200+ comments and the drama.

[PuckPoltergeist]

Neither Kent nor I implied that that other devs don't care.

Just read his reply to Josef, where he says this directly.

I have said: they didn't sufficiently commit to robustness and data integrity. Commitment is when you say: "This filesystem has a design goal of paramount data integrity".

Other filesystems simply do not claim that they are designed with such properties, mostly because such high standards were not part of the original design.

I'm sure you know that's not true. Btrfs was designed with data integrity in mind. That's why csums and redundancy was considered from the beginning. XFS is adding those features because of this. The difference is, these developers aren't that loud as Kent.

Everyone has a right to state their opinion, and to point out possible design defects in other projects.
That includes Kent.
Requiring or expecting just flattery is dangerous. Criticism should be appreciated, critics should not be kicked out. Criticisms should be seriously considered, not brushed aside.
Of course, many times critics are in the wrong, but that is also OK. You can't expect every criticism to always be true.
When criticism is suppressed (whether intentionally or not), then you get into big trouble.

Another problem is that many people react negatively to criticism. I think those people should learn to be more tolerant of critics.

Why wouldn't Kent be allowed to say "I think that I designed this better than this other thing is designed, and that was my goal". He has all the right to hold such opinions (otherwise he would have no reason to ever start working on BcacheFS).

It's not about criticism, it's about accusing and offending. Kent is not saying "I think that I designed this better than this other thing is designed, and that was my goal", he is saying "You don't have done it right" and "It's your fault, that I can't write better code".

https://lore.kernel.org/linux-fsdevel/ivjo62ghagmcoacjdtoute7mzwkcj3gu6hgdygjry5x7uiqgid@6axrxbn5auvy/

https://lore.kernel.org/linux-fsdevel/nlwn4yodlo54hdbyil3kyxhaqgg5dmmdfvizsyj77oczgzezt2@m3qbtep3fhln/

https://lore.kernel.org/all/[email protected]/T/#m031d906c66099ba8f341e7622a282c7c3302e4ff

[lumks]

Boy oh boy. Is it just me or does Kent sound like an LLM/"AI"? Overexplaining things with nonsense examples, hallucinating the importance of his project and his testing ground, playing down other projects.

Kick this crap out of the tree, Linus.

[Mathias]

So you're saying he pushed code that wasn't tested on main to main. Glad we agree. You're probably as infantile as Kent.

Let's look up your original comment:

If he keeps pushing patches with zero testing it's almost certainly going to eat your data.

I have no direct affiliation with Kent or other Linux devs. But from what I read, Kent does extensive testing on every commit he pushes that actually test the FS in ways meant to break the FS to show that it doesn't break. AFAIK he does extensive testing that Bcacefs doesn't eat your data.

What he didn't do send the patches to others to test them. That's what Linus complained about, and for good reason. What he didn't test is BE systems, because they are hard to come by. BE didn't compile and that is what Linus is mostly concerned about. Sure it's Kents fault for not sending the patches earlier and I don't defend him for his behaviour. Sure if you're on BE, Bcachefs is pretty much untested and it might eat your data and kill a kitten in the process. I don't defend Kent for his behaviour towards the LKML.

But saying "patches with zero testing" is something even Linus didn't say. And when you were called out for it, you posted quotes that didn't support your claim.

[PuckPoltergeist]

Most of Kent's contributions pre-bcachefs were individual patches on existing subsystems, that went through others before they hit Linus.

He developed and is maintainer of bcache (included in linux since 2013!)

[Daktyl198]

well kent participated in linux for decades and only recently there seems to be that much drama. so something did change.

Most of Kent's contributions pre-bcachefs were individual patches on existing subsystems, that went through others before they hit Linus. Bcachefs was developed out of tree for years and really struggled to even get merged into the mainline kernel because of Kent's development issues and failure to listen to what he was told. He basically got it in on his very last chance because he'd already submitted it like 4 times and all 4 times he had to be told the same shit about how to modify it to be mainlined.

Hence Linus's "I hoped that by bringing you into the kernel things would change". But they haven't, Kent develops in his own way. I don't begrudge him, his filesystem, or his way of development... but if he doesn't play by kernel rules, his software should be developed entirely out-of-tree and brought in by interested distros.

(I'd really rather just the kernel development system be entirely reworked and brought up to modern standsards, but alas. That's not gonna happen).

[LockedPotato]

Literally read the article. Even Linus knows it had testing, just not outside his tree.

So you're saying he pushed code that wasn't tested on main to main. Glad we agree. You're probably as infantile as Kent.