bcachefs
bcachefs
Posted Aug 3, 2025 10:30 UTC (Sun) by jmalcolm (subscriber, #8876)In reply to: bcachefs by koverstreet
Parent article: 6.17 Merge window, part 1
I use multiple distros with bcachefs and not all of them support dkms. One of them uses clang, musl, a custom memory allocator, and several kernel patches. I waited for bcachefs to be in the mainline kernel before I started using it. I did this because I am not going to manage the kernels and tools for multiple distros myself.
For me, the journey will end. Every time I read "support my users" I think to myself, "I guess he does not mean me". I doubt I am the only one.
I really like bcachefs (even though I got hit by the "docker bug"). So thank you to Kent for the filesystem even if I get left behind.
Posted Aug 3, 2025 15:35 UTC (Sun)
by koverstreet (✭ supporter ✭, #4296)
[Link] (4 responses)
Getting bugfixes out and supporting users is what we should all be doing; when we lost sight of that we're not engineering anymore. The whole point of what we do is to ship stuff that works.
But bcachefs is still in tree last I checked.
Posted Aug 4, 2025 22:16 UTC (Mon)
by jmalcolm (subscriber, #8876)
[Link] (3 responses)
Sure. But those fixes cannot be submitted after the merge window.
I love bcachefs but I do not believe it is the most critical code in the kernel. Linux and Linus have responsibilities to MANY other users and lots of other code. I cannot think of any reason bcachefs would be the only code not to follow the rules (software engineering rules).
If they are critical, patches can be made available via other channels.
> we're not engineering anymore
Even an LLM will tell me that software engineering is about good design and effective process. I have never seen a definition that says it is about reactive bug fixing or emergency process exceptions.
I see that the current pull request contains a couple dozen bug fixes and a statement that the experimental flag is coming off. Honestly when I read that, my heart sank and I had to hold my head in my hands a while. Are we going to be requiring emergency bug fixes for a non-experimental file system now? Putting that in the pull request is like pinky-swearing Linus that bcachefs will continue to be a nightmare in the future if he keeps it in.
The experimental flag should come off after a couple of kernel releases with few important bugs and no breaking changes. We have not seen that yet. The last on-disk format change was so recent that I cannot fall back to an LTS kernel because bcachefs differs between kernels. And I have a couple bcachefs systems that I have had to stop using entirely while I wait for the container fix. Taking "experimental" off now may be good marketing but it is not good engineering. At least, that is my view.
> supporting users
Let me thank you again for bcachefs. Until recently, I was a vocal advocate. I dearly hope it finds a path to wider adoption. And let me emphasize that you do not owe me a damn thing. But if you are going to put "supporting users" in every message you write, you are talking about me and I get a voice.
First, the filesystem being set as "experimental" is a social contract that we users agree to. Bugs are expected and we users must be prepared for them. I have systems that have been rendered effectively unusable due to the bcachefs container bug. But I knew what I signed-up for. I must admit, it blindsided me a little as I was ready for data loss but not a multi-release loss in system functionality like that. I can prepare for and handle data loss though.
Second, being accepted into the mainline kernel is also a social contract. In addition to the rules pre-existing, being well-known, and therefore definitely something you agreed to, I feel like you implicitly made certain promises to your users. I watched bcachefs for a long time but did not start deploying it until it was accepted into the mainline. I knew it was not stable but there were a number of other things I could start to depend on at that point (I thought). In my view, getting kicked out of the kernel will be a breach of the social contract you made with users like me. Your repeated statements do not make it feel like you see it that way at all. Once bitten I guess.
> supporting users
One more time, bcachefs the tech is great. And again, you owe me nothing. And I actually like "the words". I want to use tech built by devs that are passionate, user focussed, and proud of their code. But if you are going to keep throwing that phrase up as a defense or justification, you should know that not all of your users feel supported by your actions. I feel abandoned and betrayed. Again, you owe me nothing. But this is real information you can use to decide if you are actually "supporting users" as much as you say you are.
> People keep acting like I'm the only one who has control over this
People are acting like it is your fault? Or that you bear more than half of the responsibility? That is what I see in the messages I have read. When everybody thinks one thing and you think something else, what does that generally mean?
> bcachefs is still in tree last I checked.
Yes, it appears that perhaps Mr. "don't break user space" is trying to support his users and meet his end of the social contract for accepting bcachefs into the kernel. I hope so. But few of "his" users are bcachefs users. Most of the rest of them may be better supported by kicking us out. There is still hope. Fingers crossed.
> I'm not
Sigh. Perhaps not.
Posted Aug 5, 2025 1:42 UTC (Tue)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
Are you referring to the overlayfs/docker issue?
That's an overlayfs issue, with an overlayfs fix coming in 6.17, but bcachefs in 6.16 has a workaround - you can mount with -o casefold_disabled.
I find it interesting that you're here complaining about your own issue, while saying it's perfectly fine for everyone else to wait on their bugfixes.
Where have I heard that before... :)
Posted Aug 5, 2025 22:36 UTC (Tue)
by jmalcolm (subscriber, #8876)
[Link] (1 responses)
Completely wrong and I hope that most readers see that clearly. Maybe not. After all this thread is about self-blindness and I guarantee that I am not immune to that.
As you quoted me, "But I knew what I signed-up for". That is me taking accountability for my actions and explicitly not blaming bcachefs at all (and not you either). Sorry you misunderstood that. Accountability. You know, exactly the thing I am trying to highlight for you. If you misunderstood that, let me be clear: I am praising bcachefs (thank you again for it) and being critical of your lack of accountability*.
I am not the only one. The majority of the messages on your most recent Patreon post say the same thing. As do other forums I have seen. There, as here, you have a different take. But none of those Patreons want to fight. We all want to be on the same side (us with you)--in the kernel.
I will say one last thing only because I want bcachefs to stay in the kernel.
Here is my main posit for you:
On the LKML you have engaged in a battle with one of the most famously blunt, aggressive, dismissive, abrasive, and inflexible people in the Open Source world. Yet, the consensus is that you are the one having trouble playing well with others. That gives you no pause at all?
Perhaps a light-bulb will come on and you will put less energy into getting bcachefs kicked out of the kernel. Then again, I believe that weaknesses are over applications of a strength. So, perhaps I should leave you alone and be careful what I wish for.
No more from me. I will go back to being thankful for bcachefs (even if I can personally no longer use it) and leave you to be you. bcachefs is nice work. Good luck.
* In case this is still not clear, my criticism is of your LKML behaviour only, not an attack on you generally. I do not know you at all beyond some public messages. Well, I know that you gifted us a great fs and that would seem to make you a pretty great guy overall. I just want bcachefs to stay in the kernel. If I have taken the totally wrong approach here, know that what I am really trying to say to you Kent is "please help". Please. And thank you.
Posted Aug 6, 2025 17:39 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
You had an issue with bcachefs that kept you from running it; that's a legitimate thing to bring up. But I do - often - have to point out that there are things outside of my control.
Regarding the casefolding/overlayfs issue, it was bad form for one subsystem to be depending on global configuration of another subsystem unnecessarily. I only found out about that and started getting reports very late in the 6.15 cycle, and then I almost immediately started working on a proper vfs/overlayfs fix, because we don't want to be telling people "you can use your filesystem for docker, or Windows games - but not both". Doh.
When it turned out the overlayfs fix wasn't going to go in until the 6.17 merge window, I pushed a workaround in bcachefs (that I would have rather not added; it won't be needed when the real fix landed and those things are hard to remove) mid way during the 6.16 cycle.
So if docker/overlayfs was your issue, you should be good to go in 6.16. I apologize for the inconvenience, but when things cross subsystem boundaries it becomes more complicated.
(Side note: the number of reports I got about docker breakage when 6.15 came out was a data point that caused me to revise my estimate of bcachefs usage upwards. I did not expect quite so many reports; most of the people I talk to are running it on fileservers).
Now, I want bcachefs to stay in the kernel too, but I cannot control what Linus does.
I have to focus on my responsibilities: making sure that within bcachefs we're prioritizing robustness, reliability, and user support.
Admiral Rickover (father of the nuclear navy) had a lot of good stuff to say about engineering - one of them was, "if you cannot identify the person who was truly responsible, then no one was". I am responsible for the bcachefs code; what happens outside of my tree is a different story.
We are pushing back here against a culture and an environment which has not had this same attitude of responsibility - if it had, bcachefs would not need to exist.
And that's been the fundamental conflict here; we've had far too many pull request arguments over just getting in bugfixes for bugs that were affecting users, with no justification other than "bcachefs is experimental garbage that no one should be running" - while I'm talking to and supporting those users who supposedly do not exist every day. That's a situation where conflict is inevitable.
So, if you want bcachefs to stay in tree, and users like you to be supported, you're talking to the wrong person.
bcachefs
bcachefs
bcachefs
bcachefs
bcachefs