Slashdot Mirror
New Ext3 vs ReiserFS benchmarks
An anonymous reader writes "Saw this new benchmark on the linux-kernel mailing list. Although NAMESYS, the developers of ReiserFS has many benchmarks on their site, they only have one Ext3 benchmark. The new benchmark tests Ext3 in ordered and writeback mode versus ReiserFS with and without the notail mount option. Better than expected results for Ext3. Big difference between ordered and writeback modes."
Your question is answered in the Linux ext3 FAQ
You're on crack. Hash collisions incur only a performance hit, not lost data.
My decision isn't based on performance. They both are "fast enough" for me. I used to use ReiserFS a while back and it was great. Then I installed Redhat 7.3 on a machine and used ext3 so I didn't have to mess with anything. Yes tinkering is fun... but when I feel like it. Sometimes its nice to have stuff Just Work. Haven't had any problems since and have had a few random power outages.
Also I like the idea that I can read the drive with an ext2 driver from an older kernel or from FreeBSD just in case. In case of what? I don't know, but somehow it makes me feel better.
Slashdot cut off my comment!
Awww, and here I thought you were trying to give an example of what the ReiserFS did to your data during a hash collision.
Apparently, of the rich, by the rich, for the rich.
*ANY* journally filesystem can recover from an unexpected power loss. With an ext3 system, if you're seeing a check taking place (and you want to prevent such), disable them - in general, they are a holdover from ext2:
tune2fs -c 0 -C 0
However, you should also read this, from the tune2fs man page:
You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.
I cannot speak to the inode issue - I've never run into it myself.
We who were living are now dying
With a little patience
Can you document the claim that hash collisions cause silent data corruption? Or even that they cause a failure of any sort?
If this is true, surely it must be documented somewhere, or have been discussed in a credible forum? I did a little searching, and didn't find anything. Please post a URL to elevate your comment from unsubstantiated rumor to informative information.
In most hash-based indexing algorithms I know of, hash collisions incur a perfomance penalty, but not a data loss.
... that's why you lost your data. It annoys me to no end when people assume a cause for a problem and begin to state it as fact without verification or fact.
/.
Is it possible that there is a bug in reiserfs? Sure. I just don't trust anecdotal evidence from some dood on
You can never equivocate too much.
We benchmark ReiserFS versus all other Linux filesystems about once every 6 months or so, and the last one from about 3 months ago still places Reiser in the "significantly faster" category for our workloads, specifically web caching with Squid.
ext3 is a nice filesystem, and I use it on my home machine and my laptop. But for some high performance environments, ReiserFS is still superior by a large margin. It is also worth mentioning that I could crash a machine running ext3 at will the last time we ran some Squid benchmarks (this was on 2.4.9-31 kernel RPM from Red Hat, so things have probably been fixed by now).
All that said, I'll be giving ext3 vs. ReiserFS another run real soon now, since there does seem to be some serious performance and stability work going into ext3.