Announcement

Collapse
No announcement yet.

ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

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

  • #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; 26 April 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


            • #16
              Originally posted by juxtatux View Post
              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.
              If by "beetrive" you mean "B-tree" (which is the only thing I can think of), you're missing something...ext* uses B-trees or H-trees (a variant of B-trees), and B(e)FS, JFS, NTFS, XFS, and ReiserFS use B+ trees, HFS+ uses B-trees...
              And btrfs is Oracle-RedHat, not Canonical.

              Comment


              • #17
                Originally posted by Ibidem View Post
                If by "beetrive" you mean "B-tree" (which is the only thing I can think of), you're missing something...ext* uses B-trees or H-trees (a variant of B-trees), and B(e)FS, JFS, NTFS, XFS, and ReiserFS use B+ trees, HFS+ uses B-trees...
                And btrfs is Oracle-RedHat, not Canonical.
                Yeah, I meant Btree, beetrive is an old joke...the algorithm isn't perfect enough to pivot a whole FS around. There are flaws when it scales. It's suitable for compression, which is why the other FS incorporate it. BUT as with any compression, things get lost, especially in scale. B-tree doesn't fractal correctly, and is not trust worthy for anything that needs long-term, or rapid transactional i/o. To use it for / root where things in a production environment are static and replaceable in case of failure, OK... but other than that I can only see btrfs as academic and *cute*. And I know Oracle *free the code Sun!* is the main development behind btrfs. But it was Canonical who was pushing for it out as / root 1st... SuSE newer releases added it as an option too. I just don't trust it for any thing like /home /var or more important /usr.

                Comment


                • #18
                  Originally posted by juxtatux View Post
                  . And I know Oracle *free the code Sun!* is the main development behind btrfs. But it was Canonical who was pushing for it out as / root 1st... SuSE newer releases added it as an option too. I just don't trust it for any thing like /home /var or more important /usr.
                  There isn't a single tier 1 or tier 2 distro on the planet that is using BTRFS by default for either Root OR Home. SUSE says it is now "Production ready" on their enterprise distro but does not default to it. So I dont have CLUE where you heard that Canonical made it default for /
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    Originally posted by Ericg View Post
                    There isn't a single tier 1 or tier 2 distro on the planet that is using BTRFS by default for either Root OR Home. SUSE says it is now "Production ready" on their enterprise distro but does not default to it. So I dont have CLUE where you heard that Canonical made it default for /
                    Ummmm.... I never said default... I said Canonical was pushing for it as default for / root. And I read it on phoronix...

                    Dude... You need to read my post, we are in accord. If you had read it, you would have noticed how I stated (with some backup) how and why I DO NOT believe in a B-Tree centric file system... sigh, things get non-beetrivable after awhile.

                    Comment


                    • #20
                      Originally posted by juxtatux View Post
                      Ummmm.... I never said default... I said Canonical was pushing for it as default for / root. And I read it on phoronix...

                      Dude... You need to read my post, we are in accord. If you had read it, you would have noticed how I stated (with some backup) how and why I DO NOT believe in a B-Tree centric file system... sigh, things get non-beetrivable after awhile.
                      Well yeah everyone is PUSHING for it to be the default on /, because everyone WANTS it to be the default on /. As far as you other points...

                      1) Links to papers explaining why B-Trees and B-Tree+ filesystems dont work? Serious academic papers, not blog posts by random people.
                      2) Btrfs uses a modified B-Tree system, its not 100% stock "standard" B-Trees so if there ARE an inherit flaws to B-Trees, Btrfs may work around them.
                      All opinions are my own not those of my employer if you know who they are.

                      Comment

                      Working...
                      X