Bcachefs Prepares Last Minute Fixes For Linux 6.7

[EmanuC]

Agreed 100%, but when you mention data security... Bcachefs and ZFS have native encryption, Btrfs is still lacking in that area.

is coming: https://lore.kernel.org/linux-btrfs/...oxicpanda.com/

[evert_mouw]

is coming: https://lore.kernel.org/linux-btrfs/...oxicpanda.com/

Yes, fscrypt support (not purely native but close enough), years after even ext4 got it, while Bcachefs already has native encryption. Don't get me wrong, great to see fscrypt support emerging for Btrfs, but it clearly was not high on the priority list.

[flower]

Seems like there still is a lot to fix, but also the speed of fixing seems high. Give it yet another year and Btrfs has real competition. (I don't expect the ZFS userbase to switch, but in-kernel support might convince a few.)

well... i will switch from zfs to bcachefs. but i'll wait until its no longer experimental before i start testing it for my use case

[EmanuC]

Yes, fscrypt support (not purely native but close enough).

Can you explain better?

Correct me if I'm wrong, but bcachefs encryption is for the entire device or you encrypt all or nothing.
With encryption coming to Btrfs with fscrypt you can encrypt individual subvolumes, you can encrypt each user's home.

[evert_mouw]

Can you explain better?

Correct me if I'm wrong, but bcachefs encryption is for the entire device or you encrypt all or nothing.
With encryption coming to Btrfs with fscrypt you can encrypt individual subvolumes, you can encrypt each user's home.

You are correct. I consider whole-filesystem encryption as limiting, except when done like ZFS when filesystems are flexible inside a pool. That's a plus got Btrfs/fscrypt (more flexible).

https://bcachefs.org/Encryption/

[NobodyXu]

Agreed 100%, but when you mention data security... Bcachefs and ZFS have native encryption, Btrfs is still lacking in that area.

Thanks for correction, I meant data integrity but my brain works against me.

[waxhead]

I am biased towards btrfs and i would like to challenge the btrfs haters to come up with whats actually wrong with btrfs.

Yes it is slow for some things, "raid 5/6" should never have been added so early and it sucks that per subvolume data/metadata profiles are not yet possible. But that's is actually all luxury problems.

"Raid" 0/1/c2/c3 and 10 work great and do compare what your get (for free) with any other filesystem and see if you can beat features/reliability.

I wish bcachefs all the best, but there is no way I am switching. Remember that as bcache evolves, so do btrfs. Perhaps there will be a time when bcachefs is worth switching to, but for now and probably many years ahead btrfs is what I trust with my data.

[F.Ultra]

I am biased towards btrfs and i would like to challenge the btrfs haters to come up with whats actually wrong with btrfs.

Yes it is slow for some things, "raid 5/6" should never have been added so early and it sucks that per subvolume data/metadata profiles are not yet possible. But that's is actually all luxury problems.

"Raid" 0/1/c2/c3 and 10 work great and do compare what your get (for free) with any other filesystem and see if you can beat features/reliability.

I wish bcachefs all the best, but there is no way I am switching. Remember that as bcache evolves, so do btrfs. Perhaps there will be a time when bcachefs is worth switching to, but for now and probably many years ahead btrfs is what I trust with my data.

It would also be great if btrfs some day could do what ever it is that zfs is doing when detecting that something like a sql server is running on it so COW+checksumming can be still enabled without loosing performance.

Also I've been thinking about a delayed Raid c2, aka since one most likely are always using two similar drives from the same batch and with the same characteristics there is a huge chance that both will die quite close in time so I think there could be a benefit from a c2 type of raid 1 where the duplication is delayed (and for SSD:s also batched/deduped) so the drives would experience a large difference in the number of writes.

[Mitch]

For a good while, I'll be using BCacheFS for my tiered gaming array, BTRFS for my OS install drive on my computers and laptops, and ZFS for my NAS.

I just don't feel the need to use just one FS for everything, but if I had to get rid of one, it's ZFS due to the lack of inclusion in the kernel. Even then, I might just move my NAS to Debian so that it's not a huge issue keeping the NAS software in a good place.

They're all COW and operate on many similar principles. Just different features, priorities, and years of maturity. All great filesystems in my view.

If one of them has a big feature missing though, I think BCacheFS scrub and self-healing would be the biggest. Not a huge issue for what I'm going to use it for, but that's not ideal for some use cases. The ZFS version has saved my bacon plenty of times. I think Kent has scrub and healing on his list to tackle.

[cynic]

since one most likely are always using two similar drives from the same batch and with the same characteristics there is a huge chance that both will die quite close in time

you shoudn't do that in first place, whatever the fs you're running on it.