A KDE dev has attempted to put ext3 and reiserfs to a real world test. The results are interesting, and confirms what many of us already knew. Check out the experiment for details.
Real life test of ext3 vs reiserfs
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
owned.
I would realy like to see fat32 vs reiserfs
i would rather have him clock the speeds then saying “very fast” or “very very fast”
http://www.namesys.com/benchmarks.html
Copying some files doesn’t define a good test. There is no mention of the system loads, capabilities of the two boxes, etc. Talk about a bad test — and that makes news? Ok then, whatever!
Is that what really matters? The circumstances under which “good tests” are often performed have nothing to do with real life. Besides, what he’s measuring is mostly space usage, not speed. Anyway I’d rather trust an actual developer saying “it’s faster!” than numbers from the company who made it…
– Simon
There have been several benchmarks showing the performance gains (ie: speed, stability, etc) of using ReiserFS instead of other files systems. It’s one of the reasons I believe Novell switched SuSE Linux from ext2/ext3 to ReiserFS. Anyway you can either do a Google search to find the benefits yourself or go directly to the project page here http://www.namesys.com/ and click on “Benchmarks”.
I am running Yoper on a machiine (v2.1) with reiser4.
I do not really notice speed differences with a Mandrake 10
machine running ext3. Yoper is somewhat faster but its not a big diffeence and its mostly because of the way Yoper is compiled etc. then the filesystem.
LInspire is running on reiser4 too and here i really feel the difference. Its very snappy and feels a lot faster than Yoper and/or Mandrake….could it be Linspire gets cutting egde since the finace the reiserfs org.?
Man I really am interested in knowing how linspire behaves (I guess you’re using version 5 since you have reiserfs4). I have some questions about it, but I guess you’re under some sort of NDA agreement, so could we talk about it over email?..that of course if it’s ok with you. My e-mail is adminATconstantinmusicDOTcom
Thanx in advance!
fat32 is not a usable filesystem in the modern age, with a limitation of 2GB files, it’s horribly dated.
I’d like to see XFS through into this experience.
I’d really like to know what ext3 is doing with that space, I imagine that whatever utility you used to measure must be miscounting somehow? Maybe you have huge sectors (blocks?, whichever word is right) on your disk? 220MB just seems beyond pathetic unless it is doing something special there (possibly reserving space for each directory to have things in them, for speed purposes?).
Of course, if you are using in excess of 10,000 files repetitively, reiser is probably going to be your friend.
It makes a wonderful root filesystem
.
Novell didn’t switch SuSE to ReiserFS, they were already ReiserFS. Indeed, they were a supporter of ReiserFS development, and were one the first distros to ship with ReiserFS.
Ext3 takes up a whooping 220M…
Ha, I can just envision a shrieking swarm of bytes…
Is this not a result of ext3 reserving space. I could be horribly wrong here, but I remember reading that ext3 reserves space to try avoid fragmentation.
“Still curious though, I made a tar.gz of the directory structure. Perhaps not surprisingly, that takes up only 700K compared to the ridiculous 220M for ext3. I tried the same thing with the full dump and that takes up 60M compared to ext3’s gig”
How can that be? Tape archive is just putting the files in one long string.
The main selling point of reiserfs is in handling large directory structure, and promised atomic transactions; which is exactly what the author is used in his benchmarks.
There are many other factors that affects the real world performance of fs, e.g throughput, cpu load etc. Handling large directories well alone is no way the complete picture.
After all not many people are using 55000 empty directories on their desktop system.
one owuld allso have to take into account that reiserfs is a very new fs in linux terms. ext3 however is ext2 with a journal on top. in fact you can read from it useing a ext2 driver if you feel like it. so the question again becomes, stability or performance. how good a trackrecord does reiserfs have?
This benchmark is meaningless. Space is cheap these days. Very cheap. Downtime is not.
So reliability is the key benchmark here and gathering anything more than anecdotal evidence on which filesystem is the most reliable is hard.
My own bias is towards XFS, because I have had very, very good luck with it.
Hi Guys,
It was never my intention to create a scientific benchmark. This was just an ad-hoc trial of an idea I had.
Nevertheless, I think the results are interesting. Someone pointed out that it would be interesting to see how much space uncompressed tar takes as opposed to compressed tar.
I’ve added the results for that, and it seems to show that there is room for improvement on ReiserFS.
Speed-wise, I didn’t give numbers because I was running on different systems with different loads and different capabilities. However, I can tell you that the file operations I tried on ext3 took an order of minutes, as opposed to an order of seconds on ReiserFS. Roughly maybe 3 minutes on ext3 vs 3-4 seconds on ReiserFS (less on the second trial). Frankly, for me those results are good enough. I made sure both systems were mounted noatime and so on.
I agree with you completely! I’ve had more luck with xfs too! I’m looking into the new 128-bit FS’s.. mouth watering.. Time to start testing 😉
XFS works very well for my needs: multimedia, office/desktop and server tasks. subjectively it is fast and responsive … and seems to have low-latency as well as good-enough thoughput. and the tools are much better than those for JFS.
Space seems to matter less and less as time goes by. Harddisk prices are now close to $0.50/GB. Hitachi just released their flagship 400GB SATA drive. But speed does matter.
I’d think Google running Linux and managing huge amounts of small sized information would be interested in (supporting) the new ReiserFS.
Some are already running the new ReiserFS. But it is not in the official kernel yet. It is sitting in the mm tree. Anyone know how it is going and when/if it will be merged into the official kernel?
This was a cool ad hoc use test, but anyone trying to deduce anything real from it misses the point.
Space efficiency is a very hard thing to determine when mixing different harddrives. For example, one harddrive might have a device block size of 512 bytes, and the other might have a killobyte block size. From a design standpoint, Reiser is probably going to be more efficient with the latter drive, but might appear less efficient because of a hardware limitation with small block allocations.
Speed can also vary between drives. System load? Drive cache? ReiserFS is signifigantly more processor intensive than FFS descended filesystems (like ext2/3 or UFS), processor power and cache matters.
For those of you asking, XFS would probably perform terribly. XFS uses B-Trees up and down in it’s design, creating some additional per directory overhead, and is geared for large (as in 2-4 gigs) files. This is exactly the load underwhich it would perform badly.
Actually, in terms of on disk data structures, XFS and ReiserFS seem like brothers. ReiserFS is to large directory structures and small files what XFS is to flat structures and huge files.
Gurulabs performed comparison between ext3 and reiserfs. It’s outdated, but more scientific and gives also interesting results.
http://www.gurulabs.com/ext3-reiserfs.html
lol, that should be a test?
“Choice is good. Its nice that you can choose between file systems. But all of this “Ext3 is crap” comments are nothing but Trolls from users who know nothing about File System reliability and simply want to bash anything that has to do with Red Hat.”
I think this shows more your own bias/projection than anyone else’s….since when did ext3=red hat? AFAIk you can use ext3 on any distro.
The article don’t says if he tuned the filesystems with mount parameters. ext3 is know to use _very_ conservative dafault values (much more conservative than reiser), he might want to try data=writeback or commit=hugevalue ….
i agree with ddd, ext3 works great for me, during a lightning storm i had a hard crash caused by power outage and ext3 booted up fine after the power came back on, not one problem with it, i have had problems with ReiserFS before, but i am not going to bash Reiser too many people swear by it, maybe i did something wrong in my implementation with Reiser, one person said not to format a /boot partition with Reiser, so maybe he knows something about that, (who knows), so i am sticking with what works good for me (ext3)
/dev/hda1 = /boot
/dev/hda2 = /
/dev/hda3 = /home
/dev/hdb5 = /swapspace2
/dev/hdb6 = /storage
I have had two machines crash with major file corruption and a kernel panic using EXT3 for only a short time. In both cases, the machine was reformatted with ReiserFS (since EXT3 was an experiment of interest for me) and has been running for years now.
Good enough for me, ReiserFS stays.
I have avoided the REISERFS as it can make it very difficult to resolve certain core/attrb issues with stock kernels.
I never use distro based kernels on my production machines, instead I build and roll my own.
There have also been reports, the the REISERFS can bring older machines PII for example to a halt, bsically due to either old controller requirements or CPU requirements to support the transaction profile on a REISERFS.
So, I use ext3 because it works fairly well on older machines.
That and stability issues on kerneltrap with historic HAN’s releases of the file system have not been particularly stellar. I tend to think of ext3, based on tried and true ext2 foundations as a more reliable file system.
But, that is my opnion/preference/experience. YMMV.
-gc
Having using linux for over 5 years now, I’ve tried many different file systems, and nowadays I put ext3 on almost everything.
Reiserfs is just too unstable for me. Sure it works fine and great, until your xserver hardlocks or whatever, and you have to powerdown your computer. Almost everytime this has happened i’ve had corrupted data with reiserfs.
I’ve tried xfs too with a few problems but not enough experience to comment on it.
I’ve never had corrupted data on an ext3 partition though. That matters far more then speed to me. That said I’ve read a lot of work going into the 2.6 kernel for desktop latency has been somewhat optimized for ext3 – personally I don’t find ext3 all that slow.
Perhaps I’m biased due to it never, ever destroying my data :p
some months ago i installed it on a few computers..
on cold shutdown such computers’ filesystems lost some of the files that were being worked on at the time, not the changes or anything, but the entire files.. which lead to bad corruption of the distro (debian).. the power grid is somehow unstable here in some places of south america and that never, ever happened to me with ext3 or xfs in the several years I used them.. so, even if it’s slow, i’m not moving to reiser.
I think this shows more your own bias/projection than anyone else’s….since when did ext3=red hat? AFAIk you can use ext3 on any distro.
Sure… but his point is that some people are bashing ext3 because it was developed by Redhat.
As for me, I prefer XFS. ReiserFS is fast (especially with deletes and small files) but I had some corruption issues because of hardlocks or power failures. The “recovery” tool coming with v3.6 is utter manure. I never had that problem with XFS and it comes with recovery tools so guess which FS I am using…
I might try Reiser4 on a system partition soon but I won’t trust my data before long.
How about reading some *proper* technical documentation on this issue:
http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf
Dave
Quote: “I think this shows more your own bias/projection than anyone else’s….since when did ext3=red hat? AFAIk you can use ext3 on any distro.”
Maybe you need to learn a bit more? ext3 was developed with the help of Redhat developers, being paid by Redhat, to work on the journalled file system.
Glad that you understand that you can use it on any distro 😉 It appears trolls aren’t entirely thick.
Dave
Edwards, Scott :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00034….
The test is really pretty simple. It is hooked to a machine that cycles
the power. It runs for 5 minutes and then the power is turned off for
1 minute (to simulate the plug being pulled). For this last set of tests
it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The
system boots a minimal install of Fedora Core 2 from the IDE drive. No
tests are running on the IDE drive. In the rc.local file it starts the
fsstress test http://ltp.sf.net/nfs/fsstress.tgz and the three scripts
below (to simulate writing into a log file) on each of the SATA drives.
The ext3 have almost a perfect record with the write cache off (NB: ATA setting) : I have
run over 300 cycles on the two drives and only had two corrupted lines
in the output files. So out of 600 total cycles on the two drives there
were only two lines with bad data(see Alan Cox explanation), I think that is a pretty good record.
None of the other journaling file systems have come anywhere near this
performance. After 3 or 4 power cycles, ReiserFS became corrupted to
the point that the system would not boot up (the fsck failed and the
bootup stopped there). XFS never got corrupted to the point it wouldn’t
boot, but with approximately 100 power cycles on each drive, one drive
had 73 corrupted lines and the other had 82. With JFS after 15 power
cycles one of the drives was corrupted and the system would no longer
boot up (fsck failed again).
I just can’t understand what is happening, it makes no sense to me that
one file system would be almost perfect and three would fail so
dramatically. I am going to re-run the tests on all 4 file systems to
verify that it is repeatable.
Alan Cox :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00035….
On Fri, Jul 02, 2004 at 11:22:20AM -0500, Edwards, Scott (MED, Kelly IT Resouces) wrote:
> The ext3 have almost a perfect record with the write cache off: I have
> run over 300 cycles on the two drives and only had two corrupted lines
> in the output files. So out of 600 total cycles on the two drives there
> were only two lines with bad data, I think that is a pretty good record.
Unless you are doing data journalling or some kind of userspace
transactions you wouldn’t expect file contents to be perfect. Data
journalling has a big performance cost.
> I just can’t understand what is happening, it makes no sense to me that
> one file system would be almost perfect and three would fail so
> dramatically. I am going to re-run the tests on all 4 file systems to
> verify that it is repeatable.
Your expectations seem at odds with what journalling provides. A journalled
fs can be recovered by log replay. It doesn’t guarantee that user data is
recovered precisely. It guarantees that user data is recovered to those
points where it was committed.
Thus
open file O_APPEND
write stuff
close it
repeat. doesn’t guarantee “stuff” will always be committed – it just
guarantees that the fs will be structurally sound
open file O_APPEND
write stuff
fsync
close
OTOH says that after the fsync has returned you can be sure the data
just wrote before it *will* still be there.
Ext3 data journalling journals everything which is a bit slower but can
be appropriate for some applications (and actually for big NFS servers
often turns out to be faster because of the NFS commit behaviour)
Bill Rugolsky Jr. :
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00036….
Aside from Ext3, the other journaling filesystems usually only guarantee
meta-data consistency. (Reiserfs just got data journaling with
ChangeSet 1.1804, 2004/06/18 07:55:25-07:00.) Corrupted files are
expected with non-Ext3 filesystems. Though if fsck fails
on those filesystems, that indicates a meta-data consistency problem.
Here is a comment that I wrote a long time ago in reply to a comparison
of Reiserfs to Ext3.
read the rest.
>Exactly what did it confirm? That people who run around
>promoting filesystems like reiserfs are basically idiots?
>We already knew that,thank you very much.
It confirmed that it’s easier to have a priest give up his religion than to have a sysadmin give up his FS.
Who have not ever lost data using ReiserFS go back to heaven, you are not human.
It will be interesting to see how ReiserFS 4 is.
It is meant to fix the short comings of the ReiserFS 3.x
series just like ext3 did with ext2.