Linux Gazette benchmark Reiser 4

Linux Gazette benchmark Reiser 4

[Robert Hulme]

http://linuxgazette.net/122/TWDT.html#piszcz

It seems to come off fairly badly in most of the tests.

Slashdot have linked to this now so I suspect it will get a lot of eyeballs.

-Rob
--
------------------------------------------------------
"Verbing weirds language" - Calvin
"Java: Write once, debug everywhere."

http://www.robhulme.com/
http://robhu.livejournal.com/

Re: Linux Gazette benchmark Reiser 4

[PFC]

	Hehe. Wow. Sure, a benchmark that runs in 0.03 seconds for the fastest  
one and 0.07 seconds for the slowest one looks pretty reliable to me. How  
much time does it take to spawn the "touch" process 10k times ? Hm... I'd  
guess most of the benchmark time ?

On Fri, 06 Jan 2006 19:10:47 +0100, Robert Hulme <rob@robhulme.com> wrote:

> http://linuxgazette.net/122/TWDT.html#piszcz
>
> It seems to come off fairly badly in most of the tests.
>
> Slashdot have linked to this now so I suspect it will get a lot of  
> eyeballs.
>
> -Rob
> --
> ------------------------------------------------------
> "Verbing weirds language" - Calvin
> "Java: Write once, debug everywhere."
>
> http://www.robhulme.com/
> http://robhu.livejournal.com/

Re: Linux Gazette benchmark Reiser 4

[Hans Reiser]

PFC wrote:

>
>     Hehe. Wow. Sure, a benchmark that runs in 0.03 seconds for the
> fastest  one and 0.07 seconds for the slowest one looks pretty
> reliable to me. How  much time does it take to spawn the "touch"
> process 10k times ? Hm... I'd  guess most of the benchmark time ?

Well said, but there are some results we need to investigate and
reproduce. 

If someone is still learning about benchmarking and learning still that
benchmarks that take fractions of a second are meaningless, it means
that the possibility for error in other aspects is high.  I am willing
to bet that he copied and tar'd the kernel from a different filesystem
than the one he benchmarked, as this is the standard mistake everyone
makes at first, and the impact on performance is HUGE.  That said,
everyone hits things from a different angle.  I'd really like to have
the guys reproduce his big file copy benchmark, as that seems hard to
believe in, unless, well, if the problem is that the file is not big
enough, it would make a lot of sense.  reiser4 used to have a quality
that once it starts to flush something, it really flushes it, and if a
file is the wrong size that can be a disadvantage.  I thought we had
done something about that, but maybe it is still there.  zam, please
comment.

There is probably stuff of value in there, we just have to look at it,
and you should all understand that Slashdot and Linux Gazette are not
the same as peer reviewed journals (though I must say that a lot of the
slashdot posters made good remarks and found flaws that I missed, like
he uses a 500Mhz cpu and a modern hard drive).

A pity the guys are on vacation.....

Justin, if you need access to a modern CPU, we can give you time on one
of our servers.  We have an AMD64....  I am sure others can loan you
access to hardware also.

Justin, if you would like feedback before you publish on benchmarks, we
would be happy to provide it.  Benchmarking turns out to require at
least as much experience as designing filesystems to do well, and indeed
how well one writes a filesystem is often directly related to how well
one analyzes its performance with benchmarks.;-)

Hans

>
> On Fri, 06 Jan 2006 19:10:47 +0100, Robert Hulme <rob@robhulme.com>
> wrote:
>
>> http://linuxgazette.net/122/TWDT.html#piszcz
>>
>> It seems to come off fairly badly in most of the tests.
>>
>> Slashdot have linked to this now so I suspect it will get a lot of 
>> eyeballs.
>>
>> -Rob
>> -- 
>> ------------------------------------------------------
>> "Verbing weirds language" - Calvin
>> "Java: Write once, debug everywhere."
>>
>> http://www.robhulme.com/
>> http://robhu.livejournal.com/
>
>
>
>
>

