I thought you might find this info relevant. I'm running a starmax 4000/200 with 80 megs of ram and a 200 mhz 604e. I also run kernel 2.4.4-pre6 and I've been up for 9 days now. Before this, I was up for about 25 days. I rebooted when I rebuilt my kernel to upgrade as well as to add in a feature I wanted.
So far the 2.4 series has been rather stable for me for pc and ppc (I just have a hard time building a working kernel on ppc). I've never had an unexplained crash (that is, when I can build a 2.4 kernel that boots.). In fact, now that I think about it, I don't think I've ever had a crash, using 2.2 or 2.4.. So I don't know why you've had trouble. Have you tried using a 2.4 kernel without smp on? I'm using ext2fs BTW. If you're interested, I could send you my kernel config file. Hope this info was helpful. -Cameron On Wed, 30 May 2001, Andrew Sharp wrote: > [I am cross-posting this to the sparc list even though I haven't had > a chance to get this working on sparc yet. This is because 2.4 > kernels are a bit harder to come by for sparc32 than they are for > powerpc right now. But someday in the near future, they might be > easier to get, and then this would be useful(?) information.] > > There has been some FUD about reiserfs on this [powerpc] list, so I > thought it might be useful to gather some firsthand information and > experience and make it available. > > First, there has been some confusion about reiserfsck and e2fsck. > The idea that reiserfsck doesn't work comes from the logic(?) that > it can't fix all possible and theoretical fs damage, so therefore it > doesn't work. This is true, but it is also true by the same logic > that e2fsck doesn't work. Or that they both work. Something that > is overlooked by this whole idea is that reiserfsck and e2fsck have > vastly different respective roles in relation to the main product. > e2fsck is a common and daily use utility which is an integral part > of ext2fs and similar UFS/FFS based file systems. Reiserfsck is an > adjunct and a last gasp that might fix some problems in the event of > a hypothetical bug that hypothetically might cause the normal > recovery mechanisms from being sufficient. If you find yourself in > a situation where the normal recovery mechanisms of reiserfs don't > work, the file system is most likely so fubared that reiserfsck > won't be able to do much. But it might. The point is that under > the same circumstances, e2fsck probably wouldn't be able to put > humpty back together again either. I would like to point out that > at no time in all the tests that I ran did reiserfsck run (in the > event that the log fails to replay, reiserfsck is run). Nor did > reiserfs suffer any strange problems like corruption or anything > else. BTW, reiserfs is not considered to be a more reliable file > system, but rather more resistant to crash damage than UFS based > file systems. > > Software: > * linux kernel 2.4.5-pre3 or something like that, from the famous > benh rsync kernel tree. > * endian patches for the kernel and reiserfsprogs > * Debian potato distribution > > Hardware: > * Powermac 8500, 2 x 604e PowerPC processors > * various hard drives: > + on external 53C94 scsi controller (5MB/s async) > 1) an old 1.2GB seagate > 2) a younger 2GB IBM > + on internal MESH (10 MB/s sync) > 1) a 4GB Fujitsu > > Notes: > > All the performance test results were verified and repeatable within > about 1% deviation, unlike the test results on a certain web site > which had differences ranging from 50 to 100% for the same test(!), > rendering them completely useless. > > The big endian patches change the code to use little endian ordering > for all on-disk structures. IMO this is a mistake, and certainly > costs a dear performance penalty, because on big endian processors, > this method requires converting endianness both ways (reading and > writing) for all meta data. I submit that there is little reason > for this, and the performance cost is not worth the very dubious > feature of having the file system be moveable to little endian > systems, like x86. Note that except in few cases, the disk labels > alone would prevent this. I would very much like to see some endian > patches that don't have this affect. I believe that the large file > I/O performance and large directory tree copy performance would show > a definite increase. It may be too late now. > > It should be noted that 2.4 was extremely unstable. Random lockups > were common, at least one per 24 hours, and often just after getting > the login prompt after boot up. These lockups weren't related to > reiserfs (or ext2), because they occured regardless of whether > reiserfs.o was even loaded. In fact almost all the lockups occured > during periods of no activity. > > In the area of large file creation and I/O, ext2 was the winner, not > by much, but repeatable and significant. This was backed up by > results from the bonnie disk benchmark, showing a slight but > significant edge to ext2fs. The bonnie benchmark is in many ways a > large file I/O test. Bonnie's disk I/O test using character I/O is > of no use because it's CPU bound, meaning the results are pretty > much the same for both file systems. This large file advantage can > be traced to the "extent" aspect of disk space allocation that is > very efficient. Reiserfs would do well to adopt something like it. > > In the area of file creation and directory manipulation, reiserfs > won by a huge margin. Explicitly, after 2-3 hours, the "create 400k > files of size 0 in a directory" test caused the system to thrash > itself into uselessness on an ext2 file system, ultimately creating > less than half that many files. > > In the area of copying a large directory tree using two tar > processes, it was almost a dead heat, but with reiserfs winning by a > toe nail clipping. This miniscule advantage was probably due to the > extremely fast performance on creation of a large number of small > files, which came in handly when copying include directories from > kernel source trees. > > And last but most, the catastrophic failure test. As you might > expect, reiserfs kicked butt on this one. Actually, reiserfs was a > ray of sunshine because the system had a tendency to not be working > if left alone over night. Ext2 file systems suffered some serious, > messed up damage from these, requiring several libraries and other > core files to have to be reinstalled. If I was going to run 2.4.x > right now, I would probably make reiserfs the root file system for > that reason alone. One note however: when the cord is yanked from > a reiserfs file system, it causes the kernel to hang. Permanently. > Ext2 did not have this problem. A note will be sent to reiserfs > about that. Caution: don't try this test yourself. One of my disks > lost its low level formatting when doing this. Other severe > hardware failures to both drive(s) or computer(s) could result as > well. Don't try this at home! > > Results: http://www.netfall.com/linux/powerpc/reiser-results.txt > > Next installment: accurate depiction of Linux kernel development > politics and reiserfs. > > a > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
