ZFS vs. EXT4 On Linux Multi-Disk RAID Benchmarks

[Ericg]

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-2010-fractal-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.

[juxtatux]

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.

[Ibidem]

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?

[juxtatux]

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-2010-fractal-trees.pdf

http://www.pittsburgh.intel-research.net/people/gibbons/papers/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.

[Ibidem]

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.

[juxtatux]

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/Fractals/Iterations_in_the_complex_plane/Mandelbrot_set

Chill out people...

[juxtatux]

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.

[daduke]

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!