Re: Linux Gazette benchmark Reiser 4

[Andrea Gelmini]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

2006/1/6, Robert Hulme <rob@robhulme.com>:
>
> http://linuxgazette.net/122/TWDT.html#piszcz
>
> It seems to come off fairly badly in most of the tests.


I really did not understand  this kind of benchmark. I don't care which
filesystem is faster creating 10.000 files (something I never have to do). I
care about which filesystem fits better with my everyday use of my data.
Days ago I wrote a few script trying to simulate a tipical desktop session,
*my* tipical desktop session. With different filesystem I've got difference
of minutes. That's a benchmark that mean something to me.
Why I'm trying/looking at reiser4?
Because:
a) seeks are the real problem of hd (they kill performance);
b) journal in a fixed position creates a lot of seeks;
c) I love ext2, but my laptop crash a lot of time in a day (tests, battery
and so on).

Testing reiser4 is giving to me a good feeling with wondering logs. You
know... less seek, less HD stress... so more responsiveness.
Well, it's too early to express an opinion about R4 (I'm using it since last
week), but the only way to test a FS is to use it for a long time.

Sorry for my bad english,
gelma

[-- Attachment #2: Type: text/html, Size: 1511 bytes --]

Re: Linux Gazette benchmark Reiser 4

[Philippe Gramoullé]

Hello,

On Sat, 7 Jan 2006 13:41:50 +0100
Andrea Gelmini <dislessico@gmail.com> wrote:

  | 2006/1/6, Robert Hulme <rob@robhulme.com>:
  | >
  | > http://linuxgazette.net/122/TWDT.html#piszcz
  | >
  | > It seems to come off fairly badly in most of the tests.
  | 
  | 
  | I really did not understand  this kind of benchmark. I don't care which
  | filesystem is faster creating 10.000 files (something I never have to do). I
  | care about which filesystem fits better with my everyday use of my data.

Well, i do care about which filesystem is faster creating 10.000 files : I happened
recently to author a DVD under Linux using mplayer. For creating some menus,
i had to (well mplayer had to) dump an mpeg file into jpegs , creating about
6000 pictures ( 4 titles with about 1500 pictures for each) (and deleting them
afterwards of course)

I do expect Reiser4 to be faster in the long run for such operations (large
creates/deletes) even if that's not the case right now.

I'm rather disappointed by the feeling this benchmark will give the average users :
Reiser4 is either dog slow or far for being ready for prime time.

Still, as Hans said, i think that some valuable things can be learnt from this benchmark
and it will be good if this benchmark could be carefully reproduced by Namesys and other
Reiserfs enthusiasts

Thanks,

philippe

Re: Linux Gazette benchmark Reiser 4

[Edward Shishkin]

Hans Reiser wrote:

>PFC wrote:
>
>  
>
>>    Hehe. Wow. Sure, a benchmark that runs in 0.03 seconds for the
>>fastest  one and 0.07 seconds for the slowest one looks pretty
>>reliable to me. How  much time does it take to spawn the "touch"
>>process 10k times ? Hm... I'd  guess most of the benchmark time ?
>>    
>>
>
>  
>

Let's consider this important aspect of benchmarking more carefully.
So there is an interesting question: how much should be a difference
in order to approve that some fs really wins at this statistics? Is
there any guarantee you won't get, say, 0.05 and 0.02 after next run?
Sorry, but I didn't find any answer in Justin's notes, NOTE5 (Tests
Performed) says that questionable tests were re-run, but it seems we
need something kinda research here instead of re-run.

Below are some comments for how this problem is resolved (1*) in mongo
benchmark. Look for example at this table:
http://www.namesys.com/benchmarks.html#mongo.2.6.11
Fractions like 0.982 (D/A), 1.017 (C/A) are in black color, it means
that we _can not_ do any assumptions about winner because
|1 - X/A| < 0.02. What the magic M = 0.02 is?
Let's run the same phase for the same settings (file system, file set,
etc..) 10 times. We will obtain for the same statistics X a set of
different (because of errors) values x1, x2, ..., x10. Suppose that
X has a normal distribution (any objections?). It means that we can
calculate its trusted interval for a single measurement (2*) as
[X - d(P), X + d(P)], where d(P) = D*U(P), D is dispersion and U(P)
should be found from the standard table by any nominated value of
trusted probability P (3*).
Now we have the following simple criterion (*4):

