Yeah.. the thing is, suppose Kent was 100% right that this needed to be merged in a bugfix phase, even though it's not a bug fix. It's still a massive trust issue that he didn't flag up that the contents of his PR was well outside the expected.
That means Linus has to check each of his PRs assuming that it might be pushing the boundaries without warning.
No amount of post hoc justification gets you that trust back, not when this has happened multiple times now.
It's such a shame. We don't quite trust btrfs (but it's probably fine!), we don't quite trust the ZFS license and the fact that it is not in the Kernel (but it's mostly fine!), so Bcachefs would be so nice to have. A modern FS that one uses on their Linux root (or anywhere), as confidently as one does ext4.
But what prevents it ultimately? This ... situation. It makes me sad.
I didn't follow the details but I know that Linus is a reasonable person, and Kent is very thorough and delivering quality. But even if Linus was too much on the conservative-side here (but who's to judge??), please Kent, just fall in line. The alternative is nothing. Go have a beer with Linus.
I donate to Kent's patreon and I'm very enthusiastic about bcachefs.
However, Kent, if you read this: please just settle down and follow the rules. Quit deliberately antagonizing Linus. The constant drama is incredibly offputting. Don't jeopardize the entire future of bcachefs over the silliest and most temporary concerns.
If you absolutely must argue about some rule or other, then make that argument without having your opening move be to blatantly violate them and then complain when people call you out.
You were the one who wanted into the kernel despite many suggestions that it was too early. That comes with tradeoffs. You need to figure out how to live with that, at least for a year or two. Stop making your self-imposed problems everyone else's problems.
I'm sure it can be annoying to collaborate with the other Linux people, especially if social interactions don't come easily to you - as I assume is the case for Kent - but if you want real adoption of your fs and improvement to the status quo, playing by their rules and being humble seems like the most reliably way to get there.
I say that as someone that has donated to the project. I want to have a real alternative to zfs, let's please get there.
This whole debacle is the perfect advertisement for microkernels. The only reason Kent needs to coordinate with Linus is because filesystems need to live in the kernel. FUSE is second class. Imagine how much easier this all would be if linux maintained a slowly evolving filesystem API, and all bcachefs had to do was keep up with it.
Lots of people mentioning ZFS, which can’t do hibernation correctly as sometimes ZFS will still do some writes after that ram has suspended. Which I feel like would complete the story of here’s my mobile device that is snapshoted and backed up regularly.
I wonder where bcachfs in regards to mobile snapshots and hibernation.
In this context, this is worth a read: https://hachyderm.io/@josefbacik/114755106269205960
So the assertion is that users with (critical) data loss bugs need complete solutions for recovery and damage containment with all possible speed, and without this "last mile" effort, stability will never be achieved.
The objection is the tiniest bug-fix windows get everything but the kitchen sink.
These are both uncomfortable positions to occupy, without doubt.
No matter how good the code is, Overstreet's behavior and the apparent bus factor of 1 leave me reluctant to investigate this technology.
Does the filesystem actually need to be part of the kernel project to work? I can see where you'd need that for the root filesystem, but even then, couldn't one migrate an existing installation to a new partition with a different filesystem?
The older I get the more I feel like anything other than the ExtantFS family is just silly.
The filesystem should do files, if you want something more complex do it in userspace. We even have FUSE if you want to use the Filesystem API with your crazy network database thing.
For some reason I always read this as “BCA chefs”.
The drama with Linux filesystems is just nuts... It never ends.
This happened about a year ago as well: https://news.ycombinator.com/item?id=41407768
today Kent posted another rc patch with a new filesystem option. But it was merged..
May be bcachefs should have been governed by a group of people, not a single person.
For the uninitiated:
bCacheFS, not BCA Chefs. I’m not clued into the kernel at this level so I racked my brain a bit.
Linux needs a true answer to ZFS that's not btrfs. Sadly the ship has sailed for btrfs, after 15+ years it's still not something trustable.
Apparently bcachefs won't be the successor. Filesystem development for Linux needs a big shakeup.
Good
Good. There is no place for unstable developers in a stable kernel.
If Linux would add a stable kernel module API this wouldn't be a huge a problem and it would be easy for bcachefs to ship as a kernel module with his own independent release schedule.
Even if you're an absolute stickler for arbitrary guidelines, Linus can easily just enforce the rule and not merge, that's it! He already sees this FS as very experimental, so any subtle bugs remaining due to the dev not fixing them according to the process is acceptable. Inflating the drama and threatening compete removal is a hissy fit.
I fear posting this because it's YouTube content and I don't know of the creator very well beyond these videos, but I have been following this saga a bit from this creator:
https://www.youtube.com/@SavvyNik/videos
He gets a few words wrong because my understanding is he covers the topic in a more broad way, but most of his coverage seems objective and factual. He does have some opinions, but I think it's closer to journalism of the LKML than an opinion piece.
I've been following this for a while now.
Kent is in the wrong. Having a lead position in development I would kick Kent of the team.
One thing is to challenge things. What Kent is doing is something completely different. It is obvious he introduced a feature, not only a Bugfix.
If the rules are set in a way that rc1+ gets only Bugfixes, then this is absolutely clear what happens with the feature. Tolerating this once or twice is ok, but Kent is doing this all the time, testing Linus.
Linus is absolutely in the right to kick this out and it's Kent's fault if he does so.