Bcachefs Multi-Device Users Should Avoid Linux 6.7: "A Really Horific Bug"

[npwx]

This issue and all other issues I've raised are 100% about kent. Even in this instance, he has patches to fix 6.7 kernel, there's in a git repo. But he's so involved in a fight with the stable team, that he's telling his users that the only option is to move from 6.7 kernel. And the bug itself is very odd, he says it's upgrading "tools" that triggers it. Why not revert the tools change? So he engineered this entire bug, avoid announcing the location of a 6.7 patch, and is currently advocating that no one from the stable team should ever go on vacation.

Very weird indeed. While the filesystem may or may not eat your data, its maintainer is obviously willing to gamble with his users data over some ego cock fighting.

[varikonniemi]

This is why for many things you don't immediately jump to the latest and greatest until it has been thoroughly field tested by chumps, I mean early adopters.

This goes on Windows, Linux, Unix, Solaris, BeOS, Mac OS, I don't care, you don't trust something as critical as your data to a newcomer.

I stuck with Win 2k for years until i had no choice but to upgrade to Win XP because i needed DX8, i stuck with XP until I had no choice but to upgrade to Win 7 and so on.

On Linux I stuck with XFS for years before I used EXT4 and I have no intention of moving to a new file system until i have no choice.

I remember trying Btrfs with Fedora on a test system and losing everything on the drive, which didn't matter since i back everything up to multiple drives but still a pain in the ass.

My advice to Linux users, pretend that no other filesystem exists and stick with EXT4 until it gets deprecated.

after looking through bcachefs design i feel very much more secure using it than btrfs. I mean, how is it possible that running out of free space on the disk corrupts your filesystem? Must be first time in computer science history that this has been encountered, offered to you by btrfs?

[NotMine999]

after looking through bcachefs design i feel very much more secure using it than btrfs. I mean, how is it possible that running out of free space on the disk corrupts your filesystem? Must be first time in computer science history that this has been encountered, offered to you by btrfs?

Your comment reminds me of an old joke (and you might actually need to be OLD [in calendar years, not kernel years] to actually understand this):

"How can I be out of money when I still have checks?"

[Abacus123]

Why would I use bcachefs over btrfs? Both fedora and opensuse use btrfs as the default filesystem and it works just fine for me. I heard the only areas where btrfs is flakey is with certain RAID configurations but I don't use RAID.

[Mitch]

Why would I use bcachefs over btrfs? Both fedora and opensuse use btrfs as the default filesystem and it works just fine for me. I heard the only areas where btrfs is flakey is with certain RAID configurations but I don't use RAID.

The biggest thing bcachefs does over btrfs is tierring. If you mix drives with different performance characteristics, it'll be able to move the data around so that your most-used data is available on your fastest storage, while your least-used is moved to the slower drives. It also can put your writes through fast media.

In essence, it's like btrfs in many important ways, but the Cache part is unique. It gives you the speed and responsiveness of NVMEs plus the capacity of HDDs if you configure it this way. Btrfs has no answer to this.
Also, they have very different approaches to erasure coding / raid5/6, but both are not in a completed state quite yet when it comes to erasure coding.

Zfs has tierring to some degree, but after my using both, ZFS seems to be slower to promote data to faster drives than Bcachefs and it's not quite as nice when it comes to writes. ZFS and Btrfs have the advantage of being used in production use-cases for longer than Bcachefs

[sophisticles]

I mean, how is it possible that running out of free space on the disk corrupts your filesystem? Must be first time in computer science history that this has been encountered, offered to you by btrfs?

Back in the Win 2k days i ran into something similar.

I had bought a brand new 160gb hard drive that had been formatted on another system. Win 2k without any service packs supports a max of 128gb and I installed the 160gb drive as a secondary drive and started copying files from external drives.

When it hit the 128gb limit the OS started writing to the drive from the first sector, effectively overwriting the data that had a;ready been copied.

The first time i didn't realize what had happened, thought I must have screwed up somewhere and started over.

The second time i realized that it was restarting the data writes after hitting the 128gb barrier and remembered I had not installed the service packs yet.

Once i did that everything was fine.

Ubuntu has an issue where if the root partition runs out of space, and you reboot, you can not log in again, you end up in an infinite loop where you input your credentials, they get validated and you get returned to a login prompt.

[PuckPoltergeist]

"eating your data" is commonly understood as "files gone and unrecoverable".

Eating your data is also corruption. And split-brain is a very good chance for this.

It is even quoted in the article itself, bcachefs is designed in such a way that there should be enough metadata to recover your data.

XFS was designed that fsck and repair wasn't necessary. The end of the story is well-known...

[Nozo]

You'd have to be stupid to start using a brand new filesystem in production systems as soon as it lands in the kernel. I am very excited about bcachefs but I am not getting near it for at least a couple of years.

I mean, not even BTRFS is fully stable yet.

[Quackdoc]

It's nice to see these issues ironed out. It will be nicer when the code is re-written in rust so I will be able to actually read the code without bashing my head on a wall

"The COW filesystem for Linux that won't eat your data".

As long as the data is recoverable, I don't consider it eaten.

[PuckPoltergeist]

As long as the data is recoverable, I don't consider it eaten.

This is called backup