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

[Quackdoc]

Sounds like you either have bad hardware or are doing something that isnt well tested. The latter is the most common issue with developing systems, and the former just because testing for hardware failures is hard, so often recovery doesn't work as well in practice as it should on paper.

I have lost three drives of data to BTRFS, but those were all ~10 years ago. I am still using it today (only for git sources, so nothing can be lost), but haven't had failure in 10 years. *shrug*

the reason why I tested it on so much hardware and so many times is explicitly to avoid doing something that isn't well tested. And I know my hardware isn't faulty as im using it now and in the past, I've been running f2fs up until bcachefs landed in stable on my nvme after the btrfs issues for instance and havent had a single issue since, my portable HDD I had btrfs has been running ntfs comfortably since, and my tablet too is now running bcachefs root with zero issues.

as for doing something untested, I highly doubt this is the case since my tablet is just a normal linux tablet doing normal things. I've used btrfs as a scratch disk, used it as portable storage etc. each one wound up failing. if it was a one off thing I would have just reported it and went on my merry way. but after having so many issues repeatedly with it. Im just going to chalk up btrfs as a perpetually buggy filesystem and have officially given up on it

[tildearrow]

i've had btrfs break irrecoverably 7 times last year alone. I keep trying it because people kept saying "oh it's better now, Oh it's better now" it was never in fact better.

How exactly? I've heard that most Btrfs breakage happens due to hardware issues...

Sometimes I like to call it Labconditionsfs because it seems to be what it is.

[erniv2]

Dont tell such horror stories i just started useing btrfs dont jinx me.

[Quackdoc]

How exactly? I've heard that most Btrfs breakage happens due to hardware issues...

Sometimes I like to call it Labconditionsfs because it seems to be what it is.

i've posted it more indepth before, but i've had issues with using btrfs as an VM drive (with chattr applied), I've used it as a cache drive for video work (writing and deleting high quality image sequences) (EXR, Tiff, PNG, JXL etc.) I've had issues using it as a portable HDD for movies and games (emulators mostly) and more.

[Quackdoc]

Dont tell such horror stories i just started useing btrfs dont jinx me.

just make sure you have backups, you already should. it's only a massive issue if you have it as like, your laptop drive or something where if it goes down you are legitimatly out and in trouble. if you have it as a desktop or something, restoring a remote backup is usually fast.

[hoytXeternal]

You obviously don't actually use btrfs because that is 100% false. Btrfs check with repair actually CORRUPTS your filesystem in 99.9% of cases, even the docs say don't run it unless a dev tells you it is ok to. I have had numerous single disk btrfs filesystems destroyed by a power event. None were recoverable beyond running btrfs recover and dumping about 30% of the data on the fs to another drive

I have used btrfs for two years, and it survived hundreds of power outages (yes we had a lot of issues with electricity here) and dozens of online resizes, both shrinking and expanding.

[mdedetrich]

Kent forgot to add: when it's stable.

No data is lost, there is enough metadata for recovery.

[mdedetrich]

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.

Because he changes the fs as it progress'es so the upgrade tool is necessary. Reverting changes to the upgrade tool defeats the point of it exisiting.

I mean why the f**k are you questioning how he is solving the bug. He solved it in ~one week, not 8 years (unlike some other filesystems) and while his language his harsh its understandable in this case its a very critical bug. I personally maintain open source software that is used in mission critical scenarios (i.e. bank payment systems) that has LTS branches and such bugs are backported basically without question, it shouldn't be an argument.

Reverting the change wouldn't even fix anything, because the problem right now isn't how the bug is solved but the fact its not being backported.

and now he's putting all the blame on the stable team (and lying about it). Kent's approach and attitude is a great risk to his users right now. The path he is on will lead to his own burnout.

Its a critical filesystem bug, and generally speaking critical filesystem bugs should be backported to stable releases, thats the whole point of stable LTS

He's so stubborn (and his defenders too) that when anyone tries to give to point it out, it's dismissed as an attack instead of the advice that it is.

Actually it more looks like you are crazed individual who has trigger fingers whenever something negative happens to bcachefs, its almost as if filesystems are companies, you have stock in btrfs and see bcachefs as competition, thats how its coming across.

No one is denying that kent doesn't have the best attitude always, but ffs we are dealing with a software project that has Linus at the helm who gets handwaved away because of his status and being idolized.

[Blademasterz]

Dont tell such horror stories i just started useing btrfs dont jinx me.

I would recommend, ZFS.

[S.Pam]

Yeah, I call bullshit on this one

And you don't think there's something else wrong here... that it is purely a Btrfs issue is very unlikely.