Re: ReiserFS / 2.4.6 / Data Corruption

Alan Cox (alan@lxorguk.ukuu.org.uk)
Fri, 27 Jul 2001 16:51:16 +0100 (BST)


> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
>
> Yes, that option should never be on for an end user not having a bug that he wants a more detailed
> bug report on. It just makes us look slow compared to ext2.

Maybe its old fashioned but we'd rather any inconsistency in the file system
behaviour was made obvious to the end user. Enterprise customers object to
losing data.

> 2.4.2 was not a stable kernel for any FS, not just for ReiserFS.

The RH 2.4.2 derived kernel isnt 2.4.2 by any stretch of the imagination.
Vanilla 2.4.2 wouldnt pass a test suite.

> I don't think that even with CONFIG_REISERFS_CHECK on, journal replay can take as long as fsck on
> ext2. reiserfsck though, if that was on, oh, could even RedHat be that desperate to make us look
> bad to users as to run reiserfsck at every boot?

Hans, if you stopped considering every report that your file system wasn't
the best in the world as either a conspiracy theory or someone elses fault
you'd have a much better product

Nobody needs conspiracies to not use reiserfs as their core fs, and until
things like big endian support are cleanly resolved that isnt likely to
change.

Alan
-
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/