Earlier quoted context omitted.
> As someone who admins a lot of btrfs, it seems very unlikely that this was unrecoverable. As someone who used it all day every day in my day job for 4 years, I find it 100% believable. I am not saying you're wrong: I'm saying, experiences differ widely, and your patterns of use are not be universal. It's the single most unreliable untrustworthy filesystem I've used in the 21st century.
As someone who has used it in my day job since 2014, I find it around 5% believable. I've had nasty performance issues on old kernels, but never a single instance of unrecoverable data loss, and I've run it in plenty of pathological cases. Experiences differ
(I name these because all use snapper to provide transactional packaging and installation rollback. This is less relevant to other distros which use Btrfs but do not offer transactional packaging, e.g. Fedora or Oracle Linux.)
The snapper tool makes a pre-install snapshot before packaging operations. It can't get a reliable estimate of available space before doing this, because `df` does not work. It returns an estimate which is not reliable.
Result, snapper or packaging operations can fill the root filesystem.
Attempted writes to a full Btrfs volume will corrupt it in my fairly extensive direct personal experience.
And the `btrfs repair` tool does not work and can't fix a corrupted volume. Both the Btrfs docs and SUSE docs tell you not to run it: this is not my opinion, it's objectively verifiable info.
This caused total OS self-destruction 2-3 times per year, on 2 different desktops and 1 laptop, for 4 years.
The official guidance is: have a really big root partition and do not keep `/home` separate.
However, given that it's only having a separate /home partition (formatted XFS or ext4) that allowed me to reinstall and keep working, I refuse to do that.
When a FS repeatedly collapses and self-destructs on me, no, I will not hand it even more of my data to destroy. That would be irrational.
I know why. I know what steps could hypothetically avoid this, but for other reasons those are not desirable to me.
But this is not acceptable FS behaviour for me. The demands of Btrfs advocates of what I should do are not reasonable to me.
I am happy to accept that other configs would not exhibit this, but the thing is this:
1. A core USP of SUSE distros is transactional packaging
2. Their transactional packaging needs snapper
3. Snapper needs Btrfs
4. Because of design flaws in Btrfs, snapper can corrupt the OS partition
5. Over some 15 years these problems in Btrfs have not been fixed
That makes me think they can't or won't fix it.
That is an unacceptable price to me. My choices are to risk a self-destructing distro, or to risk all my data on a fragile FS, or to forego the distro's USP.
None of these are acceptable prices to me.
Others' mileage varies. That's fine. It's a free market. Go for it. Enjoy.
OpenSUSE is a good distro with some great tech, but the company needs to study rival distros more, learn its own weaknesses, and fix them.
(This is true of most distro vendors.)