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

  • #41
    It's going to be real fun to see the BTRFS reactions when OpenZFS lands the patchset for adding disks to a RAID-5/6 later this year.

    No only is RAID-5/6 terminally broken on BTRFS, but expansion has been probably the only real feature BTRFS has had over ZFS.

    At this rate somebody'll evolve RedoxFS into the next ZFS replacement and merge that into the kernel before BTRFS's RAID is usable. In other words: the end of the universe.

    Comment


    • #42
      Originally posted by Developer12 View Post
      It's going to be real fun to see the BTRFS reactions when OpenZFS lands the patchset for adding disks to a RAID-5/6 later this year.

      No only is RAID-5/6 terminally broken on BTRFS, but expansion has been probably the only real feature BTRFS has had over ZFS.

      At this rate somebody'll evolve RedoxFS into the next ZFS replacement and merge that into the kernel before BTRFS's RAID is usable. In other words: the end of the universe.
      Most of the anti ZFS posts in this thread read like Linus inspired pedantic dick waving that misses the forest for the trees. At the end of the day, ZFS is used for huge storage arrays of mission critical data in production. Nobody in their right mind would do that with BTRFS. I wouldn't even do that with the 8 disks in the old T630 sitting next to me. There's a reason even solutions targeted more at the SMB (not the protocol) space like Proxmox or TrueNAS SCALE use ZFS.

      This doesn't mean BTRFS is bad, it just doesn't handle this use case well at all, and storing lots of a data in a redundant / efficient way is an extremely important use case. BTRFS is great for root, I'm typing this on a Tumbleweed system and was glad when Fedora made it the default. But claiming that ZFS doesn't do anything important that BTRFS can't do is just asinine.

      Comment


      • #43
        Originally posted by Developer12 View Post
        It's going to be real fun to see the BTRFS reactions when OpenZFS lands the patchset for adding disks to a RAID-5/6 later this year.

        No only is RAID-5/6 terminally broken on BTRFS, but expansion has been probably the only real feature BTRFS has had over ZFS.
        .
        When I asked in the other BTRFS thread, someone mentioned the extent tree v2 changes allow for RAID5/6 issues to be fixed (although the patches specific to RAID5/6 havent been submitted yet). In which case it isnt terminally broken. It would be good if someone can actually confirm this.

        Comment


        • #44
          Imagine there would be a btrfs news without someone telling you about zfs ;-)

          Comment


          • #45
            Originally posted by reza View Post
            skeevy420 and others: I'd like to know your setup for partitioning etc... You mentioned your root is EXT4 and you use ZFS for others. I'd appreciate if people can elaborate. Thanks!
            I'm a relative newcomer to ZFS (generally preferring more mature filesystems like ext4 or XFS) so am still finding my way, but on the systems I'm currently running ZFS (all two of them...) I use ext4 for /root and /home, ZFS with RAID-Z1 on three SATA SSDs for "fast" data, RAID-Z1 or Z2 across either 4 or 6 high capacity HDDs for "slow" data. It's been well behaved enough that I will probably expand ZFS to a few other systems as time permits, and get more adventurous with what I do. It was incredible easy to set up and so far has coped with the one time I managed to run out of RAM (on an 1.5TB system... oops...) gracefully (read: I didn't lose any data).

            Comment


            • #46
              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.
              There absolutely is, it just doesn't have a fancy overhyped name. Linux had support for creating loop devices for ages.

              Comment


              • #47
                "The Btrfs VFS code now allows reflinks and deduplication from two different mounts of the same file-system"

                I can't believe it finally happened!
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #48
                  Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                  At the end of the day, ZFS is used for huge storage arrays of mission critical data in production. Nobody in their right mind would do that with BTRFS.
                  This is an incorrect assertion. https://btrfs.wiki.kernel.org/index....oduction_Users

                  Comment


                  • #49
                    Originally posted by intelfx View Post

                    There absolutely is, it just doesn't have a fancy overhyped name. Linux had support for creating loop devices for ages.
                    Loop devices are not even close to ZFS zvols in terms of the features offered. They aren't just exposing a file as a device node. They are based on the ZFS DSL layer just like ZFS datasets, supporting nearly all of the properties you can set on datasets such as copies=n, compression, encryption, logbias etc. And being based on the DSL they support copy-on-write transactions just like dataset writes, so you can snapshot them, clone them, send/recv them etc., just like datasets. You can use them as the backing storage of virtual machines and then continuously and transparently snapshot them and offload the VM state while it's running, for example. Or clone it and fire up a new VM based on the old one, all while the old one is running. You can't do that with loopback devices.

                    Comment


                    • #50
                      Originally posted by rleigh View Post

                      Loop devices are not even close to ZFS zvols in terms of the features offered. They aren't just exposing a file as a device node. They are based on the ZFS DSL layer just like ZFS datasets, supporting nearly all of the properties you can set on datasets such as copies=n, compression, encryption, logbias etc. And being based on the DSL they support copy-on-write transactions just like dataset writes, so you can snapshot them, clone them, send/recv them etc., just like datasets. You can use them as the backing storage of virtual machines and then continuously and transparently snapshot them and offload the VM state while it's running, for example. Or clone it and fire up a new VM based on the old one, all while the old one is running. You can't do that with loopback devices.
                      Doesn't loopback device just act like a regular file?

                      Thus, the compression is applied as usual, same for CoW.

                      As for file cloning, you can do that using cp reflink.

                      Comment

                      Working...
                      X