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

[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]

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.

[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.

[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.

[Deathcrow]

What I have said, and I repeat again:
perhaps they are not addressing issues because those issues are too hard to address, due to early design flaws, and not due to developers not wanting to.

I have never heard someone make a complaint about "$issues not being addressed" if the $issues are inherently un-addressable because of a design flaw. You'd never say it this way.

You're either gaslighting or intentionally obtuse to stan for Kent.

[Mathias]

Holy shit

> I'm more than happy to work with people, but that's got to be a conversation, and one based on mutual respect.

As someone who spent a year and a half working directly with you,
You're full of shit
[...]
You keep hating on btrfs like an insecure child.
You never afforded any respect to your users, like saying sorry for your constant temper tantrums on IRC at noobs asking simple questions.
You put your ego before stability,
[...]
You've been a solo dev for over 10 years, and you'll stay a solo dev for another 10 if you don't harden up, put your big boy pants on, lay off the weed, and get a therapist.

Also: Ted Ts'o lectured him that his test infrastructure is easy to spin up and use...

[mdedetrich]

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.

They have addressed the issue but you have to create an entirely new btrfs partition, its impossible to fix a currently existing partition as the fix requrires a breaking change to the on disk format.

At this point, you may as well choose a better filesystem which has a known history of not having these issues, i.e. openzfs

[jacob]

As someone that was around at the time and knows how FAT* works, it wasn't clever even in the day. The most I'll give it is: "it worked... most of the time". Most people that could program computers in that era could do the same thing and often did, often arguably better. We had to in order to get the most out of the limited available resources and mechanical timings. In fact, there were plenty of other software that created custom physical and logical disk layouts to minimize lengthy access times for mechanical storage that catered to the quirks of the hardware.

(*) FAT12, 16, 32 & vFAT, exFAT are all basically just extensions of the version that came before

Yes it was common to have custom disk layouts, I've been there, done that The point is, those custom layouts were optimised for particular workloads and data types. But as a general purpose filesystem meant to handle more or less anything without any assumptions, FAT was not nearly bad, especially compared to the competition (we are talking personal computers and floppies, mid-80s):

• CP/M had a far more primitive storage system
• The various "Disk Operating Systems" used respectively by the C64, Apple II and other 8-bit computers usually didn't even support hierarchical folders and were much more limited
• The original MacOS filesystem was a hack, more akin to those custom disk layouts than to a bona fide, general purpose filesystem. It also did not support hierarchical directories (the "Finder" file manager did, but it was only handled at the GUI-level, the OS itself knew nothing about it).
• The Atari ST's TOS used basically FAT. There were minor differences but for all intents and purposes it was a FAT.
• The original Amiga filesystem was simply terrible, it didn't have any block index or actual directory. That made it incredibly slow and error prone. Later, Amiga FFS was arguably much better, but IIRC that didn't come until 1990 or so.

[PuckPoltergeist]

They have addressed the issue but you have to create an entirely new btrfs partition, its impossible to fix a currently existing partition as the fix requrires a breaking change to the on disk format.

At this point, you may as well choose a better filesystem which has a known history of not having these issues, i.e. openzfs

Nice whataboutism, switching from social problems of offending and accusing to technical discussion

[PuckPoltergeist]

And those "social problems" are the best ones, especially when an elephant is made out of an ant, supported by lies, misrepresentations and fact-twisting.

Lemmy quote:

Pls remove the tin foil hat