Bcachefs may be headed out of the kernel
28 points by jmillikin
28 points by jmillikin
This whole thing is so frustrating. I’ve been keeping an eye on bcachefs for years and I’d like to try it at some point. But unless something changes, I don’t think I’d risk it anymore. Not because I don’t trust the filesystem but because I’m losing faith in the leadership. I don’t care whether Kent is right or wrong, it doesn’t matter. If he can’t learn to compromise and accept decisions then the project will die and that would be such a shame. He talks like he’s advocating on the part of bcachefs users, and though I’m not one myself yet, I would imagine that what bcachefs users really want is for the project to have a future. This drama isn’t serving anybody.
The main problem, as far as I can tell from the outside, is that bcachefs is Kent Overstreet.
Something like 97% of the commits tagged bcachefs are his. Who else understands it well enough to take over if KO takes a six-month vacation? Building yet another major kernel subsystem dependent on one person is just a bad idea. Building it on the basis of one person who insists that their work is so important that they should be allowed to sidestep normal kernel release procedure… is bad.
Branches exist for a reason, and it is perfectly reasonable to suggest that an emergency fix for a low-probability situation should be released to the people who need it now as a branch they can compile themselves (which, face it, they would have to do anyway) rather than submit it as part of a an intermediate release candidate. KO’s contention that
For a lot of users, compiling a kernel from some random git repository is a lot to ask. I spend a lot of time doing what amounts to support; that’s just how it is these days. But rc kernels are packaged by most kernels, and we absolutely do not want to wait an additional 3 months for it to show up in a release kernel -
For something that might be the difference between losing a filesystem and getting it back.
Is just wrong. I think it is completely reasonable gatekeeping to insist that someone who is trusting their data to an experimental filesystem should be able to compile a kernel from standard build instructions. (It’s also reasonable to suggest that anyone who trusts their data to an experimental filesystem should have really good backups, and probably not be running it in production.)
The best suggestion I have is that KO ought to build an organization of 2-4 more people who understand the code, and especially appoint one of them to be the interface to the kernel release procedure.
I think whatever Linus meant was not well communicated there. No idea if that’s “code will be removed”, “I’m done with this merge specifically”, “someone else will deal with you instead”, or something else. The “may be” is doing a lot of work in this title.
From a follow up message from Kent on the thread:
I firstly want to reassure people that: if bcachefs has to be shipped as a DKMS module, that will not kill the project. It will be a giant hassle, especially if distributions have to scramble), but life will continue. I remain committed as ever to getting this done - one way or the other.
Did anyone here use it? I used to have a tendency to try every new FS that goes into Linux, but I never seemed to find bcachefs interesting.
I’ve just started to, and I’m pretty impressed so far. It’s fast, and it seems to cope well with corruption (caused by something unrelated to the fs.) It’ll be really annoying if it gets booted out of the mainline tree.
I’ve got a lot of sympathy for Kent’s position, generally, but surely there comes a point that you just have to accept that the situation is what it is, and work with it / around it? I think to some extent he’s upset that he’s being told off for behaviour that other people were permitted in the past - but the kernel culture is slowly changing in various ways, some good, some maybe not so. Behaviour that crosses from the assertive to the aggressive is less tolerated (good.) Last minute large/invasive patches - even to experimental code - are also less tolerated (arguably less good, maybe a bit too conservative of an approach to experimental drivers.)
I seem to remember that In the old days the -ac kernels used to solve some of these problems; I suppose the closest thing now is “linux-next”, but it doesn’t seem to provide quite the same scope for reaching a wider audience.
I have been trying it again and again since 2018. It works until it doesn’t. When it works its really fast, I did not measure, but it feels notably snappier than BTRFS. Maybe that’s the tail latency thing they write about?
The last time it failed me was this. I still have those disk images laying around, I need to check someday, whether with an up-to-date kernel they mount just fine (as upstream claims in the issue thread) or not. I have decently high confidence in the technology, and I’m absolutely sympathetic of the occasional issue. While not instant, upstream seems very motivated to work issues out, there is strive for perfection which yields results, just not instantaneous.
However, and that is the main thing: I’m not comfortable running a non-mainline, more-or-less one-person FS. Seeing it merged to mainline was the reason for the most recent time I tried it out again.
I tried it and had to back out and revert to ZFS everywhere because BcacheFS has had a propensity for sluggish performance (especially for compressed+encrypted data) and for system freezes, in my experience managing a pretty tame amount of data with it (order low 10s of TBs). The GitHub issue about that category of freeze, last I poked at it, seems to be getting just about nowhere. Add in the drama overhead of not knowing if KO is going to type out the wrong obscenity on some day that ends in Y and get the whole FS dropped from the kernel (as seems to already be the path), and I decided it wasn’t worth the effort.
By all accounts, folks who have had FS breakage outright seem to indicate that KO will move a mountain to make sure you get recovery access to your data, which is great, but I lost faith in the FS when I saw how risky the day-to-day was - it is well and truly still a highly experimental, new FS needing a pool of dedicated, risk-tolerant, testers. And boy howdy was it also slower than a dead mule for my usecases.
ZFS 2.3 on the other hand, is just as stable as ZoL has been for me since I started using it back in 2018: nearly flawless, modulo annoying quirks about RAIDZ with mixed size disks which leads me to just run a bunch of individual drives and git-annex+(sometimes mergerfs) over them instead of trying to do all-ZFS-native pooling.
ZFS 2.3 on the other hand, is just as stable as ZoL has been for me since I started using it back in 2018: nearly flawless, modulo annoying quirks about RAIDZ with mixed size disks which leads me to just run a bunch of individual drives and git-annex+(sometimes mergerfs) over them instead of trying to do all-ZFS-native pooling.
Did you see the recent news about mixed size disk support in OpenZFS, which they call AnyRaid? Initially it’ll just be for mirrors (giving you something similar Btrfs mirroring, where you have any number of disks in a vdev and data is guaranteed to be stored on two or three separate disks) but they’re planning to add mixed disk RaidZ at some point too. The design seems very well thought out and simple too, so it should work well.