Looking at reiser4 [LWN.net]

Looking at reiser4

Posted Aug 28, 2004 2:29 UTC (Sat) by sbergman27 (guest, #10767)
Parent article: Looking at reiser4

I've been following the "Reiser4 plugins" thread on the reiserfs mailing list and ran across a very interesting post by Nikita Danilov, namesys's "Senior Scientist" according to the "developers" page at namesys.

http://tinyurl.com/63uys

It seems that Hans is being less than honest about reiser4's performance. The phases of the mongo benchmark in which reiser4 performs poorly were simply excluded from the test, by order of Hans Reiser. (To see those results, go to namesys.com's front page and click on : "Reiser4 is the fastest filesystem and here are the benchmarks."

I just ran a preliminary mongo test on my own, rather average hardware, using the parameters from the 1st mongo test listed, and sure enough, ext3 (no htree, date=order) beats reiser4 handily in all 3 phases that were skipped in the publicized benchmark. (Although Nikita only mentions OVERWRITE and MODIFY, APPEND is also excluded.)

In the APPEND phase, ext3 is 2.75 times faster than reiser4. In fact, adding all the wall clock times together, ext3 handily beats reiser4 by 22% on THE WHOLE benchmark. No wonder Hans wanted that information suppressed.

Makes one wonder just how much Hans' assertions can be trusted.

The kernel developers are wise to insist that reiser4's code go through "the usual process" before being included in the Linus vanilla kernel.

(Log in to post comments)

Looking at reiser4

Posted Aug 30, 2004 5:49 UTC (Mon) by hansreiser (guest, #24323) [Link]

Nikita is no longer the senior scientist, he went to work for a competitor before making his remarks.

You might want to look at the followups to Nikita's remarks. There was more honest disagreement about the design and significance of those phases than he portrayed. Those phases were not in the benchmark that I wrote originally, and I think a lot more work needed to be done for those phases to be properly done. It is however true that they reflect an area where reiser4 allocation policies need more work, and why we need to finish the online repacker. We should have invested more time into that aspect of the benchmark, optimized for it a bit (it is quite improvable), made it more meaningful, and put it on the website. There are so many things we need to invest more time into....