It’s been a tense few months for users of the BCacheFS filesystem, as amidst the occasional terse arguments and flowery self-praise on the Linux Kernel mailing list the future of this filesystem within the Linux kernel hung very much in the balance. After some initial confusion about what ‘externally maintained’ means in Linux parlance, it’s now clear that this means that BCacheFS has effectively been kicked out of the kernel as [Linus] promised and will ship as a DKMS module instead. The gory details of this change are discussed in a recent video by [Brodie Robertson].
We covered the BCacheFS controversy in the Linux world a few months ago, amidst reports of data loss and filesystem corruption among its users. Its lead developer, [Kent Overstreet], came to blows with [Linus Torvalds] on the LKML after [Kent] insisted on repeatedly pushing new features into kernel release candidate branches along with rather haughty statements on why he should be able to do this.
To make a long story short, [Linus] didn’t like this and froze BCacheFS support in the current kernel release with all future in-kernel development ceased. Distributions like SuSE have initially said that will disable BCacheFS starting in kernel version 6.17, meaning that users of BCacheFS may now have to install the DKMS module themselves. Some distributions like Arch are likely to include this DKMS module by default, which is something you want to check if you use this filesystem.
Trying to push out a new feature in an RC is dumb. Once is a mistake but doing this repeatedly is simply a disregarding the rules for contributions which exist to ensure stability. Contributors that are potentially destabilizing the the kernel in RC are not helping Linux.
Hmm. I think this is a lesson for everyone, and I don’t mean to say that this Overstreet guy was wrong.
This tragedy shows us what happens when people’s egos clash, what a power play this Linux is, etc.
The removal of BCacheFS is sad because it’s one of the few promising file systems.
Comparable to ReiserFS (where the removal was admittedly due to valid ethical concerns).
The removal was also a kind of public execution, to set an example.
And the major Linux distributions are acting accordingly, acting submissive to Mr. Torwald’s political message.
Their decisions (or lack thereof) demonstrate a worrying lack of integrity.
They are essentially following a leader without question, and perhaps even trying to please him that way.
Patches. What people seem to forget about kernel patches is that “experimental” support in the kernel
isn’t really experimental in the traditional sense.
A component like BCacheFS isn’t as “experimental” as it seems at first glance.
Rather, such code needs to prove itself over an extended period of time before its experimental status is removed.
That’s why experimental code sometimes retains that status for years.
Sometimes it’s also overlooked that these additional patches had a good reason, as it’s a filesystem,
a critical component of any operating system (nobody likes data loss).
Another story that comes to mind is that of the C++ developer who refused to provide additional Rust support for critical DMA-related code a few months ago.
This developer, too, was “removed,” despite acting reasonably and telling both Mr. Torwalds and the Rust folks that he didn’t have time for Rust.
Direct-Memory-Access (DMA) code is just as delicate as file system code and can’t be rushed.
It is therefore wrong to expect an experienced C++ developer to devote all of its free time to learning Rust programming and quickly become as proficient in it as he is with C++ now.
The right decision would have been to provide him with a helping assistant (person)
or the Rust fans should have provided him with a C++ <> Rust translation wrapper.
Many people seem to forget that developers sacrifice their free time and are not paid for it.
Speaking under correction here, I’m not a Linux fan.
Reiserfs was not removed for any ethical concerns. It was removed due to bitrot from lack of a maintenance, and keeping it working against the ever evolving common kernel APIs was a major pain point for filesystem developers.
“They are essentially following a leader without question, and perhaps even trying to please him that way.”
What reason could distros possibly have for “pleasing” Linus, given he cannot in any way affect their operation?
And you are twisting the Rust driver saga into something it was not. The developer did not want to admit rust code which was maintained by others
Really? My bad. But there’s still the matter about responsibility.
Even if others wrote code, it’s him who must carry the responsibility.
And to do so, he must invest time to become proficient in programming in Rust.
My point was that it’s not as simple as it looks.
“Even if others wrote code, it’s him who must carry the responsibility.”
No, that’s not what was going on at all. He just didn’t want the code in the kernel at all. It wouldn’t have been his responsibility in the slightest. It wasn’t part of his code at all, it just called his code.
That is explicitly NOT how it works.
The deal is, if C programmers want to help out, cool, they’re taking on that responsibility. If they don’t want to help out, cool, it’s not their responsibility at all. They can do whatever they want and not worry about the rust code.
But the thing that Linus made clear was that they can’t have it both ways. They can’t BOTH not have to deal with/touch the rust code, AND dictate what it can do, how it works, and what it can touch. If C programmers in the kernel wash their hands of dealing with rust code (as is their right) then they’re also giving up their say in how it interacts with their code.
@Pat @M By “responsibility” I didn’t mean liability in a legal sense.
It’s about how critical the matter is and whether or not it is compatible with one’s own conscience.
Personally, I couldn’t spontanously come up with much else than DMA if I was trying to find something “dangerous” and crucial as an example.
And I do understand if he is reserved against letting the Rust “kids” play with it through “learning by doing”.
Because I remember for example how tricky it sometimes was to call C code from Pascal and vice versa.
There’s a lot that can go wrong, the different calling conventions etc.
About C++ vs Rust, I think it’s like asking a veteran Fortran programmer to learn Logo and be good at it.
I’d decline, too and try to protect my work, for the well being of everyone. ;)
No, you really don’t understand. He was trying to dictate who could call his functions and that’s totally not OK.
It would be like saying “no, this Nvidia driver is not OK, it calls my function and I don’t like Nvidia.”
It had nothing to do with him whatsoever.
The issue is not that the code was written by others. It is that he would be forced to maintain compatibility with their code. He didn’t want to take on that commitment for a language he doesn’t know.
That was the stated reason. It’s bogus. It has been an explicit part of the deal since the beginning that C devs can do whatever the hell they like and not give a damn about breaking the rust code. The rust devs will just have to adapt.
His real motivation (explicitly admitted to!) was to sabotage rust-linux work by blocking access to the critical DMA API. Linus came down hard on this, ending the discussion by stating that C devs can learn rust and participate, or they can ignore it and get no say how rust code interacts with their stuff. They don’t get to block code they also don’t want to be involved in maintaining.
Hm, I don’t know for sure. Maybe religious ones, among others? Or for PR?
Why did certain users “follow” and worship Mr. Jobs back then?
I’ve stopped trying to understand the Linux community or makers of distros, it’s beyond my abilities I’m afraid.
Like why they constantly change everything each release so that printed books have no chance. Etc pp.
It’s just worrying when distributions simply seemingly follow the decision of a celebrity, and silently, without giving good reason why they do so.
In an extra ordinary situation like this, they should at least communicate why they keep or remove something.
Or them trying to find or discuss a compromise,
also to support users who already rely on something like BCacheFS.
Instead of just cutting off life-support prematurely, basically. IMHO.
An external kernel module would be such an interim solution, maybe.
The drop for RaiserFS a long time ago was at least understandable because of all the circumstances of its creator.
“This tragedy shows us what happens when people’s egos clash, what a power play this Linux is, etc.
The removal of BCacheFS is sad because it’s one of the few promising file systems.”
This wasn’t a power play.
Linus is the kernel’s supervisor. He’s one person. Obviously you have to match his workflow to yours, because everyone else is too.
This is like some guy overseeing a minor part of a huge factory bothering the supervisor constantly over every thing he finds. And then when the supervisor says “not now, bring it up next week at the meeting when I have time” the guy says “but my stuff is awesome and Jim over in Section D sucks!”
He’s painting it as a power play because Linus is saying “dude you have to follow my submission rules, or else I’m just going to stop taking submissions from you.” But that’s not a power play. That’s Linus being self protective. He has to. He’s human, and he doesn’t have infinite time to review stuff.
Those schedules and rules are there for a reason. They have to be. It doesn’t matter that Kent’s stuff was great. If it threatens the whole development process, it doesn’t work. This doesn’t have anything to do with Linus. It’s all Kent.
If you think I’m exaggerating anything here, go read the LKML. It’s all there.
It wasn’t? Hm. To me, the whole message basically was like:
“okay, fine, you get what you want – this time. but in the next release I’ll kill your entire life work. good bye and have a nice day.”
I don’t, I believe you. I’m aware how harsh these mailing lists can turn out.
I didn’t mean to part with any side here.
I just think it’s sad and worrying how things have turned out.
In this day and age, good filesystems matter more than ever.
Everything is digital and masses of data must be stored every time.
“To me, the whole message basically was like:”
The message was “I can’t continue to take these patches because it makes my work harder since I have to work differently just for you, are you going to change?” “No.” “Okay bye.”
You way over simplified. please actually read the discussion before bringing up the hot take you came up with after reading a very short summary.
He was booted by the CoC for being “insulting” while he was also insulted. Only one got hit by the CoC though.
If the patches would have been the reason for his and the codes ouster I wouldn’t care, but the CoC was absolutely weaponized against him.
Meanwhile Linus insults people often.
No, he was booted for ignoring the normal development process, responding to it with behavior outside the code of conduct, and refusing to acknowledge anything. Any time someone tried to explain to him what he was doing, he responded with rants about Btrfs. He just. Kept. Doubling. Down. In fact he kept arguing that the development process for Linux itself was bad. Its like he was trying to demonstrate a law was bad by repeatedly violating it even when everyone else in a community supported it. And then he was surprised he was thrown in jail.
It’s not the violations that were the issue, it’s the fact that he never even acknowledged he was doing anything wrong. Not the same in any way.
Uh no.
Go read what the excuses he gave for his behaviour were, they are all ridiculous. Despite specific warnings that he can’t do the things he is doing his response was always too do it again and blame others first not understanding why he should do whatever he wants.
He never even addressed any of the points people were making, he literally just kept saying how crap Btrfs was and how great his stuff was. It was crazy.
As someone who follows Linux news, Linus has been magnitudes more considerate in his responses than say 10 years ago. He is stern and too the point, still prone to controllee outbursts with potential expletives. It reminds me of my 1st guitar teacher, his teaching style left so much to be desired I quit his tutelage promptly. However, both he and I went on to be talented and well practiced guitarists. Chemistry is everything.
Yes he has been more moderate ever since his “hiatus”, but still regularly violates the CoC. Which I take issue with. Its literally “Rules for thee, but not for me”
They are either rules that apply for everyone or they don’t apply to anyone.
Not at all, do you think calling out someone for doing something wrong repeatedly is against the CoC? It isn’t. Now, trampling over other projects? Breaking things in RC? Those are actual problems.
This has nothing to do with the CoC. A developer unwilling to work under the same rules as others in there project got many warnings and eventually got himself kicked out, that’s all.
I can see both sides, but I acknowledge that the Linux kernel stable branch is not a good place to make frequent changes. In this case the new file system being developed is not ready for deployment by the kernels standards. The move to a dkms module makes perfect sense.
Kent’s development process was rapid fire, which is fine for him. But the rest of the kernel developers don’t want to work that way, and not only did he refuse to follow their process he actively kept attacking it and other people, taking up more of everyone’s time.
As I said above it was really weird. People would point out to him “hey our problem is you keep ignoring our process and responding to it by attacking unrelated things” and he would respond by doing the exact same thing. Again.
Kent should have just accepted the rules for pushing features to the kernel after it was explained to him but he thought he was more important than any of the other thousands of people contributing code to the kernel.
The other main drivers of the kernel agreed with the decision as well. And I think it really was the best decision because I don’t want unstable code in the kernel just because some hot shot think he’s above everyone else. They have set these rules for pushing to the kernel, the RC will only accept bug fixes.
Now he can fix what he need, then he can try and get back into the kernel again.
It’s because he disagreed with the rules and openly stated so. It was like he was trying to pull a power play against all the other developers and tried to justify it by shaming a filesystem. Sooo weird.
Hopefully Kent will cool down, come to his senses, make amends, and not basically kill his own child by being stupid stubborn.
Stating this as something “Linus didn’t like” is underestimating the problem. When a developer who fights with anyone and everyone about what policies they can ignore it is a problem for the entire community. Linus was simply the final word after repeated failures to abide by basic provisions for inclusion.