|A - X| >= 2d(P), i.e. |1 - X/A| >= 2D*U(P)/A

|           |<-d->|    |<-d->|
------<-----|----->----<-----|----->------
            A                X

The magic M = 0.02 for mongo benchmark was calculated as 2D*U(P)/A
for the trusted probability P=0.85 (5*).
Now it is clear from the formula above why statistics shouldn't be
too small: because the criterion becomes false. I am sure (and it
is easy to check) 2d(P=0.85) is much more then |0.07 - 0.03| as it
is in the case of find 10000 files. By the way, some settings, which
provide a small values (~5 sec) of the mongo STATS statistics also
make this criterion false.


(1*) Maybe this is not a perfect way, but it is better then nothing
(2*) For N measurements the expression for boundaries becomes a bit
     complicated.
(3*) For P=0.85 (as we can found in any scientific book) U(P)=1.44
(4*) One more assumption here about identical distributions of A and X
(5*) Actually D = max(D_create, D_copy, D_read, D_delete, D_dd), where
     D_each_phase was estimated once by 10 measurements with some fixed
     settings by the standard way:
     D^2 = ((x - x1)^2 + ... + (x - x10)^2)/(10 - 1), where
     x = (x1 + ... + x10)/10 is an average value.

Edward.

Re[2]: Linux Gazette benchmark Reiser 4

[Pysiak Satriani]

Hello Edward,

Sunday, January 8, 2006, 11:07:46 PM, you wrote:
> Let's consider this important aspect of benchmarking more carefully.
> So there is an interesting question: how much should be a difference
> in order to approve that some fs really wins at this statistics? Is
> there any guarantee you won't get, say, 0.05 and 0.02 after next run?
> Sorry, but I didn't find any answer in Justin's notes, NOTE5 (Tests
> Performed) says that questionable tests were re-run, but it seems we
> need something kinda research here instead of re-run.
Exactly. By the way, Justin writes he did only 3 tests and calculated
the average out of these 3. In statistics this is a very small sample.
We would need at least 30 or so. If the results would have a big
variance, they should be treated with exponential smoothening.
And then we can go off with the calculations. Also It would be nice
to have data from the exact tests made regularly to test for regressions
and see what's the trend.

> etc..) 10 times. We will obtain for the same statistics X a set of
> different (because of errors) values x1, x2, ..., x10. Suppose that
> X has a normal distribution (any objections?)
Well, for serious reasoning a smirnof-kolmogorov test should be used
or Shapiro-Wilk or any other that applies to check the normal
distribution. If it is, we can go ahead with all the calculations.
If not.. Well, I'm not enough of a statistics guru to say :-)

Regards,
Maciej

Re: Linux Gazette benchmark Reiser 4

[Hans Reiser]

Andrea Gelmini wrote:

>
>
> 2006/1/6, Robert Hulme <rob@robhulme.com <mailto:rob@robhulme.com>>:
>
>     http://linuxgazette.net/122/TWDT.html#piszcz
>
>     It seems to come off fairly badly in most of the tests.
>
>
> I really did not understand  this kind of benchmark. I don't care
> which filesystem is faster creating 10.000 files (something I never
> have to do). I care about which filesystem fits better with my
> everyday use of my data.
> Days ago I wrote a few script trying to simulate a tipical desktop
> session, *my* tipical desktop session. With different filesystem I've
> got difference of minutes. That's a benchmark that mean something to me.
> Why I'm trying/looking at reiser4?
> Because:
> a) seeks are the real problem of hd (they kill performance);
> b) journal in a fixed position creates a lot of seeks;
> c) I love ext2, but my laptop crash a lot of time in a day (tests,
> battery and so on).
>
> Testing reiser4 is giving to me a good feeling with wondering logs.
> You know... less seek, less HD stress... so more responsiveness.
> Well, it's too early to express an opinion about R4 (I'm using it
> since last week), but the only way to test a FS is to use it for a
> long time.
>
> Sorry for my bad english,
> gelma
>
reiser4 is normally very fast in creating 10,000 files.  I suspect that
there was simply error in how he did the test, and when the guys get
back i will have someone try to reproduce his results.

