4 ms·
My impression as a total outsider here is that most (all?) other filesystems I'm aware of are either more mature - and generally not in active feature developme
by dataflow 1y ago
My impression as a total outsider here is that most (all?) other filesystems I'm aware of are either more mature - and generally not in active feature development - or they are not as popular, limiting the damage. Is this inaccurate?
I will also say that bcachefs's selling point - and probably a major reason people are so excited for it - is amount of effort it puts into avoiding data corruption. Which tells you something about the perceived quality of other filesystems on Linux. Which means that saying "other filesystems seem fine with the rules" misses the very fact that people have seen too much data corruption with other filesystems and want something that prioritizes it higher.
- dismalaf 1y agoBtrfs is still very much being developed, in the kernel and is quite popular.
- koverstreet 1y agoChris Mason moved on a long time ago, Josef seems to be spending most of his time on other things, and if you look at the commit history btrfs development has been moving pretty slowly for a long time. It's a bad sign when the key founders leave like that, filesystems require a lot of coherence of design and institutional knowledge to be retained.
- samus 1y agoYes, Bcachefs is experimental and thus needs more fixes. Everyone understands that, and bugfixes are indeed totally fine to be merged at all times. The problem are new features, general improvements, and fixes that are actually features or require nontrivial refactorings. I understand the temptation, but these carry significantly higher risks than a well-thought out bugfix and are thus not welcome outside the merge window. Most prior rows between Kent and Linus have been about such patches, sometimes surreptitiously mixed in with more benign fixes. This time his argument is "think of the distro users", but this won't fly - those either accept that using an experimental FS has consequences, or Kent learns how to work with the kernel community instead of testing the boundaries of the rules in the name of all the oppressed kernel developers gatekept by Linus. Shipping bugfixes for bugfixes would be kinda embarrassing for everyone involved (Kent, Linus, and the distros!), and that's why Linus rejects his PRs.