Migrating Away from Bcachefs
23 comments
·January 20, 2025ajb
Bcachefs is experimental, and last I heard, the authors hope to be able to declare it not experimental in ~6 months. To me, that's 'try on a cache server/build server' territory, not on anything where you even think about backing it up.
Kent Overstreet does have a problem working with people; I can well believe that interactions around bugs were painful. He likely he should try to hire someone else to deal with users and distributions and use his limited patience to deal with the kernel maintainers. But it sounds like the OP was a bit naive about what it means to run an experimental FS.
AceJohnny2
> last I heard, the authors hope to be able to declare it not experimental in ~6 months
How long have they been saying that? I feel like that's been the case for years.
ajb
It's only been in the upstream kernel 6 months or so?
I know the FS has actually been around longer, but I've not heard claims about it's stability before that. It's only now that's it's getting a lot more testing
pixelesque
It was merged in 6.7, 12 months ago...
gkmcd
FWIW, I've done a few bcachefs bug reports and thought Kent's responses were great.
ajb
I should not have implied that every bug report would be a bad interaction - and to be fair where I've seen it degenerate in the mailing list, it's often the other person wasn't exactly civil to start with (which unfortunately includes Linus Torvalds). It's just that Kent seems to feel the need to fight back.
Darkskiez
I need to write up my experience. But I'm trying it out. Linux needs something like this. I've had issues, posted traces and had them fixed in seconds. Pretty damn amazing. I'd love to see a bigger team involved though.
gkmcd
My experience also. Kent is obviously very committed to the project.
kstrauser
What's all that about the bcachefs author's complaints with Rust and Debian? I'm far out of the loop on this stuff.
ajb
His side is that basically it doesn't make sense to package the tools for an experimental FS in an OS that's going to get very far behind, as debian stable will do, since the tools have to iterate rapidly to fix problems with releases of the FS. Debian-stable had an old set of some rust libraries and the packager relaxed the dependency constraints in order to package it, which doesn't make a lot of sense on something you are hoping to fix your filesystem.
Basically it shouldn't be packaged for LTS-class OS releases until it's not experimental.
bhelkey
> [bcachefs auhor's] side is that basically it doesn't make sense to package the tools for an experimental FS in an OS that's going to get very far behind
If the bcachefs author's believe the tool is too unstable for Debian stable and Debian developer's believe bcachefs is too unstable for Debian stable [1], it sounds as if they agree.
[1] https://jonathancarter.org/2024/08/29/orphaning-bcachefs-too...
knowitnone
This makes perfect sense to me. Why would Debian-stable include something obviously not stable. They have an experimental branch for a reason
6SixTy
To my knowledge, Debian changed deps in bcachefs-tools to synchronize with Debian's Rust repo, breaking it. It's one part that it's a green fs, and the other with clashing expectations of how to treat dependencies between Rust and Debian.
elitepleb
Debian would compile dependencies with versions lower than specified in the project, reintroducing bugs that users would blame upstream for, https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools
linsomniac
Why is Kent not providing his own deb packages that users can install to override the Debian provided ones to get updates?
kstrauser
Got it. I could see that being an issue.
XorNot
It seems honestly odd to me not to just vendor what you need as standalone packages if your dependencies are that specific and you're a filesystem i.e. you use the bcachefs-errno package, not errno.
tredre3
Debian tends to put their principles above pragmatism (for better or worse), so would they even agree with such vendoring when it's entirely meant as a way to bypass their vision/requirements/process for how dependencies should be handled?
snvzz
I stick to OpenZFS, it's rock solid.
Filesystems are the one thing I don't want to experiment with. Too much potential trouble.
MaKey
Can it still be called "rock solid" with a data corruption bug in its younger history? https://news.ycombinator.com/item?id=38770168
I've been patiently waiting to convert my ZFS array to bcachefs. I'm very excited about better SSD promotion logic. But I'm not willing to spend any time on an experimental filesystem on my main systems.
> But you can expect to get flamed about running Debian, or perhaps more accurately, not being willing to spearhead Kent's crusade against Debian's Rust packaging policies.
It is quite unfortunate that Kent couldn't have just said "Debian isn't supported, we will revisit this when bcachefs is more stable" and stopped talking after that. Debian and experimental software just don't work well together.