Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • F.Ultra
    replied
    Originally posted by Britoid View Post
    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.

    Leave a comment:


  • cynic
    replied
    Originally posted by portablenuke View Post

    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.

    Leave a comment:


  • evil_core
    replied
    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.

    Leave a comment:


  • portablenuke
    replied
    Originally posted by cynic View Post

    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.

    Leave a comment:


  • cjcox
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • Britoid
    replied
    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.

    Leave a comment:


  • cynic
    replied
    Originally posted by skeevy420 View Post
    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.

    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by cynic View Post

    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.

    Leave a comment:


  • cynic
    replied
    Originally posted by zparihar View Post
    What's the status of BTRFS when it comes to:
    - RAID 5 & 6 bug
    not good

    Originally posted by zparihar View Post
    - 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

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:

Working...
X