Benchmarks from Guru Labs

Benchmarks from Guru Labs

[Michael Carmack]

I didn't see any mention of this in the archives. There are some
ReiserFS benchmarks at

    http://www.gurulabs.com/ext3-reiserfs.html

The first set of tests (for small files) show a significant performance
advantage with 'notail' turned on. Assuming disk space is not an issue,
are there any performance advantages to 'notail' that are not reflected
in these tests?

Also, can anyone comment on why Ext3 has a significant edge over ReiserFS
in the small-file tests, but the situation reverses as file-size 
increases? There's not much commentary in the article.

m.

Re: Benchmarks from Guru Labs

[Chris Mason]

On Thu, 2002-07-18 at 07:53, Michael Carmack wrote:
> 
> I didn't see any mention of this in the archives. There are some
> ReiserFS benchmarks at
> 
>     http://www.gurulabs.com/ext3-reiserfs.html
> 
> The first set of tests (for small files) show a significant performance
> advantage with 'notail' turned on. Assuming disk space is not an issue,
> are there any performance advantages to 'notail' that are not reflected
> in these tests?

notail is faster in most cases.  With some tail tuning, tails could be
faster for synchronous applications (like mail servers) when the file
size is <= blocksize.  This is because flushing the tail to disk would
be free with flushing the new inode information.

> 
> Also, can anyone comment on why Ext3 has a significant edge over ReiserFS
> in the small-file tests, but the situation reverses as file-size 
> increases? There's not much commentary in the article.

Getting good consistent results out of postmark is tricky.  Notice that
between the 2nd and 3rd tests, he changed 3 different postmark variables
(file size, number of files, number of transactions).

What I can say is that we've been doing performance fixes for reiserfs
for a while now, and some of them are really coming together.  Many will
go into 2.4.20-pre.

-chris

Re: Benchmarks from Guru Labs

[Chris Mason]

On Thu, 2002-07-18 at 08:42, Toby Dickenson wrote:
> On Thursday 18 Jul 2002 1:24 pm, Chris Mason wrote:
> 
> > notail is faster in most cases.  With some tail tuning, tails could be
> > faster for synchronous applications (like mail servers) when the file
> > size is <= blocksize.  This is because flushing the tail to disk would
> > be free with flushing the new inode information.
> 
> Is there any way to control the size of tails that get merged?
> 
> I have an application for which notail gives a performance increase, but I 
> also have a majority of files sized under 10 bytes, so notail is a big space 
> penalty
> 
> I suspect I _might_ be able to get a nice compomise if it was possible to 
> "tail" the tiny files, and "notail" the larger ones.
> 
> (alternatively, Im looking at two different filesystems, with one mounted 
> "notail")

At one point in time, there was a patch floating around that made this a
mount option (Nikita's?)  But right now all you can do is change the
STORE_TAIL_IN_UNFM macro in reiserfs_fs.h

There are really only two rules.  #1 you don't want a tail when the tail
size is zero.  #2 The tail can't be bigger than MAX_DIRECT_ITEM_LEN.

Something like this would only make tails for files < 4k in size (but
you should check my paren matching)  it should read

if (!n_tail_size || (n_tail_size > max_direct_item_len || 
                     n_file_size > n_block_size)
    return 1

#define STORE_TAIL_IN_UNFM(n_file_size,n_tail_size,n_block_size) \
(\
  (!(n_tail_size)) || \
  (((n_tail_size) > MAX_DIRECT_ITEM_LEN(n_block_size)) || \
   (n_file_size) >= (n_block_size)) \
)

-chris