Justin made so many errors, I  suspect he got something wrong here also.

I encourage you guys to run your own tests, and you will see that we do
fairly well I think.  Advice when benchmarking is:

make sure your fileset is much larger than RAM

make sure the benchmark takes a while to run

create your tarballs on the same fs you use them to benchmark (readdir
order matters)

Assume a 3% noise level.

Re: Linux Gazette benchmark Reiser 4

[Marcel Hilzinger]

Am Montag, 9. Januar 2006 19:22 schrieb Hans Reiser:
> Andrea Gelmini wrote:
> > 2006/1/6, Robert Hulme <rob@robhulme.com <mailto:rob@robhulme.com>>:
> >
> >     http://linuxgazette.net/122/TWDT.html#piszcz
> >
> >     It seems to come off fairly badly in most of the tests.
> >
> >
> > I really did not understand  this kind of benchmark. I don't care
> > which filesystem is faster creating 10.000 files (something I never
> > have to do). I care about which filesystem fits better with my
> > everyday use of my data.
> > Days ago I wrote a few script trying to simulate a tipical desktop
> > session, *my* tipical desktop session. With different filesystem I've
> > got difference of minutes. That's a benchmark that mean something to me.
> > Why I'm trying/looking at reiser4?
> > Because:
> > a) seeks are the real problem of hd (they kill performance);
> > b) journal in a fixed position creates a lot of seeks;
> > c) I love ext2, but my laptop crash a lot of time in a day (tests,
> > battery and so on).
> >
> > Testing reiser4 is giving to me a good feeling with wondering logs.
> > You know... less seek, less HD stress... so more responsiveness.
> > Well, it's too early to express an opinion about R4 (I'm using it
> > since last week), but the only way to test a FS is to use it for a
> > long time.
> >
> > Sorry for my bad english,
> > gelma
>
> reiser4 is normally very fast in creating 10,000 files.  I suspect that
> there was simply error in how he did the test, and when the guys get
> back i will have someone try to reproduce his results.

I made some benchmarks for the german Linux-Magazin 6 month ago. Reiser4 on 
Suse Linux OSS was twice as fast as the next FS when copying the uncompressed 
kernel-sources. Either there was a bug in the version of reiser4 he used, or 
he did something completely wrong.  

If I have some free time, I will redo the benches with kernel 2.6.15
-- 
Üdvözlettel -- Mit freundlichen Grüssen,
Marcel Hilzinger

Re: Linux Gazette benchmark Reiser 4

[Hans Reiser]

Pysiak Satriani wrote:

>Hello Edward,
>
>Sunday, January 8, 2006, 11:07:46 PM, you wrote:
>  
>
>>Let's consider this important aspect of benchmarking more carefully.
>>So there is an interesting question: how much should be a difference
>>in order to approve that some fs really wins at this statistics? Is
>>there any guarantee you won't get, say, 0.05 and 0.02 after next run?
>>Sorry, but I didn't find any answer in Justin's notes, NOTE5 (Tests
>>Performed) says that questionable tests were re-run, but it seems we
>>need something kinda research here instead of re-run.
>>    
>>
>Exactly. By the way, Justin writes he did only 3 tests and calculated
>the average out of these 3. In statistics this is a very small sample.
>We would need at least 30 or so. If the results would have a big
>variance, they should be treated with exponential smoothening.
>And then we can go off with the calculations. Also It would be nice
>to have data from the exact tests made regularly to test for regressions
>and see what's the trend.
>  
>
I can just tell you from experience that benchmarks that take less than
a minute have a high tendency to be poor measures  He should increase
the size of the benchmark until each thing he measures takes more than 2
minutes.  If it is reproduceable it can be still meaningless.

