Comment by forgotpwd16
6 years ago
>stop wasting money on BTRFS
You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?
6 years ago
>stop wasting money on BTRFS
You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?
Take a cursory look into both codebases, the stability of the every feature at launch and on maintenance. It's not hard to see BTRFS is a doomed project. Bcachefs is more like PostgreSQL, the developer doesn't add features until he has a solid design that's well thought out. Hence why he hasn't implemented snapshots.
I don't think too many people consider it stable enough for production, either. (Unless you count a very limited subset of its functionality).
I rather run Bcachefs today than Btrfs, by a mile. At least with bcachefs I won't lose my data.
If you are on BTRFS and you encounter an unrecoverable bug (which seems to be reasonably common), the developers will most likely recommend you wipe the drive and restore from backups (because you had backups, right?)
Even if the data is still on the drive and a bugfix would make the filesystem recoverable again, they don't have the time/knowledge/resources to untangle that codebase and make fixes. Even BTRFS developers don't trust the filesystem with their own data.
If you are on Bcachefs and you encounter an unrecoverable bug, the developer will ask for some logs, or reproduction steps, or potentially even remote debugging access to your corrupt filesystem.
And then he will fix the bug, releasing a new version that can read/repair your filesystem. He knows his codebase like the back of hand.
In my research, I couldn't find any examples of someone actually losing data due to Bcachefs. All the bugs appeared to be "data has been written to drive, but bug prevented reading"
While I would still hesitate to trust Bcachefs, I would trust it way more than BTRFS.
Just want to note that bcachefs looks great (I was sort of tangentially aware but hadn't dedicated significant attention to it).
Definitely something to try out (backing up my home servers is just about to reach viability for me, so I'd definitely consider switching to it in that use case).
Thanks!
Btrfs is the only FS I used that resulted in complete FS corruption losing nearly all data on disk, not once, but 3 times.
After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.
Anecdote, I know, but I have about a dozen machines with BtrFS volumes, all active with varying loads and never experienced data loss. It seems some features are more mature than others - only two of the volumes span more than one disk and none has files that are larger than a physical volume (even though one of the multi-device volumes is striped).
In the 26 years or so I have used Linux, I have had corrupted filesystems with reiserfs, XFS, btrfs, and ext[23]. In the case of reiserfs and XFS it was practically impossible to recover the filesystem (IIRC reiserfs would reattach anything that resembled a B-tree). For ext[23], it was surprisingly easy to get back most of the data. Never had any corruption with ZFS or ext4. I didn't try to fix the btrfs filesystem, since it was a machine that had to be repurposed anyway.
My experience with recovering btrfs is that you get back most of your files, but with the content replaced with random gibberish. Which is not too useful.
In a way, I would rather it bomb out and declare a total loss than to keep sinking more time into it as it leads you along.
When was it that XFS got corrupted on you? I think as RedHat embraces XFS, I assume it's quite good now.
1 reply →
Funny the other day on another HN thread, someone was saying btrfs is good even though I said RedHat has abandoned the btrfs ship but then he said Facebook had been using it heavily.
But seeing how so many people had lost data using it, I will never use btrfs...
I don't think BTRFS has ever been considered stable.
I think they just said: "The on-disk data structure is stable" and lots of people misinterpreted that as "the whole thing is stable"
A stable on-disk data structure just means it's been frozen and can't be changed in non-backwards compatible ways. It says nothing about code quality, feature completeness or if the frozen data structure was any good.
The finalization of the on-disk data structure came soon after Btrfs was announced and happened before 2010. I meant that by 2010s when Bcachefs started development, Btrfs was considered a supported filesystem for "big name" server distros such as Oracle and SUSE.