> but it's silly to act like it's a paragon of stability in the kernel.

And it's dishonest to act like bugs from 15 years ago justify present-tense claims that it is constantly eating people's data and is a bad joke. Nobody's arguing that btrfs doesn't have a past history of data loss, more than a decade ago; that's not what's being questioned here.

▲

AaronFriel 4 days ago | parent [-]

There's no need to call someone pointing out instability of a filesystem dishonest. That's bad faith.

I don't get why folks feel the need to come out and cheer for a tool like this, do you have skin in the game on whether or not btrfs is considered stable? Are you a contributor?

I don't get it.

But since you asked - let me find some recent bugs.

5.15.37 - fixes data corruption in database reads using btrfs https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15....

5.15.65 - fixes double allocation and cache corruption https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15....

6.1.105 - fixes O_APPEND with direct i/o can write corurpted files https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1...

6.1.110 - fixes fsync race and corruption https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1...

6.2.16 - fixes truncation of files causing data corruption https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.1...

btrfs-progs 6.2 fixes corruption on zstd extent read https://btrfs.readthedocs.io/en/latest/CHANGES.html

6.15.3, 4: possible data corruption, seems to be reparable: https://www.phoronix.com/news/Btrfs-Log-Tree-Corruption-Fix

Are people that encountered these also dishonest?

	▲	simoncion 3 days ago \| parent [-]
		ext4 has "recent" correctness and corruption bugfixes. Just search through the 6.x and 5.x changelogs for "ext4:" to find them. It turns out that nontrivial filesystems are complex things that are hard to get right, even after decades of development by some of the most safety-and-correctness-obsessed people. I've been using btrfs as the primary filesystem on my daily-driver PCs since 2009, 2010 or so. The only time I've had trouble with it was in the first couple of years I started using it. I've also used it as the primary FS on production systems at $DAYJOB. It works fine.