An Exciting Btrfs Update With Encoded I/O, Fsync Performance Improvements

[RahulSundaram]

I've read the BTRFS documentation. They go into detail as to why you would even. I suggest you read it. TLDR: Just because they have similar features doesn't mean they have a perfect feature overlap or that features that they share work the same.

That FAQ is fairly generic advice that is applicable to any COW based filesystem. There are certainly implementation differences but nothing that would remotely warrant calling Btrfs or ZFS a next gen filesystem compared to the other. You should just acknowledge this and move on.

[cynic]

What's the status of BTRFS when it comes to:
- RAID 5 & 6 bug

not good

- Write Caching on separate disks
- Read Caching on separate disks
?

there was a discussion some time ago about that feature, and maybe some WIP but I haven't heard about it for a while, so don't think it is going forward.

anyway, there's a new pluggable policy that allows you to tell btrfs that some drives are faster and should be used for reads (also, you can telll btrfs to use them for metadata to increase performance). This could be mainlined in 5.19

[skeevy420]

ok, got it: you just wrote something that you cannot support with facts.

No, you asked a very broad question that's difficult to answer due to how great open source software is and how they have so much feature overlap that we're able to design our esoteric file system schemes. When you combine LUKS and LVM then nearly every file system is capable of almost every feature. Combine LUKS+LVM with advanced file systems like BTRFS, ZFS, and bcachefs and there's so much overlap in features I'd need at least a week to develop a feature matrix to even know where to get started.

With the things I do and my level of experience, there's next to nothing I can say that ZFS is capable of doing that can't be countered by a 1 2 3 combination from LUKS, LVM, & BTRFS. So like I said: you try.

If you want something simple that BTRFS can't do, like I said above, case insensitivity. For another, how about compression:

from "man zfsprops" -- compression=on|off|gzip|gzip-N|lz4|lzjb|zle|zstd|zstd-N|zstd-fast|zstd-fast-N

Btrfs supports transparent file compression. There are three algorithms available: ZLIB, LZO and ZSTD(since v4.14).

BTRFS only supports zstd-N in ZFS speak.

As you can see, not only does ZFS support more compression algorithms, it supports more options with available algorithms in regards to zstd-fast support.

That said, I could cherry pick from BTRFS and make the same damn arguments...seriously. Both Zlib and LZO stand out in that compression example . For something actually different, another one that BTRFS has is per file encryption whereas on ZFS you do it on a pool/dataset level. That's convenient if you only need $HOME/bank_records.txt encrypted. With ZFS you'd have to use a separate tool for the one file or put it into $POOL/$Encrypted_Dataset.

[cynic]

No, you asked a very broad question that's difficult to answer due to how great open source software is and how they have so much feature overlap that we're able to design our esoteric file system schemes. When you combine LUKS and LVM then nearly every file system is capable of almost every feature.

no, my question was very specific and I just asked for ONE scenario.

If you want something simple that BTRFS can't do, like I said above, case insensitivity. For another, how about compression:

from "man zfsprops" -- compression=on|off|gzip|gzip-N|lz4|lzjb|zle|zstd|zstd-N|zstd-fast|zstd-fast-N

BTRFS only supports zstd-N in ZFS speak.

As you can see, not only does ZFS support more compression algorithms, it supports more options with available algorithms in regards to zstd-fast support.

firstable, having more compression algorithm is different to say that there is something that you cannot do with btrfs. Second, how would LVM and LUKS solve it?

btrfs have a big overlapping set of features and some distinguishing ones.

Saying that to pair ZFS feature with btrfs you have to recur to LVM and LUKS is just plain FUD or fanboyism.

[Britoid]

All these fancy ZFS features that if you use on anything other than enterprise-level SSDs you'll get extreme amounts of tear.

BTRFS will likely never support raid5 or raid6 properly, it just doesn't fit well with its filesystem design. But btrfs raid is file level so you can use raid 1 with 4 drives with and get usable space and redundancy similar to raid 5.

[cjcox]

Except the elephant in the room: OpenZFS

While there are some feature differences, btrfs today and roadmap wise is going beyond current ZFS. Giving it the "nexter" crown is fine for now.

What ZFS has is maturity. May take a bit before btrfs has all the kinks worked out, even for features it has had for years now.

[portablenuke]

would you mind sharing an example of something you can do with ZFS that is not feasible with btrfs without using LUKS and LVM?

Things ZFS can do BTRFS can't: exporting space as a block device, parity RAID, convert a folder into a dataset, have nice tools.

ZFS has the ability to expose space in the pool as a block device. Creating an 8GB ZFS volume is analogous to creating an 8GB logical volume with LVM. BTRFS doesn't have this ability.

BTRFS is limited to RAID 1, RAID 10, or none. ZFS's RAIDZ can do parity striping across disks.

ZFS can convert an existing folder into a data set and back. BTRFS requires the normal "rename and swap directories" dance when creating a subvolume from a normal directory.

ZFS's tools cover the features nicely. BTRFS tools don't have everything covered. Specifically, qgroups are pretty raw.


Things BTRFS can do ZFS can't: shrink the pool, use the full space between non-symmetric disks.

ZFS pools are expected to grow, and the pool will allocate only as much space as the smallest disk even if the disk is larger.


I'm sure there is more, but these are big differences I've come across.

[evil_core]

Both BTRFS and ZFS are current gen, and the future belongs to BCacheFS!

It's the only tiered filesystem, that support fancy caching, encryption, erasure-coding, built-in volume-manager, etc.

[cynic]

Things ZFS can do BTRFS can't: exporting space as a block device, parity RAID, convert a folder into a dataset, have nice tools.

ZFS has the ability to expose space in the pool as a block device. Creating an 8GB ZFS volume is analogous to creating an 8GB logical volume with LVM. BTRFS doesn't have this ability.

BTRFS is limited to RAID 1, RAID 10, or none. ZFS's RAIDZ can do parity striping across disks.

ZFS can convert an existing folder into a data set and back. BTRFS requires the normal "rename and swap directories" dance when creating a subvolume from a normal directory.

ZFS's tools cover the features nicely. BTRFS tools don't have everything covered. Specifically, qgroups are pretty raw.


Things BTRFS can do ZFS can't: shrink the pool, use the full space between non-symmetric disks.

ZFS pools are expected to grow, and the pool will allocate only as much space as the smallest disk even if the disk is larger.


I'm sure there is more, but these are big differences I've come across.

nice, thanks for the answer!

another thing that btrfs can do and ZFS can't (i belive) is change the redundancy level on the fly.

[F.Ultra]

All these fancy ZFS features that if you use on anything other than enterprise-level SSDs you'll get extreme amounts of tear.

BTRFS will likely never support raid5 or raid6 properly, it just doesn't fit well with its filesystem design. But btrfs raid is file level so you can use raid 1 with 4 drives with and get usable space and redundancy similar to raid 5.

No you cannot, btrfs raid 1 requires 1 copy of each file so your available space will always be 50%, with raid 5 you get disks-1 of available space.