Benchmarking Linux Filesystems In New 2.6 Kernel

An anonymous reader writes "KernelTrap has an interesting article about a recent benchmark conducted to compare five journaling filesystems available with the current 2.6.0-test2 Linux development kernel. The tests were conducted with a very simple shell script, mainly timing how long it takes to copy, tar, and remove directories. Looks like reiser4 is the fastest filesystem at the expense of consuming much more CPU, with ext3 trailing a ways behind."

Comments

fs issues

[Tirel]

speed is nice, but I think the more important question is; how stable is it?

Re:Incomplete comparison?

[makapuf]

Except that if you have a mostly idle CPU and your task is more & more waiting for the disk to complete, you don't care about 11 or 30 % if the other 89 or 70 % of the CPU are idle.

Comparing CPU cycles needed is NOT a fair benckmark, unless your task is CPU _AND_ IO Bound.(if it's not io bound, take whatever fs you have, it doesn't matter.)

The benchmark was right in giving results as TWO parameters : CPU used and time spent. Might be interesting to see how it depends of the drive type or the CPU arch, though)

Stupid question

[Hard_Code]

Why do we need fast file systems? Or rather, why should we spend so much effort on performance differences of such small magnitude (take out reiser4 and its high cpu usage)? The only things I can think of are: swapping memory - this will really slow the system down, because disk is orders of magnitude slower than main memory; and databases that absolutely require high performance. But both of these typically *already* use custom file systems (or raw partitions) tailored to their exact needs. As normal user (somebody who is not constantly copying Mozilla source tries around), why should this matter? I can't remember the last time I thought "boy, this file access was slow, I wish I had a faster file system".