←back to thread

Bcachefs Goes to "Externally Maintained"

(lwn.net)
214 points ksec | 4 comments | 30 Aug 25 13:07 UTC | HN request time: 0s | source
Show context
qalmakka ◴[31 Aug 25 04:26 UTC] No.45080377[source]▶
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.

replies(2): >>45080442 #>>45081632 #
goneri ◴[31 Aug 25 04:44 UTC] No.45080442[source]▶
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).

replies(4): >>45080475 #>>45080496 #>>45083738 #>>45089695 #
1. AaronFriel ◴[31 Aug 25 04:52 UTC] No.45080475[source]▶
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.

replies(1): >>45080490 #
2. wtallis ◴[31 Aug 25 04:56 UTC] No.45080490[source]▶
> 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.

replies(1): >>45080569 #
3. AaronFriel ◴[31 Aug 25 05:21 UTC] No.45080569[source]▶
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?

replies(1): >>45081745 #
4. simoncion ◴[31 Aug 25 09:18 UTC] No.45081745{3}[source]▶
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.