Hans

Re: Linux Gazette benchmark Reiser 4

[Hans Reiser]

Did we really do the sophisticated statistical analysis below?  I
assumed we had just taken a look at how much our numbers tended to vary,
and based on experience assumed anything less than 2% was not above
noise.;-) 

The other rule of thumb I have is that really short times can be
amazingly unreliable indicators even when reproduceable.  I am not
entirely sure of why, but I know it to be true.;-)  People suggest such
things as timer inaccuracy, but perhaps there is more inaccuracy than
that could explain.  Perhaps it is scheduler timing related?  I don't
know why it is, I just know it is so.

I do like the way Zam did the red/green/black numbers by the way, I
think I forgot to compliment him on it (it was Zam who did it?).

We need to reproduce Justin's benchmark, fixing the mistakes he made in
its design, and then see how we do at it.  We need to know such things
as, how did he generate filenames, etc.  When people get back....

Hans

Edward Shishkin wrote:

> Hans Reiser wrote:
>
>> PFC wrote:
>>
>>  
>>
>>>    Hehe. Wow. Sure, a benchmark that runs in 0.03 seconds for the
>>> fastest  one and 0.07 seconds for the slowest one looks pretty
>>> reliable to me. How  much time does it take to spawn the "touch"
>>> process 10k times ? Hm... I'd  guess most of the benchmark time ?
>>>   
>>
>>
>>  
>>
>
> Let's consider this important aspect of benchmarking more carefully.
> So there is an interesting question: how much should be a difference
> in order to approve that some fs really wins at this statistics? Is
> there any guarantee you won't get, say, 0.05 and 0.02 after next run?
> Sorry, but I didn't find any answer in Justin's notes, NOTE5 (Tests
> Performed) says that questionable tests were re-run, but it seems we
> need something kinda research here instead of re-run.
>
> Below are some comments for how this problem is resolved (1*) in mongo
> benchmark. Look for example at this table:
> http://www.namesys.com/benchmarks.html#mongo.2.6.11
> Fractions like 0.982 (D/A), 1.017 (C/A) are in black color, it means
> that we _can not_ do any assumptions about winner because
> |1 - X/A| < 0.02. What the magic M = 0.02 is?
> Let's run the same phase for the same settings (file system, file set,
> etc..) 10 times. We will obtain for the same statistics X a set of
> different (because of errors) values x1, x2, ..., x10. Suppose that
> X has a normal distribution (any objections?). It means that we can
> calculate its trusted interval for a single measurement (2*) as
> [X - d(P), X + d(P)], where d(P) = D*U(P), D is dispersion and U(P)
> should be found from the standard table by any nominated value of
> trusted probability P (3*).
> Now we have the following simple criterion (*4):
>
> |A - X| >= 2d(P), i.e. |1 - X/A| >= 2D*U(P)/A
>
> |           |<-d->|    |<-d->|
> ------<-----|----->----<-----|----->------
>            A                X
>
> The magic M = 0.02 for mongo benchmark was calculated as 2D*U(P)/A
> for the trusted probability P=0.85 (5*).
> Now it is clear from the formula above why statistics shouldn't be
> too small: because the criterion becomes false. I am sure (and it
> is easy to check) 2d(P=0.85) is much more then |0.07 - 0.03| as it
> is in the case of find 10000 files. By the way, some settings, which
> provide a small values (~5 sec) of the mongo STATS statistics also
> make this criterion false.
>
>
> (1*) Maybe this is not a perfect way, but it is better then nothing
> (2*) For N measurements the expression for boundaries becomes a bit
>     complicated.
> (3*) For P=0.85 (as we can found in any scientific book) U(P)=1.44
> (4*) One more assumption here about identical distributions of A and X
> (5*) Actually D = max(D_create, D_copy, D_read, D_delete, D_dd), where
>     D_each_phase was estimated once by 10 measurements with some fixed
>     settings by the standard way:
>     D^2 = ((x - x1)^2 + ... + (x - x10)^2)/(10 - 1), where
>     x = (x1 + ... + x10)/10 is an average value.
>
> Edward.
>
>
>
>

