Re: Reiserfs stability
Just asking around is probably not the best way to decide whether you should use
a mission critical feature of some piece of software. It would be better if
there were some hard statitistics, such as a mean time between failures, but
there aren't. At least not yet, but collecting such statistics is one of the
long-term goals of (the barely begun) http://linuxquality.sunsite.dk/
However, I have a couple suggestions.
One is to examine the changelogs for a sequence of kernel releases. Look to see
if there have been any bugs fixed that have anything to do with ReiserFS, or
anything that ReiserFS depends on, like VFS or the buffer cache. If there have
been no bugs fixed for a while, then most likely no one has encountered any
problems with it for a while and the software is probably stable. Alternatively
it could mean no one is maintaining it or that there is such a difficult bug
that more than one kernel release is required to fix it :-)
Ideally you wouldn't want to use the very latest kernel (as an unknown bug could
just have been introduced), but use a few versions back from the latest, then
look ahead in history to see if any bugs at all that could effect you got fixed.
I was watching the changelogs to check up on ReiserFS this way for a while
because I wanted to use it but felt it was risky. After some time I stopped
watching because there were almost always fixes being reported, sometimes fixes
for very serious bugs that could cause massive data corruption. I haven't
checked in a long time though, and am starting to consider that I should use it
after having such a mess of ext2 filesystem corruption after a lockup that I had
to reformat and reinstall one of my boxes.
The other thing I would suggest is to install a machine with an identical
configuration to the one you plan to use and stress-test ReiserFS with Cerberus.
That way, even if there were a bug experienced by other people, you could find
out if it would be likely to effect you. Alternatively, even if no one else has
any bugs, you'd find out if you're likely to discover one.
http://sourceforge.net/projects/va-ctcs/
(Cerberus doesn't appear to be available in Woody so I guess you'll have to get
it from sourceforge).
If the machine in question is already in use and you don't have a spare
identical box, maybe what you could do is put a ReiserFS filesystem on a spare
partition, or install a second disk drive for the purposes of testing.
If you don't have a spare partition and can't afford another drive, one way you
could do it is back up the computer (thoroughly - this is somewhat dangerous)
then use GNU parted to resize a partition that has lots of free space and create
a new partition in the hole left behind
http://www.gnu.org/software/parted/
(parted is available as a debian package in Woody, although it appears to be
rather out of date.)
When you're done with your test you can use parted to remove the spare partition
and resize your the partition you shrunk to fill the hole back in.
It's a good idea to give a new kernel build thorough testing before putting it
into production. You really should do this even if the kernel is just for your
home desktop box and is not mission critical, because sometimes a build just
goes bad or a serious bug creeps in and no one knows about it for a while (again
a reason not to use the very latest kernels for production use).
I discuss the use of test suites to evaluate Linux kernels, and list some test
suites at:
Using Test Suites to Validate the Linux Kernel
http://linuxquality.sunsite.dk/articles/testsuites/
In the article I talk about testing your hardware with such programs as
memtest86 (what you should really do first), testing the kernel directly with
such suites as the Linux Test Project, and testing the kernel indirectly by
running application test suites (this tests the kernel via the system calls the
applications execute while they are under test)
Here's a quick way to test a kernel:
Get the source code to the kernel you want to use. Configure and build it, then
boot off the kernel you just built.
Now "make clean" and build the kernel again (with the same config), while
running off the kernel you just built. Boot off the new kernel and see if it
still works.
For extra credit, run a bunch of other programs at the same time as you are
building the second kernel. What I usually do is build some other large package
like AbiWord, run a big M-x hanoi in Emacs, and run glxgears at the same time as
I'm trying to build the kernel. Or you could run Cerberus during the kernel build.
For testing ReiserFS, what I would suggest is installing a system where all the
filesystems used in the kernel build will be ReiserFS (not just the filesystem
where the sources will be, but also where the software used in the build will
come from). This should be /, /tmp, /usr and whatever filesystem you put the
kernel sources on - usually /usr but I often make a symbolic link from /usr/src
to /home/src
One more thing to look for is to find out how well ReiserFS works on other CPU
architectures. I know that a while back it was reported on debian-powerpc that
ReiserFS was not ready for PPC. Porting software often shakes out a lot of
bugs, as latent bugs that do not make themselves visible on the original
platform are often exposed when the code is moved to a new one.
Mike
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford@goingware.com
Tilting at Windmills for a Better Tomorrow.
Reply to: