The next instalment of Linus vs. Kent – and Linus seems to be on the edge:
"[…] I'm contemplating just removing #bcachefs entirely from the [#Linux #kernel] mainline tree. Because you show again and again that you have no interest in trying to make mainline work. […]"
For the full discussion, start here: https://lore.kernel.org/all/cphtxla2se4gavql3re5xju7mqxld4rp6q4wbqephb6by5ibfa@5myddcaxerpb/t/#m631c24cd07f5820a4cbff8f25dff1d1a0c3cf2e7 (the quote is from one of the later mails from Linus). #LinuxKernel
@kernellogger that’s sad, I use bcache (not fs) on my desktop and like it.
[deleted a earlier toot here (see hisotry for the record), as I had read bcachefs when bcache was meant; sorry!]
@kernellogger I really hope that Linus drops bcachefs. The FS and its concept are interesting but not worth dealing with the negativity of Kent.
When rightfully criticizing his behaviour, the first thing he does is shitting on btrfs (and its devs), even if the discussion is not technical.
yup; most people can live with a sneaky remark now and then, but it's way more then that what others have to ensure from Kent…
mistakes happen, are pointed out, and then people should learn from it; if it turns out that's not the case, something has to be and hopefully will be done, but that take a day or two.
I think we already are in the "takes a day or two" stage here (I'm ignoring here that this was someone likely to happen given the history, as that is a different story…).
ohh, btw, if you haven't seen it yet:
@kernellogger why does it have to be this way god damn it!
I just want a good, stable, reliable next gen fs built into the kernel, so i can just use that instead of having to fiddle with openZFS and so on. Why can't the dev trying to create that just be a champ, and not try to stomp as many toes as possible in the process?!
Just my egoistic ¢2
Dealing with Kent afaics for a long time already was, ehh, was not easy for many people -- and the reason why some actors were not that much willing to engage constructively.
Which is…
> automatically NAK any suggestion of his without engaging constructively
…why it's so dangerous to take sides in complicated topics/discussions, as you never known if there is a non-obvious backstory that explains some behaviours.
Why? Because we are all humans. And some are great in areas that are really hard for almost all people (like writing a complex file system on your own over the span of years), but at the same time bad in others ares that are not that hard for most people.
@kernellogger yeah yeah, it was rethorical.
I'm not the easiest person to work with myself.
@vbabka @kernellogger @brot ah, I don't do detail these days, so my impressions could very much be wrong. I was almost certainly thinking back well over a year ago anyway - so I likely don't mean any recent proposals.
I dip in and out of lkml periodically but have been doing so for years, and I've been trying to keep tabs on the bcachefs stuff because I have personal reasons for wanting a 'better btrfs' (mainly for container pools etc.)
most of the debate *did* take place on the public mailing lists – but who in these hectic times is willing to wade through earlier discussions from the past 10+ years that lead to stances like "I'm a friendly and helpful person normally, but working with that particular person is really not worth spending my time, so I will keep my interactions and helpfulness from now on to absolut minimum required"
@ljs Having macros with hidden returns, not a good idea. And yeah then he threw a fit. People thinking that the drama aspect is new or unexpected, it's really not.
@kernellogger That nobody in the thread is calling out the trash talking of btrfs is beyond me. It's perfectly reasonable to argue over the process but belittling the work of others seems out of line.
2/ Ohh, #Btrfs maintainer Josef Bacik replied and among others addressed the many rude remarks from Kent: https://lore.kernel.org/all/20241007145847.GA1898642@perftesting/
Josef among others praises the #XFS and #Ext4 developers and criticises dragging other people and their projects down – and calls the latter a sort of behaviour that he thinks should have no place in this community.
Go and read it in full, quoting from it would not do this great post justice.
Many thx for it, @josefbacik! 👏
@kernellogger @josefbacik thanks for the link. I think you missed a "not" in there:
[...] is "NOT the sort of behavior that I think should have a place in this community".
thx, yeah, had noticed and fixed that two seconds before your reply arrived here. Sorry!
Just read Kent's response to this reasonable email and my God I don't want to get anywhere near this person.
@karl @kernellogger Ugh. The reply wasn't there yet when I posted the link.
@kdave @kernellogger I don't know. I was reading on and hoping someone would say something along the lines of "Kent, the opinions you have on competing filesystems are yours to have, but the way you are formulating them does a disservice to bcachefs' reputation, and yours. Be the better man and stop belittling your peers to make yourself seem taller."
@kernellogger @josefbacik cannot repeat that enough. Thank you for all the work done on btrfs 🙏
While I haven't used it at home (starting tomorrow pinky promise 😅) I may or may not have worked on commercial product, shipping XXXs of end-user devices with it.
Not to mention that btrfs has been part of #archlinux infra since 2016 (at least) and btrfs exclusive for over 2 years...
So next time you spot "I use Arch btw", you know that's another, blissfully unaware, btrfs user 👋
3/ Kent replied to Josef's mail in what I'd call a not really helpful way while missing the point Josef made: https://lore.kernel.org/all/u266iwml67vr2zrkhebfr3zwak5k7mebk4grhavnujf2wodwkz@eyksfejhgve2/ 😟
But FWIW, quick reminder, while at it:
Once a file system becomes widely used, it will be blamed for all sorts of issues that in fact are caused by other code. Here is a recent example of what currently looks like a amd_sfh issue that leads to disk corruption with btrfs: https://lore.kernel.org/all/90f6ee64-df5e-43b2-ad04-fa3a35efc1d5@leemhuis.info/ and https://bugzilla.kernel.org/show_bug.cgi?id=219331
See also: https://social.kernel.org/objects/83fd9af9-4f54-4fcd-bb72-9b27ef4a9549
A filesystem advertising itself as "the filesystem that won't eat your data" reminds me a bit of an unspoken consensus in the airline industry to never compete on safety when marketing to customers…
@karl @kdave @kernellogger It was pretty disappointing for me as someone involved at some level in both projects. I was genuinely surprised that @torvalds didn't call him out on it.
@kernellogger I have a feeling that soon we will see a patch removing whole bcachefs from kernel.
With kind of "learn to cooperate" message attached.
@kernellogger I just wanted to say this live-tooting of LKML drama is the kind of quality content I enjoy on fedi. thanks! 🙂
Yeah, that feeling is growing in me, too; not sure, maybe I'd even be willing to bet that this will happen. 😄
Maybe a "learn to cooperate" message, maybe a short "due to complications" msg with no further details.
@kernellogger I'm no filesystem developer but people complaining about unreliability of btrfs always give the impression not having used btrfs for a decade. And people in the trade of filesystem development should know about these folks. So, anecdotal evidence isn't worth the pixels on the screen.
I've been using raid5 btrfs with only one issue for 8 years. And I'm happy with it. I don't do databases on my btrfs, at least no db that requires obscene amounts of disk I/O. But Kent will never know about people being happy or content with the choice of their filesystem. On the other hand, there are people reproducing very old tales of issues with btrfs without any first-hand experience.
He should tone it down a little bit.
I was with you up until the last sentence, but sorry, its way more than a "little bit" that is needed here.
@kernellogger @josefbacik To me it seems like Kent really views himself as the savior of the Linux filesystems, "Bcachefs is so much better than everything else, so why can't I keep breaking the rules, it's only natural that I should have that right".
@kernellogger Yeah, old habit of understating things. Sorry. He needs to tone it down massively.
Yup. And the funny thing is: when it comes to kernel, most of its development rules are not strict or not even defined at all -- so you can easily get away by not following quite a lot of "rules". But some are pretty strict and he not even followed those, which is like shooting yourself in the foot.
tell me about it, I'm often like that myself, so no worries 😄
@hrw @kernellogger my guess: linus will avoid drama and will just stop pulling from this person
if anyone actually seriously cares about this filesystem, perhaps someone else would step up to maintain it.
given this project couldn't even get along with distros attempting to ship their userspace tools, this is unlikely to happen and the filesystem will stay a couple of releases on life support, eventually get deprecated and dropped
Yeah, that could happen as well; and if bcachefs would be more established already I guess that would happen. But given it's current state I currently expect it to be more like "remove it, and if anyone wants to bring it back, show that you can follow the rules and we'll merge it again".
@kdave @kernellogger @karl I can add to that: I'm a longtime user of btrfs on my NAS/homeserver: multiple disks of different sizes, a recent btrfs replace, dozens of Incus (previously LXD) containers, each with ~5-20 rotating snapshots, regular send/receive, a number of NFS exports, cp --reflink, etc.
apt is a bit slow on it due to its fsyncs. But that's about it.
It's now my default filesystem on all my systems. There's no going back: snapshots are a must have...
Thank you!
@srslypascal @kernellogger "Kills 23% fewer passengers than the leading brand" just never sounds that great, no matter how good the probabilities actually are.
In practice, that consensus goes *much* further than one might initially think:
https://www.youtube.com/watch?v=sXzO__R3eBM&t=531s
@BrodieOnLinux @kernellogger @josefbacik the thing that makes it all the more traffic is that bcachefs sounds sexy as hell. Have you looked at the Rolling for seeing it up? With encryption, caching, etc? Give me that in a stable manner and with the send/receive functionality of btrfs and I'm happy.
But it does not take more than an abusive maintainer to ruin that beautiful dream.
The saddest part is, that he is crapping all over his own efforts of these last years. He just can't see it
@rasmus91 @BrodieOnLinux @josefbacik
It might sound sexy, but what a lot of people afaics forget when it comes to #bcachefs (partly due to Kent's advertisement):
Even without the current drama it would have taken many years to stabilize the fs; sure, it already works well for a lot of users, but getting it rock stable in all those corner cases and performant at the same time takes years. Btrfs and others before it have shown that.
@kernellogger @BrodieOnLinux @josefbacik oh yes. But even as thats the case being some of the way there is better than being none of the way, and not even moving in that direction.
Chiming in to say that #btrfs has been my daily driver on several machines for 5 years without any issues, but with all the cool features like snapshots just working.
@axboe @krzk @kernellogger @vmiheer @kdave @ljs @vbabka I was just pointed to: https://lore.kernel.org/lkml/20241009055217.778948-1-daniel@gluo.nz which is quite the read...