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

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.

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.

ReiserFS loses data

[Flarners]

A hash collision in a ReiserFS directory (where two filenames hash out to the same value) causes the older file to BE OVERWRITTEN without so much as a warning. This is a huge design error, and I can't believe they're pushing Reiser as a production-use filesystem. The only way to ensure you never lose data to hash collisions is to use the 'slowest' hash setting; the faster the hash function, the more likely it is to create collisions and leak data. I had a large project lost to a

Re:Anyone care to explain ordered mode?

[*xpenguin*]

Your question is answered in the Linux ext3 FAQ [spoiled.org]

Re:ReiserFS loses data

[Albanach]

SuSE have been pushing ReiserFS for some time. I've certainly been using it for what seems like ages with no noticeable problems.

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

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:I just wrote this

[on by]

Hey! That's really cool and the best part is you didn't just cut and paste it from some other site like certain [slashdot.org] other [kuro5hin.org] people [trollaxor.com].

Re:Benchmarks

[Anonymous Coward]

Does it seem odd to anyone else that *reading* the ext3fs has a 4X performance gain for writeback vs ordered?

Since ext3fs writes in a way compatible with ext2fs, shouldn't you get (at least somewhat close to) the same speed reading it nomatter how it was written?

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

Danger, Will Robinson

[Anonymous Coward]

If you are using soft updates and not running fsck after a dirty reboot, then you don't understand soft updates. You are also flirting with loss of data.

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.

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:Gurulabs background picture?

[Anonymous Coward]

I took a class from them almost 3 years ago and they were using that graphic then.

Offtopic, good class though.

Re:Writeback kicking it

[electricmonk]

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.

This is a misinformed opinion, at best. Your RAID setup will only save data in the case of hardware failure (i.e. one of your disks fails). It will do nothing about incomplete writes. The whole purpose of journaled filesystems is to ensure that writes completed, to minimize filesystem corruption. It just so happens that the way it does this allows for a faster boot, which is an added bonus.

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

[supz]

No need to devise a way of sending out a power-down signal for those with APC UPSes. They have a product named PowerChute [apcc.com] (and even a linux version!) that machines connected to a UPS can use to communicate to each other. It has configurable shutdown times, so mission critical servers can stay up for the longest time possible, while not so important ones can be shut down immediately. We use it extensively in my office, and it really lengthens the battery length on our UPS.

Also worth nothing -- we have our Exchange server begin shutdown almost immediately after the power goes out, as it takes exchange nearly 15 minutes just to shut down. We are actively looking for an alternative to Exchange.

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)

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 [w3.org] 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 [technisys.com.ar].