Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

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

  1. #21
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,877

    Default

    Quote Originally Posted by juxtatux View Post
    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.

  2. #22
    Join Date
    Feb 2010
    Posts
    28

    Default

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

  3. #23
    Join Date
    Nov 2011
    Posts
    268

    Default

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

  4. #24
    Join Date
    Feb 2010
    Posts
    28

    Default

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

  5. #25
    Join Date
    Nov 2011
    Posts
    268

    Default

    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 at 10:46 PM.

  6. #26
    Join Date
    Feb 2010
    Posts
    28

    Default

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

  7. #27
    Join Date
    Feb 2010
    Posts
    28

    Default

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

  8. #28
    Join Date
    Apr 2013
    Posts
    1

    Default 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!

Posting Permissions

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