Linus Torvalds Isn't Happy With Some Of The Bcachefs Code For Linux 6.9

[F.Ultra]

Linus is tough, but that's because he is an amazing dev with a (too much for some) honest way of expressing his thoughts that Linux is what it is today.

If more often, technical leads were honest about code quality, and clean naming convention like Linus is, we would end up with way better quality software overall.

Yeah, too many people don't seem to get that the job of a maintainer like Linus is not to merge code, the real job is to reject bad patches and force the devs to both improve their code and make a great justification for the existence of the code. Once that code hits upstream it will have to be maintained for a long long time.

[dralley]

I would highly reccomend people read the mailing list replies before commenting here. There is no drama, just technical discussion. It's normal for one dev to like something and for another not to... Phoronix readers really need to learn how to not jump to conclusions

Challenge: impossible

[evasb]

Completely normal discussion, with Linus being passionate. No drama at all.

[jeisom]

Wasn't it 6.8 that the bcachefs submission didn't even compile? Did they even test Linus's patch to verify that it didn't cause data corruption. He was mostly interested in getting it to compile. Really not comfortable anything from that touching XFS.

[dralley]

Wasn't it 6.8 that the bcachefs submission didn't even compile? Did they even test Linus's patch to verify that it didn't cause data corruption. He was mostly interested in getting it to compile. Really not comfortable anything from that touching XFS.

I don't understand why some people are so intent on spreading FUD when they themselves cannot even remember what exactly they are talking about, much less the context.

Nothing from bcachefs can "touch" XFS without the XFS developers deciding to use it, which they would do only after reviewing it themselves and deeming it suitable. What's the issue here.

[pkese]

Not again LOL

Can someone explain what the actual hype is for this file system when it’s poorly written, slower than the competition, doesn’t do anything unique, and its maintainer is emotionally unstable? Is it just because it’s not Btrfs?

It actually has some fresh and valuable architectural ideas that go beyond what btrfs is doing.
Basically it similarly has b-tree COW architecture like btrfs, but metadata nodes are much larger (256K or more) and implement an append log inside of them, so an update to a single file is just a small append to the log, rather than rewriting a bunch of metadata tree nodes, which is what btrfs is doing.
Consequently 1) small updates to files will be a lot cheaper and faster than in btrfs. In addition, 2) erasure coding (raid5/6) is going to be much easier to implement in bcachefs than in btrfs and 3) it will be possible to implemented tiered storage, e.g. put frequently accessed data to SSD and infrequent data to HDD all within the same filesystem.

It is currently slow, because it is quite new, so the focus is now on getting it feature complete (and not lose data) rater than maximizing performance. Even btrfs used to be slow as hell at the beginning, but they are improving the performance with each consecutive release.

If things go well, I may look into converting my filesystems to bcachefs in some 5 years from now (I've been running all my gear and servers on btrfs for over 10 years with satisfying results).

[johnandmegh]

Completely normal discussion, with Linus being passionate. No drama at all.

From the two messages quoted here, at least, 3% (12 of 424) of the total words written by Torvalds add no substance to the critique, and serve no purpose other than to add drama to the points he's making, or to belittle someone's work:

"senseless...horrendous...disgusting...disgusting. ..nonsensical...insane...idiotic...garbage...point less...garbage...horrendous...stupid"

If this is "normal", then I cannot help but think that he himself is contributing to the maintainer burnout that he has spoken of - working in an environment where you are constantly subject to the judgment of a man who goes out of his way to be discourteous is quite tiring, in my experience.

[Daktyl198]

This is like the 3rd article in the last month I've seen about Kent having poor interactions with other kernel maintainers/developers due to his weird ways of developing his corner of the kernel. I never even heard of the guy until this, and I've seen nothing positive about any of the work he's done tbh.

[Daktyl198]

From the two messages quoted here, at least, 3% (12 of 424) of the total words written by Torvalds add no substance to the critique, and serve no purpose other than to add drama to the points he's making, or to belittle someone's work:

"senseless...horrendous...disgusting...disgusting. ..nonsensical...insane...idiotic...garbage...point less...garbage...horrendous...stupid"

If this is "normal", then I cannot help but think that he himself is contributing to the maintainer burnout that he has spoken of - working in an environment where you are constantly subject to the judgment of a man who goes out of his way to be discourteous is quite tiring, in my experience.

Maintainer burnout comes from sheer volume of work and stress of making mistakes, not from Linus. Ask literally any maintainer.

Linus used to be worse with his words, but the reality is that he just doesn't soften the blow. If your code is awful to look at, let alone run, he will let you know. It's far better than somebody pussyfooting around and not really telling you what's wrong so you never know what needs fixing. Linus will call the code disgusting, then tell you exactly which part of it is bad and why so that you can fix it.

[dralley]

It is currently slow, because it is quite new, so the focus is now on getting it feature complete (and not lose data) rater than maximizing performance. Even btrfs used to be slow as hell at the beginning, but they are improving the performance with each consecutive release.

And also because for some reason the formatting tool is deciding to use 512 byte blocks by default on some drives where it ought to be using 4096 byte blocks (and where the competition is using 4096 byte blocks). You can actually see that this is the case in Michael's benchmark setup screenshots.