Slashdot Mirror
Benchmark Madness
Guillem Cantallops Ramis writes: "In Bulma (Balearic Islands LUG) we've done real benchmarks this time: Mongo benchmarks (designed by Hans Reiser and used to test ReiserFS, slightly modified by me to support XFS and JFS), kernel compilation benchmarks, and a small "database simulation" benchmark. You'll find everything in english this time, with benchmark results and interesting comments by Dr. Ricardo Galli (Universitat de les Illes Balears, UIB). Have fun... and switch to a journaled filesystem now!" The previous article was here.
One advantage that ReiserFS and XFS are supposed to hold over ext2fs and other ufs based filesystems is the directory lookup time on directories with moderate to moderatly large numbers of files (1 million to 10 million or so). Does anybody know of any benchmarks available on the net that can backup this claim? If you want to test it yourself, you can look into Postmark which is easy to compile and simulates a heavily loaded mail or news server.
Unfortunatly the primary site appears to be down (I just downloaded the file a couple of days ago!), but if it comes back the primary distribution site is: http://www.netapp.com/ftp/postmark-1_13.c
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
It's comparing how well these different filesystems can compile a kernel. Do these tests tell you how well ext2, reiserfs, xfs will be able to serve up dynamic php/mysql content on an apache server? Hell no. Use apache's bench mark stuff for that on a controlled network, controlled machines, reboot between tests to eliminate caching, etc. But that's another can of worms. Please don't try reading more into the results than what's given to you.
---
Yah, those worthless little things; faster recovery, preserving data and faster boot-ups.
--
Linux O Muerte!
Because the availability of the data in the Linux cache may affect the time measured for cp -a, I repeated the command a couple of times before doing the real measurements (there was a huge variance with the first time).
I don't know that much about benchmarking. But this statement seems a little off. If there is data in the cache then the disk is not being tested on the reads. Its seems like the first time running is by far the most accurate because no data is in memory. However you have to ensure that the no data is in memory for all tests. This seems fairly easy to reproduce by rebooting and performing the same set of commands at startup to run the tests.
---
Oops, it's not yet in the standard kernel. Oops, the patches don't apply against the latest, most debugged versions of the kernel. Not, it's not time to switch now. I'll stay with stable and standard functions, thanks
... Quota support ... Kernel automounter support ... Kernel automounter version 4 support (also supports v3) ... Reiserfs support.
Let me check menuconfig on what I got from kernel.org... okay, Linux Kernel v2.4.4 Configuration: File systems
It is in the latest stable kernel.
Softupdates can guartantee consistency in case of crashes, thus providing save yet asynchronous-like performance (i.e. optimal performance).
Details are explained on the website of the author, Kirk McKusick. Also you can find a link there which leads to an interesting (technical) comparison of logging (aka journalling) versus softupdates.
I wish someone would port softupdates to linux (ext2fs). Or better yet, make BSD's FFS+softupdates a native Linux filesystem. It would surely outperform the other currently available filesystems. At least on my computer, when I benchmark FreeBSD+FFS+softupdates against Linux+ext2fs/reiserfs (on the same hardware, disk, disklocation) FFS+softupdates consistently wins hands down. I don't think this is because of FreeBSD's kernel, but rather because of softupdates (and FFS with it's large blocksize combined with smaller fragments to avoid too much slack).
Benchmarks? Compiling the kernel to benchmark a filesystem? Hmmm. Sorry but, No. How about that "real-world" random write program? Give me a break people. These are not valid benchmarks which was clearly stated the first time this story was posted. Why /. seems to think it's interesting is beyond me.
Someone you trust is one of us.
ok, i can kinda see a kernel compile cause of all the io but what ever happened to good old find and grep. Certainly they could have come up with some better tests.
find / |grep blah
SEE, now that's alot of IO
"...through this door all my dreams come realities, and all my realities become dreams..."
I beg to differ, write cacheing is normally ENABLED by default. If the drive was in full sync, then your performance would be complete crap. Everytime you did anything you'd have to wait for the data to get destaged onto the drive (very painful).
Do a "dd if=/dev/zero of=./file.test", wait a bit and break out of it (you could also do a rm -rf on a larger directory with lots of files). It will spit out how much it has supposedly written out to the drive, then quickly do a sync, you'll have to wait a bit while the data gets out of cache. The more memory you have the more pronounced this becomes, the sync destages the data to the drive from write cache. My box with 2gig of ram "supposedly" wrote ~500mb out to a single drive in just about 5 seconds... until I typed sync.
Who does Mr. Galli thinks he's fooling. I mean, come on ...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Wow. Does this mean it can handle SQL Server? That's always been my favourite database simulator.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The only advantage the new FSes hold is probably their journaling capability, leading to faster fscks, faster bootups and less risk of data loss. Did we really need a new set of filesystems for that? ( BSD Soft Updates show that the whole speed and reliability advantage can be had with old filesystems as well!) Where's the advantage? Where's the progress? The benchmarks only leave me disappointed.
There is absolutely no reason to panic.