Re: ReiserFS / 2.4.6 / Data Corruption

From: Hans Reiser <reiser@namesys.com>
To: Chris Wedgwood <cw@f00f.org>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Christoph Hellwig <hch@caldera.de>,
	linux-kernel@vger.kernel.org
Subject: Re: ReiserFS / 2.4.6 / Data Corruption
Date: Tue, 31 Jul 2001 14:59:46 +0400	[thread overview]
Message-ID: <3B668FA2.5E76BE1E@namesys.com> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107301904060.5582-100000@duckman.distro.conectiva> <3B65E177.D77ACA45@namesys.com> <20010731223203.B7257@weta.f00f.org>

Chris Wedgwood wrote:
> 
> On Tue, Jul 31, 2001 at 02:36:39AM +0400, Hans Reiser wrote:
> 
>     If you could halve linux memory manager performance and check as
>     many things as reiserfs checks, would you do it.  I think not, or
>     else you would have.  You made the right choice.  Now, if you add
>     a #define, you can check as many things as ReiserFS checks, and
>     still go just as fast....
> 
> The memory manager is stress much more often that reiserfs, EVERYBODY
> has it.
> 
> The MM system does have various sanity checks, things might be
> slightly faster without them, but having the sanity checks is still
> very important.
> 
> If the memory manager does something bad, chances are your system will
> go boom --- upon reboot all is happy.  If as fs goes bad, that
> corruption might still be there when you reboot, even if to another
> kernel!  This is a major difference.
> 
> Anyhow, I use resierfs with debugging/checking on in lots of places.
> The speed difference is negligible, so I think this whole thread is
> pointless.
> 
> FWIW, if the mainline kernels remove the debugging option, I will hack
> it back in --- I for one am happy with the performance and am pleased
> there is additional sanity checking.
> 
>   --cw
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Last I ran benchmarks the performance cost was 30-40%, but this was some time
ago.  I think that the coders have been quietly culling some checks out of the
FS, and so it does not cost as much anymore.  I would prefer that the "excesive"
checks had stayed in.

Sigh, I see I cannot persuade in this argument.  It seems Linus is right, and
debugging checks don't belong in debugged code even if they would make it easier
for persons hacking on the code to debug their latest hacks.

Hans