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

  • #21
    What's the status of BTRFS when it comes to:
    - RAID 5 & 6 bug - Write Caching on separate disks
    - Read Caching on separate disks

    ?

    Comment


    • #22
      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.

      Comment


      • #23
        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

        Comment


        • #24
          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.

          Comment


          • #25
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                Comment


                • #28
                  Originally posted by skeevy420 View Post

                  Yes. My current ZFS zraid started off as a 1.5TB partition on a single 2TB HDD. The other 500GB was NTFS for Windows. When I quit dual booting around 2017 I gave the rest of the disk to ZFS. A few years later I bought a 4TB HDD and upgraded that to a mirror. A little bit later I bought a 2nd 4TB HDD and replaced my starting 2TB disk and finally had a 4TB mirror. Around that same time I bought a 4TB HDD for Windows because I was dual booting again. About a month or two ago I juggled data around and converted that mirror into a raidz with that 4TB HDD Windows was using (that's not an officially supported method and very dangerous).

                  As far as being rock solid and reliable for my data, I've been a happy camper using ZFS since around 2016. The only time I have issues is when the kernel upgrades faster than OpenZFS. My remedy is to run custom kernels and to simply not update until OpenZFS does -- can't accidentally update to an incompatible kernel if Pacman doesn't know where to get it. I'm currently doing that with Linux 5.16 and 5.17.

                  BTRFS I've always used for root and have been hit by GRUB and compression issues in the past. Sometimes it's from using esoteric setups and other times it's simply due to using a rolling release distribution and finding out a bug exists the hard way. Whatever the case may be, it has happened enough in the past 10 years that I've gone back to using Ext4 for my root volumes. Ext4 just works and I've never been hit by an issue so bad that a reinstall of the OS seemed like the easier fix.

                  If I was using a distribution like OpenSUSE I'd probably have much better BTRFS experiences.
                  Ok, so some more questions:
                  • Btrfs has online resize (partition's start is unchanged), but doesn't support efficiently moving a Btrfs partition on the same HDD/SSD to a different starting point on the storage device. What is ZFS's support for such operations?
                  • Both Btrfs and ZFS support snapshots, send and receive. Is ZFS implemented as "natively copy-on-write", or will ZFS use the copy-on-write policy only when needed?
                  • A problem with Btrfs is very high fragmentation of large database files, if CoW wasn't disabled when the db file was being created or there is a snapshot referring the db file. This accumulates up to 1 million fragments per 20GB of database data. It negatively impacts performance. What is the longtime fragmentation of databases in ZFS?

                  Comment


                  • #29
                    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?
                    ZFS supports using SSDs as caches for HDDs. The same can be achieved with bcache + btrfs/ext4/...

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X