[lproven]

How long have you got?

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

I have had Btrfs collapse and corrupt itself more in the last half a decade than all other Linux filesystems put together this century.

If you fill the volume, it will fail, and its own repair tools do not work and will damage it further. I would not and do not trust it.

[jcalvinowens]

I don't care about the raid features personally, that's irrelevant to me. I care about snapshotting and send streams more than anything else.

Your anecdotal evidence about data loss is meaningless. I can counter with my own anecdote: I've had zero data loss with btrfs running pre-release RC kernels on my laptops for over a decade. I fill up disks a lot.

[lproven]

Good for you.

One failure report is worth 1,000 success reports. Add as many orders of magnitude as you wish, and the statement remains true. This is not merely an axiom of reviewing and assessment, it's a joke:

https://xkcd.com/937/

I've been reviewing tech for a living for nearly 30 years now, and evaluating tech for a living -- as well as using it and fixing it and deploying it -- since the decade before that.

The point of tech assessment and tech reviewing is to balance the good features against the bad features. Too many people get dazzled by the good stuff so that they don't notice the bad stuff.

As the late great Douglas Adams put it:

« In other words - and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws.” »

I don't care how good the features of a filesystem are if I can't trust it. Either it needs to be very solid, and have good documented battle-tested tools for fixing it and repairing it, such as XFS or JFS... which probably means it is also conservative on the features.

Or, alternatively, absolutely blasted bulletproof, to the extend that a multi-billion-dollar corporation sees fit to launch it without a repair tool because it doesn't need one.

There is one such system, and it is ZFS.

Btrfs is neither. It is loaded with features, some half implemented if that, it is fragile, and it does not have good repair features.

If I had seen it fail once, I would be dubious and sceptical.

If I had seen it fail twice, I would no longer trust it.

But I have not. I have seen it fail half a dozen times in 4 years.

And it is not just me.

Here is the documentation on the repair tool:

« Warning

Do not use `--repair` unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume. »

Source: https://btrfs.readthedocs.io/en/latest/btrfs-check.html

Here is #1 corporate user SUSE's:

« WARNING: Using '--repair' can further damage a filesystem instead of helping if it can't fix your particular issue. »

Source: https://www.suse.com/support/kb/doc/?id=000018769

In corporate terms, this is an admission.

This tool cannot be trusted and that it is present means that the FS cannot be relied upon.

This is a giant red flashing light and eardrum-bashing warning siren.

It doesn't matter how many people like it and have had no problems. THERE ARE PROBLEMS. It doesn't matter how many corporates use it. A broken tool may still be usable.

Meta may deploy Btrfs across racks of kit but they don't care about the data on those racks and it can be replaced.

Fedora doesn't use snapshot support because it's bodged that functionality into OStree so it doesn't care if it's dangerous. It just wants to describe how horrendously inefficient Flatpak is.