Bcachefs Merges Support For Btrfs-Like Snapshots

[brucethemoose]

bcachefs has raid (1/10/5/6), checksumming, supports ssd cache (write / read), encryption, snapshots, compression, dynamic removing and adding of disks at runtime

all of those features are marked stable (considierung its small user base take this with a grain of salt).
i wouldnt call that low overhead.

Ah, seems I got a very incorrect impression of bcachefs from somewhere else.

[mdedetrich]

You are not in breach of any licensing terms when using libreoffice.

Yes I know, I didn't mention otherwise.

You are when using ZFS. The licence was deliberately chosen to be incompatible with that of the linux kernel. Remember, Oracle own the code, so if they wanted to kill any ambiguity, it could be licensed to be GPL compatible tomorrow. Or they could choose to include the code in their fork of RHEL (Oracle unbreakable linux) which would hint (but not guarantee) that they dont intend to sue users

It may not matter much to home users, but if you are a company that is profitable, it is a heck of a risk to take.

I get that people like the software. but if I needed to use it, I would use it on a BSD where Oracle could not sue for licence infringement.

The point is that people are mixing 2 things up, one is the CDDL license with its GPL2 incompatibility and the other is oracle suing a company because of using ZFS.

The former is an obvious problem hence why ZFS isn't in the kernel tree. The latter is a complete non issue, Oracle cannot sue anyone for this any reason, you actually have to breach the CDDL license and you can up and read what the CDDL license is (its very close to mozilla's open source license).

Its also important to note that Oracle did not create CDDL, Sun did. It is also an approved open source license according to the FSF.

So this "oracle suing people because of CDDL" is just plain FUD, its just as likely to happen as Oracle suing companies for using OpenJDK.

If you have a corrupted filesystem after a power down go yell the drive/controller/motherboard manufacturer. It's the most battle tested feature of btrfs: every transaction is atomic (assuming no faulty storage stack).

Unless Khrundel is using a HBA (which I doubt), I suspect he is using motherboard sata in which case this is not what is going to be causing errors on BTRFS (in such a case its an error with the BTRFS filesystem).

[F.Ultra]

its just as likely to happen as Oracle suing companies for using OpenJDK.

Or perhaps Dalvik ;-)

[useless]

Unless Khrundel is using a HBA (which I doubt), I suspect he is using motherboard sata in which case this is not what is going to be causing errors on BTRFS (in such a case its an error with the BTRFS filesystem).

He explicitly stated that he used bcache underneath. That setup tends to end up in disaster.

Yeah. Sure. "Four legs good two legs baaad". I've asked you a question. Is it ok to lose 2-3 days work due to filesystem corruption? How frequently btrfs users have to backup all their important data? Once a day? Once an hour?

Me, most of my coworkers and every member of my family does daily backups. Just a send-receive to the NAS and done (and to a cloud storage provider). We started doing this after the first time we hit data loss; guess what filesystem we used. Hint: it poisoned all of our mediocre backup strategy back then.

That is bullshit. You can't seriosly suggest "just copy all data to another drive, reformat and restore" as a solution for a minor FS corruption. Do you understand that whole filesystem copy of modern HDD takes 2-10 hours?

No, you're doing it wrong:

