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."
jred
I'm not a mechanic but I play one in my garage...
If you want journeled ext3 data vs, reiserfs with tails and without tails check out:
http://labs.zianet.com
There are some decent benchmarks there that compare the two as well as extensive NFS tests.
Your question is answered in the Linux ext3 FAQ
One thing in these benchmarks surprised me just a bit:
;0)
that reiser would do so well on the heavy-throughput/large file test.
I've been laboring under the perception that reiser was good for randomly accessing small files, but paid a performance penalty when going after large ones.
Guess I'm still waiting to prove that no one can be wrong about everything!
Cheers.
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.
I'm 110% sure it's saved more files when I've lost power or when something's hung requiring a hard reset than it'd deleted due to hash clashes. What's the likelihood of two files generating the same hash? You talk of increasing likeliness, but don't mention any figures. It's hard to judge without some stats.
As an aside, why didn't you restore your large project from your backup? What do you mean you didn't have...
*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
so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"? So is the _only_ gain the fsck time?
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.
Rather difficult to tell considering that you cannot run Qmail or Postfix under Windows. If you have any benchmarks of, say, Microsoft Exchange (ha!) outperforming Postfix, we would love to see them.
No mindcraft, please.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
to informative information.
Informative information? I really ought to use "Preview" before "Submit".
Actually, you sold it to the Daemon. The matrix was made with FreeBSD. >=)
He's actually referring to the MadOnion 3DMark2001 benchmark.
http://www.madonion.com
If you've never seen it, it's a killer.
Simon
Coming soon - pyrogyra
I would have wanted to also see a non-journalling filesystem compared against these. Since I'm not currently using a journalled filesystem, it would be nice to see the difference between what I use now (ext2) and the journalled fs's.
Forget reading the article, did you read the Slashdot posting? Lets see,
First problem: They weren't trying to make anyone look good, this was a 3rd party test.
Second: Why would they try to make anyone look good, neither of the "products" tested are for profit projects. They have nothing to gain from false benchmarks.
Third: How could that be taken as Linux bashing? Both filesystems are linux only, they aren't being compared to anything non-linux nor are you comparing them to anything non-linux.
Please read both the article and posting before you take the "How to post" (early and often) of slashdot very seriously.
Any benchmarks on XFS vs. ext3/ReiserFS?
... 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.
My car is missing. Therefore, UFOs from the center of the earth took it. Bigfoot was involved.
Why doesn't anyone compare UFS/FFS w/softupdates enabled to the Linux filesystems?
Better yet, why did EXT get to be the defacto Linux filesystem, rather than UFS? It outperforms, and supports much large files/filesystems.
A comparison of UFS from a platform other than FreeBSD might be in order.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Here is what you are missing. Soft updates is a method of ensuring that disk metadata is recoverably consistent without the normal speed penalty imposed by synchronous mounting. The only guarantee that softupdates makes is that your file system can be recovered to a consistent state by running fsck. Soft updates is designed to aid the running of fsck, but does not eliminate the need.
Better get out your Palm add running fsck to your "to-do" list.
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.
Does anyone have info on which of these file systems might be the better one for glitch-free playback of multitrack uncompressed audio? (I'm thinking of up to 16 simultaneous streams, so effiicent throughput would be the priority -- BeOS's BFS was optimized for this sort of thing, but I don't know who in Linux-land has been focused on that aspect of performance)
I don't care if it's 90,000 hectares. That lake was not my doing.
Comment removed based on user account deletion
I use ext3 in ordered mode for my "/" and "/usr" partitions for its data journaling, and reiserfs with -notail for my /tmp and /pub partitions (pub is an FTP/SMB fileserver, lots of activity). I think this is a good compromise between performance and non-corrupability (sp?)
Jeremy
The GIF Unisys patent has, IIRC, passed and is no longer an issue. Otherwise, all true. Motice, though: What image format is the Slashdot logo?
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Who gives a fuck how fast NTFS is compared to fat? Fat32 has a stupid max file length of 2^32 bytes, rendering it all but useless for video work.
If you're stuck doing video work on an NT kernel, (and many people are, since linux is definately behind in this area), do you really want no files bigger than 4gig?
graspee
Comment removed based on user account deletion
Completely true. I've filed a bug to the slashdot bug report page in sourceforge to add some semantic tags to the ones we are allowed to use. I'd like to use , , etc. The bug was deleted as quick as it was posible, with no explanation.
Besides, not only the HTML code doesn't validate. but also Slashdot has blocked the W3C validator!. That's very stupid, as anyone can just download and validate the page uploading it to the validator. Here is the validation result.
This is not necessarily a bug if the probability of that happening in real world scenarios is negligible. After all, you risk data loss from many sources.
Unfortunately, programmers often seem a bit unreasonable about probabilities. They complain about a (say) 1:10^20 chance of losing a file, while at the same time writing the whole file system in C, which basically guarantees a several-fold increase in the probability of undetected software faults compared to alternatives. In fact, the fix for such a remote possibility may not only kill performance, it may actually increase the overall probability of a fault that causes data loss--because the extra code may have bugs.
So, no, this doesn't bother me. I suspect that if Reiser knows about it and he isn't fixing it, he probably thought about it and decided the probability is too remote. If you disagree, I would like to see a more detailed analysis from you.
I'm curious, how can a script (software) reboot a a server that has already halted?
Let's be scientific about this.
Provide at least one pair of filepaths which generate a hash collision under whatever scenario you care to specify, so that others can test and verify the resulting effect, even if it's probabilistic and requires billions of reruns to trigger -- no problem.
If the effect isn't seen by anyone else under any conditions, then the problem doesn't exist. Conversely, if it does happen under some repeatable conditions (even if only extremely rarely) then it *is* a problem, and will be fixed.
If you want to be constructive about it, take this issue out of mythology and onto firmer ground.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
To prove you theory you could take the hash function in reiserfs and replace it with a function that always returns '1'. You would probably have to reformat your partitions though for that test though. The filesystem should still work. If it doesn't that's a bug.
The chances of their being a bug in reiserfs is about 100%. Same is true of ext3 though.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:
The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.
Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.
Slashdot - News for Herds. Stuff that Splatters.
Oh dear God man, I would never want that! Is it really possible for that to happen to my Linux box with ext3? I'm switching to ReiserFS right away!
Thanks for the warning!
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I understand your point. But their point was (paraphrased):
"We need to choose a file system. Let's try to experimentally determine which of out two prime contenders is best."
You may feel that their selection of contenders is incorrect, but to select between them based on experiment is called "the experimental method" (sometimes mistakenly "the scientific method". This is the basis of science, engineering, and technology. I.e.: Don't assume ahead of time that you know the right answer, check.
If they didn't find the problems that you expected, then perhaps you need to examine why. But a hand-waving "explanation" doesn't explain very much, so I don't even really know what problems you think they should have found. FWIW, I haven't noticed any instability problems with ext3.
I think we've pushed this "anyone can grow up to be president" thing too far.
I love that band!
Bare bone nest is one of 5 records that keeps the LP player hooked up to the stereo.
Comment removed based on user account deletion