Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: RAID 5/6 Support Finally Comes To Btrfs

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,660

    Default 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. #2
    Join Date
    Apr 2011
    Posts
    35

    Default

    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

  3. #3
    Join Date
    Dec 2008
    Posts
    151

    Default

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

  4. #4
    Join Date
    Oct 2009
    Posts
    101

    Default

    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?

  5. #5
    Join Date
    Oct 2007
    Posts
    1,326

    Default

    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).

  6. #6

    Default

    Quote 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.

  7. #7
    Join Date
    Oct 2009
    Posts
    101

    Default

    Quote 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.

  8. #8
    Join Date
    Jun 2012
    Posts
    328

    Default

    Quote Originally Posted by ryao View Post
    with the Linux disk cache, which wastes memory.
    If I remember well, ZFS is even more memory hungry. Furthermore, it even does not really uses extents and as the result, overall filesystem design seems to be so slow that it could only perform reasonably well with gigabytes of memory buffers. Else it's getting painfully slow. And most tuning/install guides suggest not even to try ZFS without ~2Gb or so. Btrfs appears to be less problematic in this regard.

    He also says that this is a clone of what md raid already does, which implies that it suffers from the RAID write hole.
    I guess that if it would be really per-file or per-subvolume, this would be much less problem, especially in mixed/multithreaded/... environments.

    Alsi ability to reshape could be rarely used but you see, when you have to reshape many TiBs, it would be great option to have. Just because it's very troublesome operation otherwise. And btrfs seems to be really flexible when it comes to allocating things, one way or another. And Sun always preferred to publish far more of colorful marketing bullshit than actual design worth of. Sure, they had a business, but they've achieved that now I'm take their achievements with a grain of salt.

  9. #9
    Join Date
    Oct 2007
    Posts
    21

    Default

    Quote 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.

  10. #10
    Join Date
    Nov 2011
    Posts
    12

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •