# Reiser4, slower than Reiserfs? my benchs seem to proove it..

## borkdox

Hi,

I don't really know whats wrong, most of the bench I see around the forums and in namesys.org proove that reiser4 is way faster than Reiserfs. In the past weekend I decided to switch and enjoy the huge speed improovement. But for my amazement there was none, and even decrease. So i decided to do some testing in a empty 30GB(My hd is 160GB). I formatted the partition with reiser4, did some tests, then with reiserfs, and did some tests. Have repeaded this couple of time after changing kernel and version of libaal and reiser4progs, always getting a similar result.

Results:::

```

Reiser4:

[root@myhost gentoo]# time tar -xjf /usr/src/linux-2.6.6.tar.bz2 

real    0m31.718s

user    0m23.350s

sys     0m5.442s

ReiserFS:

[root@myhost gentoo]# time tar -xjf /usr/src/linux-2.6.6.tar.bz2 

real    0m28.182s

user    0m23.130s

sys     0m4.624s

----------------------------------------------------------------------

Reiser4:

[root@myhost gentoo]# time tar -xf /usr/src/linux-2.6.7-rc3.tar

real    0m6.167s

user    0m0.243s

sys     0m3.461s

ReiserFS:

[root@myhost gentoo]# time tar -xf /usr/src/linux-2.6.7-rc3.tar

real    0m4.266s

user    0m0.229s

sys     0m3.404s

-----------------------------------------------------------------------

Reiser4:

[root@myhost gentoo]# time tar -xf linux-2.6.7-rc3.tar

real    0m9.307s

user    0m0.222s

sys     0m3.680s

[root@myhost gentoo]# time rm -rf linux-2.6.7-rc3

real    0m7.234s

user    0m0.083s

sys     0m2.064s

ReiserFS:

[root@myhost gentoo]# time tar -xf linux-2.6.7-rc3.tar

real    0m21.259s

user    0m0.210s

sys     0m3.429s

[root@myhost gentoo]# time rm -rf linux-2.6.7-rc3

real    0m1.070s

user    0m0.014s

sys     0m1.013s

------------------------------------------------------------------------

Reiser4:

[root@myhost gentoo]# time tar -xjf linux-2.6.6.tar.bz2

real    0m31.661s

user    0m23.520s

sys     0m5.890s

[root@myhost gentoo]# time rm -rf linux-2.6.6

real    0m7.014s

user    0m0.076s

sys     0m2.071s

ReiserFS:

[root@myhost gentoo]# time tar -xjf linux-2.6.6.tar.bz2

real    0m28.761s

user    0m23.179s

sys     0m4.559s

[root@myhost gentoo]# time rm -rf linux-2.6.6

real    0m1.022s

user    0m0.025s

sys     0m0.976s

```

Bonnie++::

```

Reiser 4::                                 

                     Sequential output                 Sequential Input      Random   

       Per Ch        Block         Rewrite       Per Ch        Block         Seeks   

Size   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   /Sec   %CP

1G     13724   93    43296   16    23588   14    20297   94    44393   14    179.4   0

                                    

                                    

                                    

ReiserFS::                                 

                     Sequential output                 Sequential Input      Random   

       Per Ch        Block         Rewrite       Per Ch        Block         Seeks   

Size   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   K/Sec   %CP   /Sec   %CP

1G     14124   96    51434   25    21099   9     20527   95    42477   12    169     0

```

Specs(if more is needed tell me)::

Kernel 2.6.7-rc3-love1

Athlon XP 1800+

Soltek SL-75FRN2-L(Nforce 2)

512MB DDR PC2700

Maxtor 160GB 7200RPM 8MB (DiamondMax Plus 9)

Could anybody give me some tips, or a solution to this? 

Thanks   :Wink: 

----------

## codergeek42

You're not using the notail option, right?...

----------

## borkdox

 *codergeek42 wrote:*   

> You're not using the notail option, right?...

 

No, but I mounted the test partition with notail[Edit:noatime, I meant] and the results stood about the same...

EDIT--

Sorry I meant the noatime option instead of notail. No, I never mounted reiser4 with notail, mount won't let me mount the partition with that option.Last edited by borkdox on Mon Jun 14, 2004 11:59 pm; edited 1 time in total

----------

## stahlsau

seems you´re right. I did benches with iozone on my raid0 device with various filesystems, which proved that reiser4 was by far the slowest. JFS was best, right before XFS, which was a lil faster than ext2.

I have the results in an oo-calc-sheet with a nice diagram; if anyone likes to see, just pm me.

----------

## ryceck

 *codergeek42 wrote:*   

> You're not using the notail option, right?...

 

Does the notail option really make a large difference???

----------

## borkdox

 *ryceck wrote:*   

>  *codergeek42 wrote:*   You're not using the notail option, right?... 
> 
> Does the notail option really make a large difference???

 

As I tried to say in my last post, I don't think one can enable notail in reiser4. I tried, but it won't mount with "-o notail".

----------

## Jake

I did some benchmarks myself. Since I wasn't using my 1Gb of swap on my second hard drive, I used that partition to keep things as fair as possible. In all cases, the benchmark files were the only ones on the filesystems tested. I used the defualt kernel, mount, and mkfs options. My kernel is 2.6.6-love4, anticipatory IO scheduler (aka "the fast one"). All values are averages of 4 runs.

My "Tar" benchark is "tar xf file.tar", "Find" is "find dir >/dev/null", and "Rm" is "rm -r dir".

Reiser4 is slow for whatever reason but still competitive, R3 is great for kernel source (small files), XFS is good for 192kbps MP3s (large files) but not kernel source, and EXT2 is painfully slow for large files.

----------

## HumanPixel

You may be running with debugging enabled. Check it in your kernel.

----------

## evermind

```
                  reiserfs      reiser4

      

mount /dev/hdb7 /mnt/hdb7/

            real    0m2.229s   real    0m0.286s

            user    0m0.000s   user    0m0.000s

            sys     0m0.056s   sys     0m0.007s

        

cp /usr/portage/distfiles/linux-2.6.6.tar.bz2 /mnt/hdb7/   

            real    0m3.808s   real    0m3.102s

            user    0m0.002s   user    0m0.004s

            sys     0m0.440s   sys     0m0.360s

        

tar -xjpf linux-2.6.6.tar.bz2

            real    0m58.745s   real    1m6.643s

            user    0m47.981s   user    0m48.495s

            sys     0m6.8080s   sys     0m8.693s

        

rm -rf /mnt/hdb7/linux-2.6.6

            real    0m1.581s   real    0m11.988s

            user    0m0.040s   user    0m0.031s

            sys     0m1.464s   sys     0m3.010s

      

extract from /mnt/hdb7/linux-2.6.6.tar.bz2 to reiserfs

            real    2m16.272s   real    1m5.202s

            user    0m48.474s   user    0m48.082s

            sys     0m9.5800s   sys     0m7.459s

```

my reiser4quickbench  :Smile: 

just on mount, cp large files and read from reiser4 partition reiser4 is faster

----------

## samx

I did some similar tests like elocal and I got the same results (Reiser4 slightly slower on extracting the kernel sources and notably slower on deleting the kernel sources)  :Confused: 

But there is a discipline where Reiser4 seems to be much better!  :Very Happy: 

```
#tar -xjf linux-2.6.5-rc2.tar.bz2 (I only remark this for better understanding of the next line)

ReiserFS:

bash-2.05b# time tar -cf linuxtest linux-2.6.5-rc2

real 0m45.381s

user 0m0.236s

sys 0m2.125s

----------------

Reiser4:

bash-2.05b# time tar -cf linuxtest linux-2.6.5-rc2

real 0m22.332s

user 0m0.259s

sys 0m2.446s
```

I think this is a impressing difference! So I would say that Reiser4 has its pros and cons... 

Unfortunately, you can't really benchmark the stability of a fs (I think more stability for the price of a little performance is ok) 

Hans Reiser says his fs should be better because it's an "atomic filesystem"

I can only say that the two times I powered off my PC immediately (one as a test five weeks ago, one some minutes ago to test the new kernel crash-exploit) I had no problems, but I also didn't had any problems when I had switched off my PC with ReiserFS as root for several times.

So... some new stuff for the holy filesystem war  :Rolling Eyes: 

----------

## borkdox

 *HumanPixel wrote:*   

> You may be running with debugging enabled. Check it in your kernel.

 

Nope, no debuggin options, only "Use larger keys on reiser4 tree (REISER4_LARGE_KEY)".

After doing some testing that I saw others around here doing, I see that in some parts, like the "tar -cf", Reiser4 wins Reiserfs, on others it is around the same as reiserfs or slower. As samx said, it has its pros and cons. The thing is that I was expecting speed increase in all parts, not only a 1-2, if you look at the benches in namesys you see that reiser4 an advantage over reiserfs increase in most benchs. I guess somehtimes everyone doesn't get the expected results, unless the benchs in namesys are only the "tar -cf" kind  :Twisted Evil: .

More people than I tough is getting the low results  :Crying or Very sad: , maybe reiser4 is slow in most(not all  :Wink: ) situations after all...

----------

## wrc1944

I just discovered the reiser4/notail problem the hard way, as discribed in my other thread.

https://forums.gentoo.org/viewtopic.php?t=185543

However, I could mount reiser4 partitions with notail in fstab manually, after I booted to root. And, my / partition mounts OK with notail also in fstab.

I am having some problems with creating .xfce4 and .icewm items when I emerge those progs. Is there a consensus forming about this, regarding the benefits (or lack thereof) of reiser4?

I'd like to hear Redeeman's and other opinions on this, as they're the experts. I was all set to attempt moving to reiser4 ASAP, but maybe this partially explains why the release of reiser4 has fallen far behind the previously announced schedule. Guess I'll just maintain a test box for the present, and see what develops. We can always hope for a breakthrough, I suppose.

wrc1944

----------

## Jake

I have new benchmarks. "-tar" is "tar cf file.tar dir" and "-cat" is "find dir -type f -exec cat {} \; >/dev/null". XFS is still best for my MP3s, but not by much. Resier4 remains competitive for the MP3s but does better with the kernel source, beating all but EXT2.

I bet Reiser4 is really fast for "diff -Nuar kernel-tree1 kernel-tree2 > patch_file", but I've done enough benchmarking for now.

----------

## Redeeman

in the tests i have done reiser4 rocks anything, except delete times.

----------

## Jake

 *Redeeman wrote:*   

> in the tests i have done reiser4 rocks anything, except delete times.

 

What kinds of tests and with which snapshot? Clearly R4 is better at some tasks than others, and I think some of the slowness is from post 3/26 bugfixes or adapting to -mm changes.

----------

## Jake

more benchmarks, "Diff-Nuar" is "diff -Nuar linux-2.6.6 linux-2.6.7-rc3-love2 > love_patch", "Patch" is "patch -p1 < ../love_patch >/dev/null", and "Patch-R" is "patch -p1 -R < ../love_patch >/dev/null"

Reiser4 is almost twice as fast as R3 for diffing and good for patching, but nothing comes close to EXT2 for patching, although it wasn't faster than R4 for diffing.

----------

## samx

Just one thing which is interesting: After copying my complete root partition from reiserfs to reiser4, I noticed that on reiser4 there was about 2 or 3% more free disk space (unfortunately I don't have the exact values).

Reiser4 seems to save more disk space.   :Very Happy: 

----------

## samallica

 *samx wrote:*   

> But there is a discipline where Reiser4 seems to be much better! 
> 
> ```
> #tar -xjf linux-2.6.5-rc2.tar.bz2 (I only remark this for better understanding of the next line)
> 
> ...

 

doesn´t this mean that R4 is slower ('cause user and sys times are higher)?

----------

## borkdox

 *samallica wrote:*   

>  *samx wrote:*   But there is a discipline where Reiser4 seems to be much better! 
> 
> ```
> #tar -xjf linux-2.6.5-rc2.tar.bz2 (I only remark this for better understanding of the next line)
> 
> ...

 

I don't think so.

Sys-Total  number  of  CPU-seconds  that the process spent in kernel mode.

User-Total number of CPU-seconds that the process spent in user mode.

We are talking real performance what time does the command take to execute as a whole, not how many seconds it used the CPU. How fast data is moved inside a harddrive doesn't deal that much with CPU, unless compression, encryption and other stuff is being used too. From sys and user data we can conclude that reiserfs is lighter on CPU than reiser4, wich sound logical due to the features added to it.

----------

## mani_

 *Redeeman wrote:*   

> in the tests i have done reiser4 rocks anything, except delete times.

 

i can confirm this

reiser4 was the fastest extracting the kernel.tar and a bit slow when deleting the unpacked files

----------

## AlterEgo

 *samx wrote:*   

> Just one thing which is interesting: After copying my complete root partition from reiserfs to reiser4, I noticed that on reiser4 there was about 2 or 3% more free disk space (unfortunately I don't have the exact values).
> 
> Reiser4 seems to save more disk space.  

 

By copying the disk, all the files get written in an ordered fashion.

You basically "defragmented" your new partition. 

I assume that makes the difference in space.

----------

## borkdox

 *mani_ wrote:*   

>  *Redeeman wrote:*   in the tests i have done reiser4 rocks anything, except delete times. 
> 
> i can confirm this
> 
> reiser4 was the fastest extracting the kernel.tar and a bit slow when deleting the unpacked files

 

Can you please   :Smile:  , post some results and info about your hardware, kernel, reiser4 snapshot used, and version of libaal and reiser4progs? 

Thank you!!    :Wink: 

----------

## moa333

http://www.namesys.com/v4/v4.html#BLOBs

the reiserfs main site says the manual:

 *Quote:*   

> 
> 
> Do we pay a performance penalty for making Reiser4 atomic? Yes, we do. Is it an acceptable penalty? We picked up a lot more performance from other improvements in Reiser4 than we lost to atomicity [...]  I have to say that in my heart I don't have any serious doubts that for the general purpose user the increase in data security is worthwhile. The users though will have the final say.
> 
> 

 

    It semas that if you turn off the system your disk is ok, you dont nead to check it too long or at all because it is atomic.

    Maybe this slow down in performance due to atomicity is what you see in the tests.  Try to do more various tests, that dont imply reading and writing, like only writing without reading (or only reading)

    ext3 is not the fastest system and reiserFS is not so secure for some people; i think reiser4 is somewere between, maybe even faster in some tests....   maybe the beta verssion is not well configured yet...

----------

## testerus

Reiser4 is very fast with small files. I have pan (1 GB cache, about 200,000 files) using  reiserfs (default settings) on a 3,5" harddisk and it takes several minutes to start.

Then I changed my notebook (2,5" hard disk) over to Reiser4 and wow. Pan now starts in 5 seconds (same data). Ok, now some defragmentation occured and it is down to 10 seconds, but this is still a lot faster.

Just hopping that Reiser4 is getting stable soon.

Regards, Helge

----------

## spb

IMHO Reiser4 is quite stable enough for a desktop system. I wouldn't put it on a production box, but I've had all my partitions except /boot on it for a few months now with no problems whatsoever.

----------

## samallica

 *elocal wrote:*   

> 
> 
> I don't think so.
> 
> Sys-Total  number  of  CPU-seconds  that the process spent in kernel mode.
> ...

 

so i am wrong if i think that "real" counts the "real" amount of time a command needs to execute (including the time some other process eats up meanwhile)?

----------

## borkdox

 *samallica wrote:*   

>  *elocal wrote:*   
> 
> I don't think so.
> 
> Sys-Total  number  of  CPU-seconds  that the process spent in kernel mode.
> ...

 

Absolutely not.

----------

## samallica

 *elocal wrote:*   

> 
> 
> Absolutely not.

 

so if i´m not wrong (if that´s what you mean  :Smile:  what do the numbers proove then?

----------

## cbr

Guys. Your partitions are mounting for like under a second. My root partition with reiser4 takes about 20 seconds to mount. Why does it take such a long time?  :Crying or Very sad: 

----------

## samx

 *samallica wrote:*   

> what do the numbers proove then?

 

I would say they prove that reiser4 is fast in a few disciplines (tar -cf kernelsource), but it's slightly more cpu-intensive than reiserFS.

I think reiser4 is a good choice if you have a fast processor, but a slow harddisk (laptop...) but it's probably not appropriate for old processors.

@cbr: how big is your root partition? have you tried to fsck it?

----------

## cbr

The partition is 66GB and no, i have not tryed to fsck it.

----------

## borkdox

 *samallica wrote:*   

>  *elocal wrote:*   
> 
> Absolutely not. 
> 
> so if i´m not wrong (if that´s what you mean  what do the numbers proove then?

 

I don't think you actually read my whole post....

```

I don't think so.

Sys-Total number of CPU-seconds that the process spent in kernel mode.

User-Total number of CPU-seconds that the process spent in user mode.

We are talking real performance, what time does the command take to execute as a whole, not how many seconds it used the CPU. How fast data is moved inside a harddrive doesn't deal that much with CPU, unless compression, encryption and other stuff is being used too. From sys and user data we can conclude that reiserfs is lighter on CPU than reiser4, wich sound logical due to the features added to it.

```

To put it clearler, real counts the time it takes for the stuff to be done, doesn`t matter if you are making a backup of your harddrive at the same time, wich will completely alter the scores. Of course I think everybody that posted bench tried to be running the less amount of proccess and keeping an equal cituation for both cases(Reiser4 and ReiserFS). Sys and User time only count the mount the process spended using the CPU, not the time writing(or reading) the harddrive, wich is what we want to see if Reiser4 is faster or slower than Reiserfs.

----------

## samallica

 *elocal wrote:*   

> 
> 
> Of course I think everybody that posted bench tried to be running the less amount of proccess and keeping an equal cituation for both cases(Reiser4 and ReiserFS). 

 

that's what i wanted to hear  :Wink: 

----------

## borkdox

 *samallica wrote:*   

>  *elocal wrote:*   
> 
> Of course I think everybody that posted bench tried to be running the less amount of proccess and keeping an equal cituation for both cases(Reiser4 and ReiserFS).  
> 
> that's what i wanted to hear 

 

 :Laughing:   :Very Happy: 

----------

