Rik van Riel wrote:
>
> On Tue, 31 Jul 2001, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> > >
> > > Nope. It does a reiserfs_panic instead of letting the wrong arguments
> > > slipping into lower layers and possibly on disk and thus corrupting data.
> > >
> > > And in my opinion correct data is much more worth than one crash more or
> > > less (especially with a journaling filesystem).
> >
> > There is nothing like a distro maintainer overriding the design
> > decisions made by the lead architect of a package, not believing
> > that said architect knows what the fuck he is doing.
>
> Are you actually saying you don't care about user's data,
> or is it just my imagination ?
>
> (I hope it's my imagination ...)
>
> cheers,
>
> 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/
I am saying that you can put so many internal checks into a filesytem that it is
unusable for any real usage. Guess what? ReiserFS does that! But we surround
the checks with a #define. The only limit we have on the checks, is that after
the relevant bug disappears we cut out the ones that make things so slow that it
noticeably inconveniences our debugging. It has to slow things down quite a lot
that we can't stand to wait for it while debugging, but there are some kinds of
checks that you can do that are that slow.
ReiserFS checks more things than the rest of the kernel does. We can do this
because we use the #define, and pay no price for it. You should do this also in
your code....
Every major kernel component should have a #define which if on checks every
imaginable thing the developer can think of to check regardless of how slow it
makes the code go to check it. Then, when users (or at least as usefully,
developers adding a new feature) have bugs in that component, they can turn it
on.
Hans
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:47 EST