BcacheFS for 6.17

Why'd you put up with it?

> But I feel like the fundamental thing you keep missing here is that it doesn't matter if you're right. It doesn't matter if you're right on technical grounds. It doesn't matter if you're right about the abuse you've received. It doesn't matter whose fault the entire situation is. You are not going to achieve your desired goals by behaving the way you are. Nobody is willing to support you. It may be horrifically unjust, but bcachefs will die and be forgotten and you will have wasted your time.

Ok, you think I've waging some kind of futile war. But - no.

I do have significant support, and a real community I've built up: that's not going to vanish if (when) we have to go the DKMS route. ZFS has shown that can work for a filesystem, they've made it all the way to distro installers, so I think that approach has some legs. People want this thing, it solves real problems and addresses real needs, and a lot of believe believe in my code and my methods. So I've got options here.

Option a: go the DKMS route for awhile. In a couple more years I should have erasure coding, online fsck and a whole bunch of other stuff done that'll make us more than competitive with ZFS for most people. There'll be some big deployments that are already in the works, and we'll be in distro installers - we were well supported by NixOS even before going upstream, I've just been waiting until the experimental label is off to push for more distro support, and that's six months away. Then, in a few years someone else can see about getting it back in (probably won't be me, someone else in the project), and we'll be much more solidly positioned should fights and drama like this arise.

Option b: people have been getting interested in FUSE performance, and I see no reason why a userspace filesystem can't be as fast as in-kernel, to within the margin of error. Ringbuffers for kernel <-> userspace fs communication, threads pinned to each core, temporary per-cpu mappings for zero copy to/from the pagecache - I've been sketching stuff out and it looks plenty doable, and that would open up new long term possilibities, like talking directly to NVME devices, which would cut out a lot of block layer overhead (the block layer really is fatter than it needs to be). A lot of interesting stuff is going on in userspace these days that we might be able to take advantage of.

Option c: I've in the past had real offers from people who wanted to use the bcachefs codebase for other products. Not my passion, but certainly would be lucrative.

Option d: Start playing music again, find a nice hippie village, start having a social life and just work on bcachefs as more of a hobby, supporting my friends and existing users who really like it. I'm sure I could find some way to pay the bills :)

IOW, I really have no need to put up with toxicity and drama if it gets to be too much. And it's been way over the top: I lost a very promising hire because of Linus's repeated public threats to remove bcachefs from the kernel (strangely enough, people don't want to leave a stable job for the new thing when the leader of the project is saying he's going to kill it, and all their coworkers are seeing it and telling them they'd be completely crazy to do it). And it's been an enormous time sink and source of stress: bcachefs isn't just me, it's a whole community, and the drama affects the entire community and I have to respond to it. On top of that, given how often the fights have been over bugfixes, and it doesn't seem to be getting better, I have to consider whether we're really going to have a stable reliable release process staying in the kernel.

So all of that means that being out of the kernel is probably going to be the more stable, secure option at this point.

I like the kernel _community_, I have a lot of friends in it that I genuinely enjoy working with and it's a project that I've genuinely enjoyed being a part of and want to support - but when I've gotten at least a dozen emails from Linus in just the past two months that don't fit on a screen and have all been about how he doesn't trust my judgement, thinks that everyone hates me, thinks I need therapy and have to give a public apology - yeesh. No thank you :)

> It seems like you're not in a place to apologise and change your behaviour, and, well, I do understand that and I've been there before and I understand why it may feel incredibly unfair to be asked to. I'd recommend finding a good therapist to work on that, but also consider whether you can achieve more of what you want by just disengaging from LKML and having someone else take responsibility for managing pull requests and engaging with Linus and other maintainers. This may not be fair, it may not be just, but you're a technical person and you should understand the benefits of pragmatic solutions.

Now hang on, which behavior are you referring to?

Technical criticism really has to be fair game if we're to take ourselves seriously as engineers. I don't mind in the slightest when people tear into my code, and in fact I rather enjoy it (I've said it elsewhere before, and I'll say it again - I'll bake and mail a plate of cookies to the first person that comes up with a good, intelligent insightful rant/flame about the bcachefs code. Stuff like that is pure gold; when people can talk in an articulate way about what frustrates them, that's some of the best and most useful critiquing you can get).

But from what I've seen of the people who've spoken up and said I've pissed them off - or even the stuff people have come up with digging through lore - I'm sorry, it's been just absurd. It's like people have collectively lost their minds and decided to go on a witchhunt (you do realize the kernel community is famously known for being toxic, right? It shouldn't surprise anyone).

The only person I'd remotely want to apologize to that I haven't already is Josef, because I was pretty savage about btrfs the other day on fsdevel. I think highlighting our track record and engineering on standards on filesystems definitely needed to be done; we're a technical community, and we should be making decisions for technical reasons, so even if people within the community don't want to hear it that needs to be highlighted and discussed before git rm -rfing bcachefs.

But Josef is a good guy, and that was a bit over the top, so if Josef's reading this - please consider this an apology.

As for the rest... sorry, not apologizing to people who start swearing at me in technical discussions :)