Re: reiserfs empirical study (very long)
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 debian-powerpc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: