[lproven]

> 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.

[gosub100]

The first time I tried it out about 4 years old, I bricked it within a few days!! It was on a new (to me) Linux distro or maybe an existing one but I heard it was cool and the snapshots sounded neat.

I stayed away for a while but have it again on a Garuda install. I never completely give up on a technology, I hope they get it together.

[tiberious726]

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

[lproven]

It is the default root filesystem on SLE and openSUSE, as well as Garuda, SpiralLinux, GeckoLinux, siduction, and others.

(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.)

[AnonC]

> It's the single most unreliable untrustworthy filesystem I've used in the 21st century.

I think the “experiences differ widely” point makes sense with this comment too. Synology uses btrfs on the NAS systems it sells (there’s probably some option to choose another filesystem, but this is the default, AFAIK). If it were to be “the most unreliable untrustworthy filesystem” for many others too, Synology would’ve (or should’ve) chosen something else.

[curt15]

Synology only uses btrfs in single-disk mode and implements RAID-1 functionality using its own patched version of mdadm to side-step the gotchas of native btrfs raid1.

[electricant]

What 'gotchas' exactly?

[tiberious726]

None for raid 1. They do it for raid 5/6 if you're a crazy person and want to run parity raid in 2024.