Bcachefs to be removed from mainline Linux kernel • Hacker News Board

Re: Bcachefs to be removed from mainline Linux kernel

#31

Post by rastignack » Wed, Aug 13, 2025, 6:16 PM UTC

koverstreet wrote: post #25

rastignack wrote: post #24

Earlier quoted context omitted.

Maybe then you should have considered this file system as truly experimental and expected your end users to make frequent backups. And advertise it as such. You could also have some kind of dkms bleeding edge module for your users to test fixes before they reach the kernel. This way you wouldn’t be so preoccupied about getting code as fast as possible in the kernel.

No, a lot of bcachefs users are explicitly using it because of data loss, and they needed something more reliable; that's bcachefs's main reason for existing. Besides that, if you want to make anything truly reliable, you have to prioritize reliability at every step in the process of building it. That means actively supporting it, getting feedback and making sure it's working well, and you can't do that without shipp…

Some distributions do release hotfixes before they reach mainline kernel. If you expect end users to compile Linus’ kernel head, why couldn’t they compile your branch though ? They get timely fixes.

Re: Bcachefs to be removed from mainline Linux kernel

#32

Post by Timon3 » Wed, Aug 13, 2025, 7:35 PM UTC

koverstreet wrote: post #18

Timon3 wrote: post #14

Earlier quoted context omitted.

> If the filesystem corrupts data, it has to be fixed at the maintainer's discretion. This is what the users want. Tough luck it makes Linus' life harder! Where do you get this idea? Lots of Linux users want lots of things - a big part of the reason Linux is so successful is because they don't get what they want, and the project instead focuses on stable development and release cycles. Many users want Linux to break…

Funny, because "don't break userspace" is one of the principles I've been citing. Things always degenerate when it turns into power struggles and people are going "No, I decide!". "Make sure thinks work" is the underlying principle, and it's based on that that the code should have been, and was merged. But then the personality conflicts and power struggles came out, and there's no need for that. - You don't go overri…

> And, regarding bcachefs still being marked as experimental: I'm being much more conservative with the experimental label than btrfs or ext4 were. Your data is safer on bcachefs than btrfs, today: you're not going to lose a filesystem, repair is thorough and robust and complete.

> You may still hit hiccups, which is why the experimental label is there, but robust and complete repair and rock solid multi device have been reason enough for a lot of people to switch already.

It doesn't matter how conservative you are being, it's _still_ marked as experimental. That simply means there's no great pressing need to get a new feature into the next possible release - users can either compile their own kernels, or wait if they aren't able to. They decided to use an experimental file system.

You're making life much harder for these users by causing bcachefs to be thrown out of the kernel. No matter how you twist and turn it, you're responsible for "breaking userspace" in this case. I have no interest in trying to convince you - I've seen people much better at explaining things than I can try to do so, and I've seen you ignore each and every one of them.

Re: Bcachefs to be removed from mainline Linux kernel

#33

Post by rekoil » Thu, Aug 14, 2025, 8:16 AM UTC

itvision wrote: post #17

I've talked to Linus personally about the entire issue and yes, in 6.18 bcachefs is getting dropped. I cannot quote him because it's private. Kent is also aware of his decision.

Sad to see, I was excited to switch to bcachefs on a new setup.

Re: Bcachefs to be removed from mainline Linux kernel

#34

Post by Brian_K_White » Thu, Aug 21, 2025, 5:46 PM UTC

koverstreet wrote: post #18

Timon3 wrote: post #14

Earlier quoted context omitted.

> If the filesystem corrupts data, it has to be fixed at the maintainer's discretion. This is what the users want. Tough luck it makes Linus' life harder! Where do you get this idea? Lots of Linux users want lots of things - a big part of the reason Linux is so successful is because they don't get what they want, and the project instead focuses on stable development and release cycles. Many users want Linux to break…

Funny, because "don't break userspace" is one of the principles I've been citing. Things always degenerate when it turns into power struggles and people are going "No, I decide!". "Make sure thinks work" is the underlying principle, and it's based on that that the code should have been, and was merged. But then the personality conflicts and power struggles came out, and there's no need for that. - You don't go overri…

There is no power struggle.

This is not a case of 2 equal entities failing to find a compromise.

One is both technically more valid and has the simple right to set the terms and processes regardless of other opinions, the other is neither. All failure to function is on Kent, not on any "struggle".