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."

Comments

Writeback kicking it

[jred]

Writeback kicks ordered's ass. They do warn you about it, though:

However, it is clear that IF your server is stable and not prone to crashing, and/or you have the write cache on your hard drives battery backed, you should strongly consider using the writeback journaling mode of Ext3 versus ordered.

I didn't see where "notail" made much of a difference on ReiserFS, though.

Re:Writeback kicking it

[Zwack]

But if you look at the NAMESYS benchmark comparing ext2 to ext3 and ResierFS then it is clear that for sheer throughput ext2 wins...

IF Speed is your reason for choosing a Filesystem then writeback wins on almost everything in these examples...

But using a Journaled Filesystem isn't usually done for Speed... Unless you count speed booting after a crash. It's done to (more or less) guarantee filesystem integrity after a crash. You may lose data, but you only lose writes that never completed.

So, if you are choosing ext3 with writeback, is it faster than native ext2? I don't know. But it doesn't sound like it is any safer.

Of course, if you're worried about data integrity, you will have a mirror across multiple striped drives using multiple controllers. And then use a Journaled Filesystem to improve boot time.

Z.

Re:Writeback kicking it

[cduffy]

ext3 with writeback is indeed safer than ext2, inasmuch that all corruption will be with regard to the data -- your metadata is still safe.

Now, data corruption can be a Very Bad Thing, depending on what you're doing... but in many cases, preventing metadata corruption (and thus being sure that your filesystem is always usable) is Good Enough.

Re:Writeback kicking it

[Anonymous Coward]

Nope. That's the problem. fsync() guarantees that the disk controller hardware is synced with the OS. It does not guarantee that the disk platters hold the data. It probably should, but implementing that is not always possible. Many controllers lie to look faster.

Re:Writeback kicking it

[Sabalon]

There is also an apcupsd. This way, you can have one machine that is hooked to the UPS (no need for additional hardware to let multiple machine monitor the UPS.) When power goes down, the apcupsd then lets the other servers know what is going on (power off, power on, shut down now, etc...) Ports to Unicies galore, and winders.

This all assumes that you have the network on a UPS and with the power out all machines can still talk.

Pretty nice tool with tons of options. http://www.apcupsd.org (oddly, with the exception of the what's new pages of the docs, the url isn't listed in the docs.)

Of course, I like my option - buy a UPS with enough capacity to hold the whole room for about 30 minutes (40KW) and a big ole generator in case things go down for a while.

Journaled ext3 vs Reiserfs

[Anonymous Coward]

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.

Re:Anyone care to explain ordered mode?

[*xpenguin*]

Your question is answered in the Linux ext3 FAQ

Re:ReiserFS loses data

[delta407]

You're on crack. Hash collisions incur only a performance hit, not lost data.

my decision

[salmo]

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.

Re:Speaking of losing data...

[Fluid Truth]

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.

Re:But Remember

[EllF]

*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.

Re:Can you document that?

[RockyMountain]

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.

Re:ext3 writeback vs ext2?

[sjames]

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"?

Consider a large tmp volume.

Anywhere where the consequences of finding stale data in a file are no worse than having the data simply missing after a crash. Even a src directory if you do a lot of big makes (since you're best off with make clean ; make after a crash anyway). Just be sure to sync after writing out a source file.

However, as long as performance is adequate, probably better safe than sorry when it comes to filesystems.

XFS?

[Jennifer Ever]

Any benchmarks on XFS vs. ext3/ReiserFS?

Re:ext3 writeback vs ext2?

[Guy Smiley]

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?

Well, ext3 with data=writeback is equivalent to how reiserfs has always operated (i.e. if you crash you can lose data in files that were being written to). Using data=ordered is an extra benefit that doesn't have any noticable performance hit unless you are trashing the disk and RAM in a benchmark. FYI, there are now beta patches for reiserfs that implement data=ordered.

Only the fsck time can be a big deal if you have to wait 8 hours while your 1TB storage array is fscking (8 hours is a guess, I don't have that much disk...)

Your bong had a hash collision

[gregor_b_dramkin]

... 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 /.

As always, it depends on what is on the filesystem

[SwellJoe]

Yes, folks, some filesystems are faster than others for some type of file.

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.

Re:ext3 writeback vs ext2?

[Wesley Felter]

So what's the point of running ext2 if it's exactly equivalent to ext3/writeback but with very slow fsck?

For multimedia playback?

[Jeremi]

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 use both

[JebusIsLord]

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?)

Slashdot fight agains standards.

[Nicopa]

Also: Slashdot (the founders/owners/editors) is notorious for saying one thing and doing another. Witness the virulent anti-DMCA stance, yet, notice also how they support the very companies who forced it upon us (aka Sony). Witness their yammering about IE/MS not following standards when in fact their own HTML on thier own site is grossly out of established standards.

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.

Re:ReiserFS loses data

[Morgaine]

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.