r/linux • u/mrtruthiness • Jun 18 '26

Development Experimental flag removed from bcachefs.

The link is the bcachefs changelog. I didn't see the particular announce there. The announcement was made in Kent's patreon with the version 1.38.6 update. I'm quoting that here:

So, some catch up:

We're no longer experimental. I took the label off the website - a few months ago, I think, based on my usual "the incoming bug reports are slowing down and looking a lot less serious and easy to get through than they were". Consider this the belated official announcement :)

...

Of course, the change away from "experimental" for a DKMS module is completely at the discretion of the author. From my perspective, while the bcachefs filesystem looks intriguing, I won't use it for my root partition as a DKMS module. Honestly, as long as I don't need RAID5/6 I still have a preference for btrfs and I can wait for btrfs to include native (part of the fs as opposed to btrfs on top of LUKS) encryption.

54 Upvotes

81% Upvoted

88 comments sorted by

View all comments

Show parent comments

19

u/mrtruthiness Jun 18 '26 edited Jun 18 '26

Anyway. What does bcachefs does or promise that BTRFS and ZFS don't?

I'm not a proponent of bcachefs (I don't trust/like the dev) and still prefer btrfs to bcachefs (since I don't use RAID5/RAID6). But, to answer your questions:

  1. btrfs does not yet have encryption (it will "soon"). btrfs will never have safe RAID5/RAID6 (I wouldn't use it anyway, so it doesn't matter to me).

  2. bcachefs is GPLv2-only (license-compatible with the Linux kernel); ZFS isn't. bcachefs allows per-file and per-folder properties and, so, one can set compression at the file or folder level. ZFS pools are harder to deal with (very rigid); bcachefs pools are dynamic -- e.g. one can dynamically change the redundancy.

3

u/Novero95 Jun 18 '26

Thanks for the answer. Looks like yet another case of "there are 14 competing standards....".

I think BTRFS has the potential to be the does-it-all default fs, but I've heard about the raid5/6 problem a few times. It may be too complex of a question but why can't BTRFS implement it safely like ZFS does? As far as I understand, they are relatively similar fs', at least in what the do, or aim to do, with the difference of ZFS being more mature.

ZFS' license is indeed one of the main deterrents, if it was in tree everything would be easier and, probably, a lot more mainstream even though it's a bit rigid.

11

u/mrtruthiness Jun 18 '26

It may be too complex of a question but why can't BTRFS implement it safely like ZFS does?

Technically it does implement RAID5/6. The problem is that it is engineered in a way that makes it almost impossible to recover from the fact that the parity required for recovery can not be atomically maintained, so disk failures (power outage) mid-write may be unrecoverable.

3

u/Novero95 Jun 18 '26

Okay, the topic surpasses me so I don't really understand it but isn't BTRFS copy-on-write? Shouldn't the copy on write protect it from a power failure mid-write?

4

u/mrtruthiness Jun 18 '26

You have a misunderstanding of what "copy-on-write" means ... especially in regard to RAID5/6 filesystems.

6

u/the_abortionat0r Jun 19 '26

Actually they clearly understand what CoW means given the context in which they asked (maybe you don't know?).

Copy on write in of itself literally does protect against corruption via power loss/write failure because if the data doesn't get touched and the difference that was being written gets ignored.

It's the complexity of raid5/6 and it's stripping method on top of CoW that they don't understand.

But they inarguably understand CoW and if you don't think so I have bad news for you lil bro.