Announcement

Collapse
No announcement yet.

RAID 5/6 Support Finally Comes To Btrfs

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

  • RAID 5/6 Support Finally Comes To Btrfs

    Phoronix: RAID 5/6 Support Finally Comes To Btrfs

    It's been a long time coming, but the Btrfs file-system now finally supports RAID 5 and RAID 6 configurations for the next-generation Linux file-system...

    http://www.phoronix.com/vr.php?view=MTI5Mjc

  • #2
    I think you overuse the verb "finally" [1]. It sounds impatient and in it's overuse it sounds like a little child is begging and nagging for something until it gets it. Just leave it out and the articles gain quality. Less is more.

    [1] https://www.google.com/search?q=phoronix+finally

    Comment


    • #3
      Considering the glacial pace of btrfs development, the word "finally" is certainly apt in this case.

      Comment


      • #4
        What do we gain from this? btrfs RAID doesn't work quite like ordinary RAID, so btrfs RAID1 doesn't have the two-disk limitation that ordinary RAID1 does. Does this allow for increased performance?

        Comment


        • #5
          RAID 1 is simple mirroring and wastes space compared to RAID 5: http://en.wikipedia.org/wiki/Raid_5#RAID_5

          When I worked for Sun's storage division, RAID 5 was wildly popular. Unfortunately, zfs hadn't really caught on yet (would have made my life a lot easier).

          Comment


          • #6
            Originally posted by waucka View Post
            What do we gain from this? btrfs RAID doesn't work quite like ordinary RAID, so btrfs RAID1 doesn't have the two-disk limitation that ordinary RAID1 does. Does this allow for increased performance?
            RAID 1 has no two disk limitation. It appears that btrfs does from Chris Mason's email. You can read It for performance information.

            With that said, Chris claims to have implemented a LRU stripe cache. That would imply double buffering with the Linux disk cache, which wastes memory. He also says that this is a clone of what md raid already does, which implies that it suffers from the RAID write hole. It also means that the md raid code is being duplicated, which is generally a bad thing for maintainability.

            Comment


            • #7
              Originally posted by waucka View Post
              What do we gain from this? btrfs RAID doesn't work quite like ordinary RAID, so btrfs RAID1 doesn't have the two-disk limitation that ordinary RAID1 does. Does this allow for increased performance?
              The most important advantage of btrfs/zfs raid is that the filesystem checksums allow it to work out which set of data is the correct one when there is some corruption (as opposed to a full-on disk failure), unlike normal raid-1 or 5.

              Comment


              • #8
                But what about RAID7 (like raidz3 in zfs) and support for ditto blocks?

                Comment


                • #9
                  Originally posted by waucka View Post
                  What do we gain from this? btrfs RAID doesn't work quite like ordinary RAID, so btrfs RAID1 doesn't have the two-disk limitation that ordinary RAID1 does. Does this allow for increased performance?
                  * Planned support for N-way mirroring (triple mirror raid1) isn't
                  included yet.

                  From my understanding the benefit of BTRFS RAID is that is is object-level raid so there are no 1 week rebuilds after the 10TB stack blows a disk, only the lost files are written out somewhere safe.
                  Last edited by varikonniemi; 02-05-2013, 03:52 AM.

                  Comment


                  • #10
                    I'm really looking forward to when this hits mainline. I don't know if this was stated yet, but another advantage of file system aware RAID like btrfs is potentially faster scrubbing. You only need to scrub the blocks that are occupied by file data, which is awesome for massive arrays. Another advantage to btrfs raid is that it's super easy to mount. You can just mount whichever disk you want in the array, and the entire array is assembled automatically. This can certainly have its uses.

                    Comment


                    • #11
                      Have also looked forward to this, itīs one of the major features that have been missing.
                      This together with Btrfs ability to change RAID levels, add new disks to an existing array on-the-fly and rebalance is really nice. Here Btrfs has a real edge over ZFS which is very static once created.
                      According to the Btrfs FAQ there are also plans for per-subvolume and per-file RAID levels which will become handy in some cases

                      Comment


                      • #12
                        Originally posted by ryao View Post
                        RAID 1 has no two disk limitation. It appears that btrfs does from Chris Mason's email. You can read It for performance information.

                        With that said, Chris claims to have implemented a LRU stripe cache. That would imply double buffering with the Linux disk cache, which wastes memory. He also says that this is a clone of what md raid already does, which implies that it suffers from the RAID write hole. It also means that the md raid code is being duplicated, which is generally a bad thing for maintainability.
                        I looks like I was a little unclear here. (And a little mistaken!) With ordinary RAID1, every disk in the system is a copy of the others. I had been given the impression that btrfs RAID1 just means "put everything in two places". So, on my system with btrfs RAID1, my four 2TB drives would give me 4TB of storage, while ordinary RAID1 (assuming I found an implementation that would accept more than two disks) would only give me 2TB. However, a check with "btrfs filesystem df" tells me that I only have 1.30 TB of space! Crap. Well, at least btrfs's flexibility should let me easily switch to RAID5 or RAID6 in the future.

                        Also, given that the performance test results were just sitting there in the email, they really should have been included in the article. I'm a bit disappointed, though, that Chris only compared btrfs RAID to MD RAID. I would have liked to see btrfs RAID1 compared to btrfs RAID5/6.

                        Comment


                        • #13
                          Originally posted by axero View Post
                          But what about RAID7 (like raidz3 in zfs) and support for ditto blocks?
                          RAID 7 is not a standard RAID level. As for ditto blocks, I was told by the btrfs developers that they already have something equivalent to ditto blocks. btrfs also lets people turn them off, which makes btrfs' disk format vulnerable to ghost writes.

                          Originally posted by benmoran View Post
                          I'm really looking forward to when this hits mainline. I don't know if this was stated yet, but another advantage of file system aware RAID like btrfs is potentially faster scrubbing. You only need to scrub the blocks that are occupied by file data, which is awesome for massive arrays. Another advantage to btrfs raid is that it's super easy to mount. You can just mount whichever disk you want in the array, and the entire array is assembled automatically. This can certainly have its uses.
                          Scrubs should verify both data and parity. Otherwise, you can have inconsistent parity that would cause failed rebuilds following disk failures.

                          Originally posted by LasseKongo View Post
                          Have also looked forward to this, itīs one of the major features that have been missing.
                          This together with Btrfs ability to change RAID levels, add new disks to an existing array on-the-fly and rebalance is really nice. Here Btrfs has a real edge over ZFS which is very static once created.
                          According to the Btrfs FAQ there are also plans for per-subvolume and per-file RAID levels which will become handy in some cases
                          I would say that ZFS has an edge. Performance is more important than the ability to reshape. ZFS's raidz is immune to the RAID write hole. That gives ZFS a considerable performance advantage over both software and hardware RAID 5/6. btrfs raid 5/6 might outperform MD RAID 5/6 in benchmarks, but btrfs RAID 5/6 will still incur a performance penalty from the RAID write hole. What you gain in the ability to reshape with btrfs, you lose in performance. You feel performance throughout the time that a system is deployed, while reshaping is incredibly rare.

                          Comment


                          • #14
                            Originally posted by ryao View Post
                            RAID 7 is not a standard RAID level. As for ditto blocks, I was told by the btrfs developers that they already have something equivalent to ditto blocks. btrfs also lets people turn them off, which makes btrfs' disk format vulnerable to ghost writes.
                            Yes, RAID7 is not a standard RAID level. I just made it up to denote a RAID level with block-level striping with triple distributed parity instead of double distributed parity as with RAID6. ZFS implements this kind of parity in raidz3 which yields a fault tolerance of up to three failed drives in a storage pool. If ZFS can implement it without a hitch then so can btrfs.

                            To be honest, I can't see why anyone even would be interested in using RAID5 at all, especially when reading what's on the 'baarf.com' website. There is no sensible reason to go lower than at least a two drive fault tolerance when building a storage pool (or a disk array if you will), disk drives are really not that expensive. So, RAID6 or "RAID7" is way more desirable.

                            I'm not sure if ditto blocks is the *only* way to protect against "ghost writes" or even should be necessary to use on e.g. a raidzn or a fully mirrored storage pool for full protection against silent corruption. But for disk pools where you don't use any type of RAID (e.g. the system pool or rpool), ditto blocks have turned out to be invaluable. So if you don't want to say, mirror your system pool then ditto blocks is a viable option if you want at least some level of protection.

                            Comment


                            • #15
                              I wonder what will be the real-life performance compared to MD5/6+LVM+ext4?
                              EDIT: Bad hair day. Failed to notice the benchmarks in the end of the mailing list message....

                              - Gilboa
                              DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                              SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                              BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                              LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                              Comment

                              Working...
                              X