A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Giovanni A. Orlando]

Hi,

    Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I 
see that
    in some cases ReiserFS 3.X is better than Reiser4.

    Correct me if I am wrong. High numbers means poor, more delay.

    Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
    we plan to know if there are some system the Reiser3 performance
    may become available for Reiser4.

    Reiser4 is superior but seems that with full security enabled logically
    the system may delay.

    Basically, my question may be re-posted like: "I know Reiser4 is
    different than Reiser3, but may the Reiser4 performance may be superior
    all the time, doing some update?

Thanks,
Giovanni.
   

-- 
-- 

Check FT Websites ... http://www.futuretg.com  - ftp://ftp.futuretg.com
http://www.FTLinuxCourse.com
    http://www.FTLinuxCourse.com/Certification
http://www.RPMParadaise.org
http://www.GiovanniOrlando.com


Fixed Europe:  +39 0824 314 007.
Global Mobile: +39 393 665 4239  (does not work if I am in Caracas).
Global Venezuelan Mobile: +58 412 55 41 338.

'Life is ethernal ... and full of sex!'

-- 

Re: A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Hans Reiser]

Giovanni A. Orlando wrote:

> Hi,
>
>    Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I
> see that
>    in some cases ReiserFS 3.X is better than Reiser4.
>
>    Correct me if I am wrong. High numbers means poor, more delay.
>
>    Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
>    we plan to know if there are some system the Reiser3 performance
>    may become available for Reiser4.
>
>    Reiser4 is superior but seems that with full security enabled
> logically
>    the system may delay.
>
>    Basically, my question may be re-posted like: "I know Reiser4 is
>    different than Reiser3, but may the Reiser4 performance may be
> superior
>    all the time, doing some update?
>
> Thanks,
> Giovanni.
>  

Please understand that that benchmark was so poorly done that it will
have to be repeated by us and fixed before it can have any diagnostic
meaning at all.  We may indeed learn things from it, but what we will
learn we still have no idea of at this time.

V3 is faster for highly synchronous workloads.  V4 smokes it in pretty
much all other measures.  Given time, V4 will become fast at synchronous
workloads.

Hans

Re: A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Vladimir V. Saveliev]

Hello

On Wed, 2006-01-18 at 08:28 +0000, Giovanni A. Orlando wrote:
> Hi,
> 
>     Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I 
> see that
>     in some cases ReiserFS 3.X is better than Reiser4.
> 
>     Correct me if I am wrong. High numbers means poor, more delay.
> 
>     Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
>     we plan to know if there are some system the Reiser3 performance
>     may become available for Reiser4.
> 
>     Reiser4 is superior but seems that with full security enabled logically
>     the system may delay.
> 
>     Basically, my question may be re-posted like: "I know Reiser4 is
>     different than Reiser3, but may the Reiser4 performance may be superior
>     all the time, doing some update?
> 

Unfortunately, currently, reiser4 is not yet superior all the time.
There are some bottlenecks we are trying to fix these days.

Re: A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Giovanni A. Orlando]

Vladimir V. Saveliev wrote:

>Hello
>
>On Wed, 2006-01-18 at 08:28 +0000, Giovanni A. Orlando wrote:
>  
>
>>Hi,
>>
>>    Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I 
>>see that
>>    in some cases ReiserFS 3.X is better than Reiser4.
>>
>>    Correct me if I am wrong. High numbers means poor, more delay.
>>
>>    Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
>>    we plan to know if there are some system the Reiser3 performance
>>    may become available for Reiser4.
>>
>>    Reiser4 is superior but seems that with full security enabled logically
>>    the system may delay.
>>
>>    Basically, my question may be re-posted like: "I know Reiser4 is
>>    different than Reiser3, but may the Reiser4 performance may be superior
>>    all the time, doing some update?
>>
>>    
>>
>
>Unfortunately, currently, reiser4 is not yet superior all the time.
>There are some bottlenecks we are trying to fix these days.
>
>  
>
OK! ... However this is problem for us.

