4 ms·

BtrFS is ahead, sure, but the code is nasty garbage. I encountered enough permanent BtrFS file system corruptions when the power would suddenly go out after a

by Valmar 8y ago

BtrFS is ahead, sure, but the code is nasty garbage. I encountered enough permanent BtrFS file system corruptions when the power would suddenly go out after a storm... which I thought should have been impossible with copy-on-write file systems that use extents... apparently not. BCacheFS is looking far more stable, even this early in its development.

ahartmetz 8y ago
It seems like bcachefs has the infrastructure that is lacking for btrfs to become robust without superhuman intelligence and / or working memory. From the post: "Basically, there's a new btree transaction context widget for allocating btree iterators out of, and queuing up updates to be done at transaction commit - so that different code paths (e.g. inode create, dirent create, xattr create) can be used together without having to manually write code to keep track of all the iterators that need to be used and kept locked, etc. I think it's pretty neat how clean it turned out."
- Valmar 8y ago
  Indeed. BCacheFS's development is slow, but that's because stability is the ultimate goal. Don't rush to make everything work, but gradually crank out stable code that's actually reliable. Kent almost single-handedly developed BCache, but eventually, other kernel maintainers took over from him. BCache is basically stable now. Kent's plan for BCache was for it to be the basis for BCacheFS from the very beginning, it seems. So, while BCache does what it's good at, it is also architectured to make developing BCacheFS easier. Basically, Kent has been building an entire filesystem almost single-handedly, and has been doing so much better than BtrFS has been. Kent has a corporate sponser now, thankfully, so he can a bit more easily afford to spend more time on it. His Patreon donations seem bare-minimum, though, for the task. Enough-ish, but not ideal.

by Valmar 8y ago

ahartmetz 8y ago

It seems like bcachefs has the infrastructure that is lacking for btrfs to become robust without superhuman intelligence and / or working memory. From the post: "Basically, there's a new btree transaction context widget for allocating btree iterators out of, and queuing up updates to be done at transaction commit - so that different code paths (e.g. inode create, dirent create, xattr create) can be used together without having to manually write code to keep track of all the iterators that need to be used and kept locked, etc. I think it's pretty neat how clean it turned out."

Valmar 8y ago
Indeed. BCacheFS's development is slow, but that's because stability is the ultimate goal. Don't rush to make everything work, but gradually crank out stable code that's actually reliable. Kent almost single-handedly developed BCache, but eventually, other kernel maintainers took over from him. BCache is basically stable now. Kent's plan for BCache was for it to be the basis for BCacheFS from the very beginning, it seems. So, while BCache does what it's good at, it is also architectured to make developing BCacheFS easier. Basically, Kent has been building an entire filesystem almost single-handedly, and has been doing so much better than BtrFS has been. Kent has a corporate sponser now, thankfully, so he can a bit more easily afford to spend more time on it. His Patreon donations seem bare-minimum, though, for the task. Enough-ish, but not ideal.