Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser <reiser@namesys.com>]

Rik van Riel wrote:

> > If you could halve linux memory manager performance and check as
> > many things as reiserfs checks, would you do it.
> 
> I haven't removed a single debugging check from the
> 2.4 VM. Performance is MUCH more reliant on things
> like evicting the right page from RAM or reading in
> the right page at the right time.
> 
> CPU usage is only secondary.
> 
> > .. You made the right choice.
> 
> Thanks ;)    [yeah, yeah ... flame me about out-of-context]
> 
> > Now, if you add a #define, you can check as many things as
> > ReiserFS checks, and still go just as fast....
> 
> I'm sure these checks make reiserfs a tad more CPU hungry,
> but isn't the real win in reiserfs supposed to come from
> superior disk layout, readahead across files, etc... ?
> 
> Or is that all just a myth ?
> 
> regards,
> 
> Rik
> --
> Executive summary of a recent Microsoft press release:
>    "we are concerned about the GNU General Public License (GPL)"
> 
>                 http://www.surriel.com/
> http://www.conectiva.com/       http://distro.conectiva.com/


A tree is a complex structure.  You can check it, and the temporary structures
involved in balancing it, quite a lot of ways while balancing it.  I believe you
that the checks you need for your code have no significant performance impact. 
Ours sometimes do.  Consistency checks can be quite a bit more than a tad
consumptive of CPU.  Like I said, there were a few checks we removed after the
bug was gone because we got tired waiting for our debugging iterations taking so
long because of them.

Using the #define means we don't have to think about the effect on performance
of a check, we just leave it in.  Some checks belong outside the #define
(checking to see if garbage came back from disk is left outside the define
nowadays.)  Distros should trust the developers in these tradeoff decisions. 
Otherwise, things just get stupid.

Hans