Linus Torvalds is fed up with bcachefs | Hacker News Reader

Linus Torvalds is fed up with bcachefs

lore.kernel.org

37 pointsramon15610 comments

I agree with Josef Bacik, the constant trashing of btrfs is getting really annoying and disrespectful to the filesystem developers, and it's sad to see how another filesystem developer refers to btrfs.

The write-hole issue did take a long time to fix, and yes it's annoying that the fix requires full RMW cycles, and yes it's frustrating to know that the design of btrfs means that there probably won't be a better solution, but it doesn't mean that "people cannot rely on it after 10 years". Some people do rely on it, it serves them well, if it was that unreliable it wouldn't be the default filesystem choice on a major distribution.

I really don't know with which side(s) the faults lie, but as someone who thinks bcachefs is a promising FS (and supporting koverstreet a little on patreon), I sure hope they can get something settled.

This is why complaints about Linus are very wrong.

It is Kent that is in the wrong here.

If Linus was even half of the bad guy that people whine about, bcachefs would already be out of the mainline.

It is coming because Kent seems incapable of learning how to work inside an organization.

Imagine Kent's attitude on a corporate dev team. He wouldn't last a month.

Is it just me, or has Linus lost the plot here? He says that Kent isn't interested in improving his process and "playing with others," and completely ignores that Kent is getting funding and appears to be building a team of maintainers and testers. He responds

> You can do it out of mainline. You did it for a decade, and that didn't cause problems. I thought it would be better if it finally got mainlined, but by all your actions you seem to really want to just play in your own sandbox and not involve anybody else.

How is Kent not involving anybody else? It sounds to me like Linus is fed up with Kent, not Kent's software, and is ignoring evidence in favor of bcachefs.

Did we read the same thread?

Kent sends commits last minute and his response is “they sat in my tree the last 2 weeks; nbd!”

Complains he has no idea what Linus is asking for…

He seems so overwhelmed a simple ask like “don’t let patches sit two weeks so you can personally noodle to your hearts content the git log” are missed.

Have seen similar from Kent on various kernel mailing threads I watch. Lots of deflection of his obligation to test more broadly, push sooner as he appeals to some big picture only he understands like he did here invoking acts over 20 years ago.

So what he’s working hard in his little btrfs bubble; what’s trickled down hill on others smells of bio waste

We read the same thread. I haven't read all the context. Thanks for that.

But I disagree that he's deflecting his obligation to test more broadly -- it does sound like he's trying to get people together to do exactly that. It's easy to see this situation in black and white, and Linus's approach to the conversation is rather polarizing in that regard.

He is deflecting the obligations that having a project in the kernel mainline puts on him.

Linus' reaction is very appropriate because Kent is breaking the mainline and wrecking the kernel development cycle. It is more than appropriate to pull bcachefs out of the mainline.

I partly posted this to see if anyone had more context or experience with Kent. Thanks for the extra bit of information.

I can agree with both, but in the end it's Linus' decision.

He says they have a process and Kent isn’t respecting it, it is very frustrating for him understandably because he has to deal with a lot of people like Kent and doesn’t want to compromise his process, he expects Kent to be humble and respect the process. And he says if Kent doesn’t want to respect it then this whole thing can be developed outside of his project, all of this seems pretty understandable.

everyone dumps on Linus but no one is willing to take his job

wait, what's that? how can any old Internet Commenter just decide to replace Linus?!?

fork the kernel, call it something else...now you have your own kernel and you can be the BDFL and do all the YOLO merges you want

as it stands I agree with him completely in these threads so you are more than welcome to build your own fork, I will stick with Linux

Reply on news.ycombinator.com