1. Copy everything that can be salvaged (if it's not in your daily backups).
2. Find the root cause of the transid missmatches.
3. FIX that root cause.
4. Then reformat and restore.

It's basic troubleshooting. Why you assume it's just a "minor FS corruption"? If several generations were lost to a bad cache device then it's a major FS corruption.

I don't know why you going in circles. As I've already have written, files was deleted by repair tool. No magic required, just don't do additional harm.

Why to yell at someone else if it is btrfs' fault? This system is garbage. 8 years of "production ready" state and it still have no decent repair, which won't corrupt system more. What will be next excuse? "Just buy an UPS already"?

I still don't get why you think that data loss because of faulty hardware could be blame on a tool that tries to fix what isn't there. It's stated in the fricking manpage what kind of errors it can solve effectively and then give you a big warning not to use it indiscriminately. You have restore to salvage data, which shouldn't be to much because of backups. fsck only tries to repair the consistency of the filesystem and it gives you no guarantees of what it reconstructs (why do you think there's a folder called lost+found?), why do you rely more on that? That the stack somewhat failed to write something and it didn't error'd as it's supposed to is a MAJOR issue. Actually, it's a stop-gap issue because it will happen again; any other regular FS is oblivious to that usually.

Or maybe they just can't tell their customers "if it's not backed up, it's not important" every time btrfs failed. Something tells me this is more probable cause than "they don't want to pay salary for one additional programmer".

They accumulated expertise in another solution before btrfs had gone production ready. SUSE, Facebook, Western Digital and Oracle took another path. What was your point again?

[useless]

Why do end users always think they know better than the devs who put the warning there? Maybe the btrfs-progs devs should set a code for --repair, that you can only get past by asking on the mailing list or looking at the source.

People who think that BTRFS is unstable in every day use cases are really weird. It's used on thousands of servers at my work, also AFAIK facebook uses it for their container/cloud infrastructure. It doesn't magically fail, unless hardware is broken or you do something weird & out of scope.

It beats me. Seriously, of all of the reason not to use btrfs (high performance database servers? logging servers maybe? VM servers that already use CoW?) they chose the ones that actually makes btrfs a solid filesystem.

Most of these rants are based on FUD, bad hardware or user error. They even refuse to acknowledge that a disk's firmware can do nasty things without ever logging something to smart. "but ext4 doesn't corrupt itself" you hear... well, no shit since ext4 doesn't have near the same amount of integrity measures built into it to preserve the files it stores (or, at least, to yell at you that it cannot give you the same thing you told it to write). btrfs devs even started putting together a common knowledge database of shitty disk model/firmware because of the bad reputation these issues are bringing on them; mostly spinning WD for now, SSD are even worst.

[Khrundel]

He explicitly stated that he used bcache underneath. That setup tends to end up in disaster.

Then why there is no disaster with other filesystems?

Me, most of my coworkers and every member of my family does daily backups. Just a send-receive to the NAS and done (and to a cloud storage provider). We started doing this after the first time we hit data loss; guess what filesystem we used. Hint: it poisoned all of our mediocre backup strategy back then.

OK, good for you. So, you will lose only one day's work due to faulty filesystem. Is it OK?

No, you're doing it wrong:

1. Copy everything that can be salvaged (if it's not in your daily backups).
2. Find the root cause of the transid missmatches.
3. FIX that root cause.
4. Then reformat and restore.

It's basic troubleshooting.

Are you trolling? First and last step would take a day. Second and third require knowledge of btrfs voodoo.

Why you assume it's just a "minor FS corruption"? If several generations were lost to a bad cache device then it's a major FS corruption.

Because it has happened after several (about 5) boot-time freezes, which cause I know (videocard). How much data can be corrupted during failed boot?

I still don't get why you think that data loss because of faulty hardware could be blame on a tool that tries to fix what isn't there.

Indeed I had a faulty hardware: the videocard. Do btrfs require a videocard to function? Almost all hardware didn't change since, I've only replaced HDD because i had to buy a new one to copy what can be salvaged and don't want to copy everything two times.

Another reason I think it is btrfs check fault is that if you run btrfs check --repair you will see a big warning about this tool. So, even assuming there was a coincidence, some another hardware (MB, SSD, HDD) was faulty and then somehow had fixed itself, why btrfs developers advise against using repair tool? Maybe because they know it can't fix anything?

It's stated in the fricking manpage what kind of errors it can solve effectively and then give you a big warning not to use it indiscriminately.

Sure, I should have read a manpage before creating a btrfs partition. Unfortunately, I haven't read it, shame on me, I assumed "better fs" with atomic operations, COW and checksumming is more robust than usual ext4.

fsck only tries to repair the consistency of the filesystem and it gives you no guarantees of what it reconstructs (why do you think there's a folder called lost+found?), why do you rely more on that? That the stack somewhat failed to write something and it didn't error'd as it's supposed to is a MAJOR issue. Actually, it's a stop-gap issue because it will happen again; any other regular FS is oblivious to that usually.

I repeat: it had removed many files during fsck. And it failed to restore consistency, I've got readonly mode on next boot. That is how it was. You are using same strawman argument again and again, assuming data was somehow lost and I wanted it magically restored. No. I wanted only consistent filesystem and I've got removed files instead.

They accumulated expertise in another solution before btrfs had gone production ready. SUSE, Facebook, Western Digital and Oracle took another path. What was your point again?

My point is: btrfs is a garbage. I know this. Redhat know this. Btrfs developers know this. Even you know this because you keep suggesting copy/reformat/restore. I warn other people against using it. Unfortunately it is impossible to throw it out of kernel now and replace with something decent, but at least more distros can advise against it during install.

[Khrundel]

Facebook, Western Digital and Oracle took another path. What was your point again?

And please, stop posting this nonsense.
Facebook uses X is not a valid argument. Facebook is a big company, they can use anything. They can use some DOS machines for something.
And their usage of btrfs doesn't mean btrfs is in good shape. They may know about it is faulty and still use it with care. For example they can use multiple devices btrfs for quick and painless adding of space to VMs, while using some external solution to ensure data integrity.

Btrfs deserves it's bad reputation.

[Mario Junior]

• Compression
  
  Done - LZ4, gzip and ZSTD are currently supported. ZSTD support unfortunately still seems to be slightly buggy, but LZ4 is stable and well tested.

[lowflyer]

The name "Bachefs" rings in my ears as something like kitchen, restaurants and Gordon Ramsey. I'm sorry I can't fix that.

And I doubt that any --repair option will ever be able to help here

[flower]

• Compression
  
  Done - LZ4, gzip and ZSTD are currently supported. ZSTD support unfortunately still seems to be slightly buggy, but LZ4 is stable and well tested.

The last update on that site was Tue Dec 4 08:07:29 2018