Announcement

Collapse
No announcement yet.

ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

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

  • #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 /

        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.

            Comment


            • #21
              Originally posted by juxtatux
              Douche... How can you Agree with me that it's inferior then demand proof FROM ME for YOUr argument?

              I mean seriously...I've been AWFK, but this took me 1 min on google.

              http://tokutek.com/downloads/mysqluc...ctal-trees.pdf
              http://www.pittsburgh.intel-research.../fpbptrees.pdf - *PAGE 4* CMU - BELL *FREAKING* LABS - IBM

              THE ALGORITHM IS NOT READY FOR PRIME TIME...*Troll* It's freaking academic, & *CUTE* (like yourself), It looks neater than it really is (like yourself).

              "btrfs still needs to bake." - Phoronix
              1) You just got yourself reported... Seriously, the little kids on Phoronix are getting old.
              2) I never agreed with you that it was inferior. In fact, personal experience says the Btrfs is very stable and very usable and reliable on systems. Currently using it as the filesystem for my home file server / linux test machine, and im planning on using it on my laptop. I demanded proof because YOU said it was inferior and I wanted to see the basis of your claims.

              Comment


              • #22
                Originally posted by Ericg View Post
                1) You just got yourself reported... Seriously, the little kids on Phoronix are getting old.
                2) I never agreed with you that it was inferior. In fact, personal experience says the Btrfs is very stable and very usable and reliable on systems. Currently using it as the filesystem for my home file server / linux test machine, and im planning on using it on my laptop. I demanded proof because YOU said it was inferior and I wanted to see the basis of your claims.
                1)Awe...you...you...you ADMIN YOU... Was my language harsh? Cause now I'm all spring time fresh... does your mom know?

                2)These are OLD arguments... and ones that have not been addressed... good luck with your future roll out...let me guess 2TB?

                *at the risk of loosing my phoronix account, I'm going to bow out of this thread.

                Comment


                • #23
                  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.
                  What FS DO you believe in then? FAT, F2FS, or ZFS? Because IBM (JFS), SGI (XFS), Microsoft (NTFS), Apple (HFS+), NTT (NILFS), Nokia (UBIFS), Matthew Dillon (HAMMER), Reiser (ReiserFS), and Be, Inc. (BFS) ALL used B or B+ trees.
                  Basically, it's Sun and filesystems that are designed for low end systems that don't use B trees or a variant thereof. Notice how many of those filesystems are known to scale?

                  Comment


                  • #24
                    Originally posted by Ibidem View Post
                    What FS DO you believe in then? FAT, F2FS, or ZFS? Because IBM (JFS), SGI (XFS), Microsoft (NTFS), Apple (HFS+), NTT (NILFS), Nokia (UBIFS), Matthew Dillon (HAMMER), Reiser (ReiserFS), and Be, Inc. (BFS) ALL used B or B+ trees.
                    Basically, it's Sun and filesystems that are designed for low end systems that don't use B trees or a variant thereof. Notice how many of those filesystems are known to scale?
                    To sum it up in an acronym...

                    EXT ... it's magical...unlike a certain mid-summers night eve.

                    Dooshy got my post THAT HAD THE WHITE PAPER HE REQUESTED pulled, and *I SWEAR THIS IS MY LAST POST ADMIN!!!*

                    So please read this before you freaking *flame on* and get all acronym and name dropping crazy 'K?

                    B-Tree & B+-Tree DOESN'T FRACTAL
                    http://tokutek.com/downloads/mysqluc...ctal-trees.pdf
                    http://www.pittsburgh.intel-research.../fpbptrees.pdf

                    The white paper was written by CMU, Bell Labs, & IBM... btrfs still has issues contained with therein.
                    'K!

                    Please DO NOT expect any more replies...as I have been REPORTED! And am only replying out of courtesy.

                    Comment


                    • #25
                      ext3 uses hashed B trees, ext4 uses H trees, which are a variant of B trees. Ext2 is the last variant of ext* which didn't use B trees or some variant.
                      And the CMU/Bell/IBM paper describes "a new type of B+-Tree that optimizes both cache and I/O performance." (first sentence of Section 1.1). It's not saying that B trees and B+ trees don't work, it's saying that two existing categories of B+ trees can incur performance penalties, so here's a third variant of B+ trees ("fractal prefetching"/nested B+ trees of the first two types) that doesn't have that problem. That doesn't equate to what you're saying, and observation of real life (in which SGI and IBM use XFS and JFS, both B+ tree based, on _very_ large systems, and ext4 falls flat at the high end-one of the XFS developers had an interesting benchmark in a video, that illustrates this well) indicates that they do scale.
                      Last edited by Ibidem; 04-27-2013, 10:46 PM.

                      Comment


                      • #26
                        Originally posted by Ibidem View Post
                        ext3 uses hashed B trees, ext4 uses H trees, which are a variant of B trees. Ext2 is the last variant of ext* which didn't use B trees or some variant.
                        Alright, this is blown WAY out of proportion... My argument was FOR BENCHMARKING ***JOURNAL*** FS....

                        What got sidetracked, and I REFUSE TO RECANT, is B+Tree is just not suitable to CENTER , repeat, CENTER your FS around. It's neat math don't get me wrong, it's NOT mathy by any-means... BUT there are problems when the whole thing is B+-Tree. If there isn't then WHY aren't they rolling it out? And lets face it, it just isn't being rolled out.. BUT BY ALL MEANS USE B-Tree!! I use bcrypt and bzip out the wazz-ooo (wait? can I say wazoo?.. anyways) it's very neat at index, the MATH F=Sum(LOG N / LOG B), how can I say NEVER USE THAT! Of course it's IN there... BUT Ahhh us kids used to love to trip over cracks in the sidewalk... and man... when an EXT4 journal vomits because a hidden fractal spacial dimension emerging (*did I just hear angles crying?*) in the calculated spherical aerial density of the platters.. you recompile e2fsprogs & bug-eye migrate between two fresh partitions... only to find you have NO corrupted data and improved performance...well...I don't have a white paper for that one.

                        http://en.wikibooks.org/wiki/Fractal...Mandelbrot_set

                        Chill out people...

                        Comment


                        • #27
                          Originally posted by Ibidem View Post
                          ext3 uses hashed B trees, ext4 uses H trees, which are a variant of B trees. Ext2 is the last variant of ext* which didn't use B trees or some variant.
                          And the CMU/Bell/IBM paper describes "a new type of B+-Tree that optimizes both cache and I/O performance." (first sentence of Section 1.1). It's not saying that B trees and B+ trees don't work, it's saying that two existing categories of B+ trees can incur performance penalties, so here's a third variant of B+ trees ("fractal prefetching"/nested B+ trees of the first two types) that doesn't have that problem. That doesn't equate to what you're saying, and observation of real life (in which SGI and IBM use XFS and JFS, both B+ tree based, on _very_ large systems, and ext4 falls flat at the high end-one of the XFS developers had an interesting benchmark in a video, that illustrates this well) indicates that they do scale.
                          I dunno, real world caches overflows means that bits get lost. On intense transactional DB, that's life or death. Like I said prior, btrfs doesn't address these issues. I maybe wrong and I hate to misrepresent anyone...but Linus didn't trust b-tree for the longest time until it was proven... then bzip became delfacto. I'm not saying things don't or won't change, amend, meld or compromise but there's just something planer about disk i/o, that flat b-tree holds back.

                          Comment


                          • #28
                            FS blocks and RAID chunks alignment

                            Hi Mickael,
                            XFS VS ZFS would be a better starting point for disk benchmarks, ext4 defaults are not so good when it come to data alignment with the RAID chunks.
                            XFS is pretty good at getting correct stride and stripe values, while ext4 needs some efforts to specify the block size, stride and stripe_width. It can explain some bad performance on the mdadm implementation.
                            HW RAID, is the last test to do because here it is difficult to check blocks/chunks alignments.

                            Thank you for your site!

                            Comment

                            Working...
                            X