Catastrophic Damage

[mutech]

This issue is about a non-technical bug that has about as wide ranging consequences as the worst of BTRFS.

I switched to using BTRFS a bit more than a year ago, even though I felt uneasy about what I heard about its robustness. I would rather have used ZFS, but I did not like the complications arising from its licensing issues and the hoops I would have to jump through to keep stuff up to date.

I choose BTRFS because it best fits my use case. I don't mind the performance penalties, because they don't impact me enough to make a difference. I don't mind the threat of loosing data, because I actually do backups and I script my setup and considering that I had no issues with BTRFS yet, it's problems are not mine.

But I would much rather use bcachefs. Why use a slower file system that might be less robust and why not use a faster one that is more reliable? Bcachefs should be THE choice, if what is said about it is true.

To me it looks like Bcachefs is the best product and the worst choice at the same time.

Bcachefs runs the risk to be thrown out of the mainline. If that happens, it shares much of the reasons for why many Linux users won't use ZFS.

Bcachefs runs the risk not to be supported by major distributions. I don't want to be restricted from using distros I would prefer if not for bcachefs. I also don't want to go the extra mile to get bcachefs running and maintain it manually in order to use a particular distro. This shares the ZFS curse.

Kent criticised BTRFS harshly because of its misguided priorities. He expressed that its unforgivable not to focus on reliability and not to aim for the best performance an architecture can provide. I see his point, however, if despite making the right technical choices and succeeding in a superior product (my assumption), his communication and working style results in making that superior product an inferior choice, this is actually several orders of magnitude more misguided, because for all users who decide pragmatically on a set of factors that include reliability and speed but also their particular use case, all the technical advantages of bcachefs are lost and irrelevant.

When Kent dismissed Josef's call for cooperation and his request to stop throwing mud at competitors, I only felt sad for Kent not seeing that all the accomplishments he achieved with his priorities, his thrive for perfection, are just wasted.

BTRFS has a horrible reputation - in my perception. But it works just fine. It's bad reputation is overruled by my experience. ZFS works just fine, better than BTRFS. But it's cursed by license and that has practical implication I don't want to suffer. Bcachefs is cursed by ego. That's worse than all the potential defects of BTRFS and ZFS' curse, at least for me.

If this issue was about a catastrophical data loss with bcachefs, it would be the thing Kent absolutely does not want to have me experience. If I have to restore my workstation tomorrow, because of such a loss, that would cost me 2-3h or work. That's annoying if I have to meet a deadline tomorrow, but otherwise I just go out and it's done when I'm back. Not a big deal.

But I cannot in good conscious decide to use bcachefs, and I'm far from the only one. This should be the worst kind of issue any project can receive.