Bcachefs Goes to "Externally Maintained"

The whole situation is moronic at best. Linux needs a decent modern filesystem in tree. ZFS would easily be it, but unfortunately Sun decided back in the '00s to fuck Linux because they wanted to push Solaris instead. Little they knew ZFS ended up being FreeBSD top feature for years.

Btrfs is constantly eating people data, it's a bad joke nowadays. Right now on Linux you're basically forced to constantly deal with out of tree ZFS or accept that thinly provisioned XFS over LVM2 will inevitably cause you to lose data.

Btrfs is NOT constantly eating people data. You have nothing to back this statement.

It's widely used and the default filesystem of several distributions. Most of the problems are like for the other filesystem: caused by the hardware.

I've been using it for more than 10 years without any problem and enjoy the experience. And like for any filesystem, I backup my data frequently (with btrbk, thanks for asking).

btrfs has eaten my data, which was probably my bad for trying out a newly stable filesystem around 15 years ago. there are plenty of bug reports of btrfs eating other people's data in the years since.

It's probably mostly stable now, but it's silly to act like it's a paragon of stability in the kernel.

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

> Btrfs is NOT constantly eating people data

Tell it to my data then. I was 100% invested in Btrfs before 2017, the year where I lost a whole filesystem due to some random metadata corruption. I then started to move all of my storage to ZFS, which has never ever lost me a single byte of data yet despite the fact it's out of tree and stuff. My last Btrfs filesystem died randomly a few days ago (it was a disk in cold storage, once again random metadata corruption, disk is 100% healthy). I do not trust Btrfs in any shape and form nowadays. I also vastly prefer ZFS tooling but that's irrelevant to the argument here. The point is that I've never had nothing but pain from btrfs in more than a decade

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?

2017 was 8 years ago...

8 years is not a long time.

I know it's not the same, but close enough for me: lvm + xfs works wonders and it's rock solid.

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.

I would love to use xfs on my NAS setup but no checksums is a deal breaker. Checksums have saved me multiple times where I've been able to either repair files with parity or restore from backups.

Without checksums I would have overwritten my backup data and lost a ton of files because the drives were reported that everything was OK for months while writing corrupt files.

8 years ago was the first time that person encountered a problem with btrfs. But that wasn’t the last apparently:

> My last Btrfs filesystem died randomly a few days ago

> Btrfs is NOT constantly eating people data. You have nothing to back this statement.

Constantly may be a strong word, but there is a long line of people sharing tales of woe. It's good that it works for you, but that's not a universal experience.

> It's widely used and the default filesystem of several distributions.

As a former user, that's horrifying.

> Most of the problems are like for the other filesystem: caused by the hardware.

The whole point of btrfs over (say) ext4 is that it's supposed to hold up when things don't work.

Thin provisioning with lvm is afaik problematic, because the file systems aren't aware of it and if you run out of space you're screwed

I think any discussion of btrfs needs to acknowledge that raid5/6 support was promised in the early years, shipped in the kernel in 2013 and, until 2021's btrfs-progs 5.11 release, did not warn users that they risked data loss when creating volumes.

For near a decade btrfs raid5/6 was "unsafe at any speed" and many people lost data to it, including myself.