Until now, I don't look yet around in Reiser4 code, because too busy.

However my previous comment: "Use Reiser3 code where is better" ... may 
work.

I am sure that R4 is too different but logically may work!

Thanks,
Giovanni.


-- 
-- 

Check FT Websites ... http://www.futuretg.com  - ftp://ftp.futuretg.com
http://www.FTLinuxCourse.com
    http://www.FTLinuxCourse.com/Certification
http://www.RPMParadaise.org
http://www.GiovanniOrlando.com


Fixed Europe:  +39 0824 314 007.
Global Mobile: +39 393 665 4239  (does not work if I am in Caracas).
Global Venezuelan Mobile: +58 412 55 41 338.


-- 

Re: A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Giovanni A. Orlando]

Hans Reiser wrote:

>Giovanni A. Orlando wrote:
>
>  
>
>>Hi,
>>
>>   Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I
>>see that
>>   in some cases ReiserFS 3.X is better than Reiser4.
>>
>>   Correct me if I am wrong. High numbers means poor, more delay.
>>
>>   Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
>>   we plan to know if there are some system the Reiser3 performance
>>   may become available for Reiser4.
>>
>>   Reiser4 is superior but seems that with full security enabled
>>logically
>>   the system may delay.
>>
>>   Basically, my question may be re-posted like: "I know Reiser4 is
>>   different than Reiser3, but may the Reiser4 performance may be
>>superior
>>   all the time, doing some update?
>>
>>Thanks,
>>Giovanni.
>> 
>>    
>>
>
>Please understand that that benchmark was so poorly done that it will
>have to be repeated by us and fixed before it can have any diagnostic
>meaning at all.  We may indeed learn things from it, but what we will
>learn we still have no idea of at this time.
>
>V3 is faster for highly synchronous workloads.  V4 smokes it in pretty
>much all other measures.  Given time, V4 will become fast at synchronous
>workloads.
>
>Hans
>
>  
>
Good!

Thanks, Giovanni


-- 
-- 

Check FT Websites ... http://www.futuretg.com  - ftp://ftp.futuretg.com
http://www.FTLinuxCourse.com
    http://www.FTLinuxCourse.com/Certification
http://www.RPMParadaise.org
http://www.GiovanniOrlando.com


Fixed Europe:  +39 0824 314 007.
Global Mobile: +39 393 665 4239  (does not work if I am in Caracas).
Global Venezuelan Mobile: +58 412 55 41 338.


-- 

Re: A question: May Reiser4 be equivalent to Reiser3 with some flag/plugin ...

[Vladimir V. Saveliev]

Hello

On Wed, 2006-01-18 at 08:28 +0000, Giovanni A. Orlando wrote:
> Hi,
> 
>     Looking the http://linuxgazette.net/122/TWDT.html#piszcz article, I 
> see that
>     in some cases ReiserFS 3.X is better than Reiser4.
> 
>     Correct me if I am wrong. High numbers means poor, more delay.
> 
>     Now, because we plan to support both: Reiser3 and Reiser4 in our OS,
>     we plan to know if there are some system the Reiser3 performance
>     may become available for Reiser4.
> 
>     Reiser4 is superior but seems that with full security enabled logically
>     the system may delay.
> 
>     Basically, my question may be re-posted like: "I know Reiser4 is
>     different than Reiser3, but may the Reiser4 performance may be superior
>     all the time, doing some update?
> 

Unfortunately, currently, reiser4 is not yet superior all the time.
There are some bottlenecks we are trying to fix these days.