←back to thread

Bcachefs may be headed out of the kernel

(lwn.net)
144 points ksec | 1 comments | 04 Jul 25 13:32 UTC | HN request time: 0.332s | source
Show context
criticalfault ◴[04 Jul 25 17:57 UTC] No.44466573[source]▶
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.

replies(8): >>44466668 #>>44467387 #>>44467968 #>>44468790 #>>44468966 #>>44469158 #>>44470642 #>>44470736 #
pmarreck ◴[04 Jul 25 19:56 UTC] No.44467387[source]▶
This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time.

It's a damn shame too because bcachefs has some unique features/potential

replies(1): >>44471352 #
rob_c ◴[05 Jul 25 09:28 UTC] No.44471352[source]▶
And a honking great bus factor of Kent deciding enough is enough and having a tantrum. You couldn't and shouldn't trust critical data to such a scenario
replies(1): >>44472312 #
bombcar ◴[05 Jul 25 12:24 UTC] No.44472312[source]▶
There’s no harm doing it - if the thing actually works! Kent getting that lass metro pass wouldn’t cause your file system to immediately corrupt and delete itself.

What you want to avoid is becoming dependent on continued development of it - but unless you’re particularly using some specific feature of the file system that none other provide you’ll have time to migrate off it.

Even resierfs didn’t cease to operate.

replies(2): >>44472721 #>>44473464 #
1. rob_c ◴[05 Jul 25 15:35 UTC] No.44473464[source]▶
> There’s no harm doing it - if the thing actually works

This is the antiphrasis of good project management and stability.

No you want to avoid a static target in a dynamic environment that is unmaintained (such as an experimental fs in the kernel tree).

If it's static and unsupported. You'd end up failing to be run this to recover disks using ryzen9 processors that requires a minimum kernel version where the API/abi have drifted so far that the old module won't compile or import.

If you can't afford to get your hands dirty and hack at the API changing if this has such a bus factor. DON'T USE IT.

Frankly the argument you're making is the other side of stick with ext2 since it works. It's probably going to die soon and frankly unless there's a community to support it. (such as zfs, or ext4 in the kernel, or CEPH in hpc corporate spaces)