Announcement

Collapse
No announcement yet.

ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

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

  • ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

    Phoronix: ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

    When dealing with multi-disk configurations and RAID, the ZFS file-system on Linux can begin to outperform EXT4 at least in some configurations...

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

  • #2
    Next up please, Michael, Ext4 LVM vs BTRFS Raid. With compression. Its the test we've been waiting on since whenever you do EXT4 you never do it overtop LVM and sometimes you forget to enable btrfs compression.

    Comment


    • #3
      And there you go...

      Comment


      • #4
        My XFS test (test1) across 8 x 1TB (Hitachi laptop 5K1000) RAID5 (Adaptec 52445)

        http://openbenchmarking.org/result/1...FO-1303116FO49

        Note, the 8 x 1TB are split across two ports of the Adaptec 52445 (4 drives on each).

        HW raid FTW... or maybe something else??

        (just for comparison purposes... why not put the whole disk benchmark set?.. noting that the testsuite failed to get some modules in my test1 case)

        Comment


        • #5
          Originally posted by Sergio View Post
          And there you go...
          Exactly. ZFS scales and ext4 not so much.

          Comment


          • #6
            BTRFS apologists proven wrong

            BTRFS apologists love to make excuses as to why BTRFS is slower than EXT4 by claiming that the more numerous features of BTRFS invariably yield slower function on bread-and-butter filesystem tasks. Well, take that! ZFS does more things and is faster than EXT4 at the same time! What excuses will they come up with now??

            Comment


            • #7
              Originally posted by stan View Post
              BTRFS apologists love to make excuses as to why BTRFS is slower than EXT4 by claiming that the more numerous features of BTRFS invariably yield slower function on bread-and-butter filesystem tasks. Well, take that! ZFS does more things and is faster than EXT4 at the same time! What excuses will they come up with now??
              Its not a matter of BTRFS apologists... We've requested numerous times that Michael do an EXT4 over LVM vs BTRFS raid benchmark because it IS a more fair benchmark. Btrfs handles everything as 'raid' even with one disk. Its just the nature of the filesystem, so no matter what it accounts for raid, therefore it IS more fair to benchmark it against similar raid. The REAL benchmark here would be

              ZFS vs Btrfs vs LVM+Ext4 with 2 disks each. That would the the REAL benchmark to see. Also are you really surprised that ZFS beat ext4? ZFS has had the crap optimized out of it. Pretty sure it even keeps the most used parts of the disk in memory rather than writing to disc... (Not the disc cache, actual RAM)

              Comment


              • #8
                Originally posted by stan View Post
                BTRFS apologists love to make excuses as to why BTRFS is slower than EXT4 by claiming that the more numerous features of BTRFS invariably yield slower function on bread-and-butter filesystem tasks. Well, take that! ZFS does more things and is faster than EXT4 at the same time! What excuses will they come up with now??
                You must have missed the part where this test was run on a server with 22 disks. Maybe btrfs would still be slower, or maybe it would be faster. I have no idea, and you don't either.

                Comment


                • #9
                  apples to oranges

                  so raid10 is faster than raid5
                  i'm unimpressed

                  Comment


                  • #10
                    I'd love to see the solution with luks encryption involved. I run my ssd's in raid1 for desktop and laptop use, with md, luks, and lvm carefully aligned atop 2 disks for system, but would love to see how this scales for sensitive data across many with the various fs layers involved how performance compares to mtbf with data sensitivity as a concern.

                    Comment


                    • #11
                      Originally posted by pal666 View Post
                      so raid10 is faster than raid5
                      i'm unimpressed
                      raid10 is expected to be faster than raid5 under a heavy read/write workload.

                      Comment


                      • #12
                        Originally posted by stan View Post
                        BTRFS apologists love to make excuses as to why BTRFS is slower than EXT4 by claiming that the more numerous features of BTRFS invariably yield slower function on bread-and-butter filesystem tasks. Well, take that! ZFS does more things and is faster than EXT4 at the same time! What excuses will they come up with now??
                        It seems you've missed the last benchmarks were zfs were just killed by Ext4. There's a big chance btrfs will perform better in benchmark using RAID.

                        Comment


                        • #13
                          What are the states of the boxes when running benchmarks? Are these seasoned installations or fresh? Are they vanelia? My understanding of a journal FS is that bit patterns are recognized over time and usage. A desktop vs. server. Streaming vs. Database vs. fileprint... The journal contains the file requirements & conditions itself, the bits thrown across the platters are random, and Hardware I/O addressing is modified for access time over usage patterns...In a word, heuristics...RAID performs this in HW.

                          I abandoned LVM for this reason, as EXT4 journal does a superior job with a flat /dev/sd* partion vs. LVM /dev/1TBdrive/root, /usr, /tmp, /var, etc. This is also why everything on YOUR EXT4 partition is YOUR data. It is unique to your installation and cannot be forensically differentiated as anything but unique, especially when its' extent & sources based.

                          So... ZFS being from oracle , can we assume that the journal heuristics algorithm is tuned for past paced SQL transactions or high-end workstation workloads? Where as EXT4 heuristics is multipurpose? I say that even with a binary distro RHEL, workloads & disk I/O need to be simulated to properly condition the journals... am I out of line? Or are we out of testing hardware?
                          Last edited by juxtatux; 04-26-2013, 05:18 PM.

                          Comment


                          • #14
                            Feature wise comparison

                            Well at least by comparing ZFS (with its RADIZ) to a EXT4+LVM+MDraid stack, it's on par regarding feature.

                            Now it would be nice to include BTRFS (as another modern filesystem with comparable features) in the mix....

                            EXT4 bare (as reference point), EXT4+LVM+MD raid (as a way to compare the same feature with an older FS - our "orange flavoured apple" :-P), ZFS (with all advanced features like RAIDZ), BTRFS (with also advanced features so we compare oranges to oranges).

                            Comment


                            • #15
                              Originally posted by DrYak View Post
                              Well at least by comparing ZFS (with its RADIZ) to a EXT4+LVM+MDraid stack, it's on par regarding feature.

                              Now it would be nice to include BTRFS (as another modern filesystem with comparable features) in the mix....

                              EXT4 bare (as reference point), EXT4+LVM+MD raid (as a way to compare the same feature with an older FS - our "orange flavoured apple" :-P), ZFS (with all advanced features like RAIDZ), BTRFS (with also advanced features so we compare oranges to oranges).
                              Yeah, I was hoping for a little more background representing the numbers. I feel the match up was worthy, btrfs isn't journal'd. Ext4 and ZFS do compete for platters in production, and personally, I would never trust a beetrive algorithm for a working FS, performance or no, it's just flawed Canonical.. But plain-jane file copies don't do the FS justice when comparing. Systems are getting HUGE in scale and it's really starting to show that real working experience in a system FS tunes more aspects that it used to. Especially with SAN being was it is, fiber-channel switching alongside with RAID produces STAGGERING amounts of heuristics... both ext4 and zfs treat that data different when assimilating it into working journals.

                              Comment

                              Working...
                              X