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

Anyone care to explain ordered mode?

[glrotate]

I think I know what writeback is (like with cache?), but can anyone explain ordered mode?

Re:ReiserFS loses data

[delta407]

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

...what I would like to see

[Bandito]

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.

XFS?

[Jennifer Ever]

Any benchmarks on XFS vs. ext3/ReiserFS?

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.

Why always Linux?

[evilviper]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

Re:Why always Linux?

[kryptobiotic]

Just today I was working on getting some molecular dynamics code to work on a DEC PWS 500au. This code writes some large (3GB-500MB) files to the disk. On a fresh striped down (~400MB) install of RedHat 7.1 using ext2, bonnie showed throughputs of about 20MB/s for sequential read/writes of a 512 MB file.

On a fresh install of FreeBSD 4.6 using UFS, bonnie reported more than 30 MB/s on the same machine.

I know this isn't really what you were looking for but it surprised me that there was that much of a difference.

Re:Why always Linux?

[m.dillon]

Just for the hell of it I ran the same benchmarks on one of my test boxes (FreeBSD running -current). The performance basically comes down to how much write latency you are willing to endure... the longer the latency, the better the benchmark results for the first two tests.

So, for example, with the (conservative) system defaults I only got around 250 trans/sec for mixed creations with the first postmark test, because the system doesn't allow more then around 18MB of dirty buffers to build up before it starts forcing the data out, and also does not allow large sequential blocks of dirty data to sit around. When I bump up the allowance to 80MB and turn off full-block write_behind the trans rate went up to 2776/sec. I got similar characteristics for the second test as well. Unfortunately I have only one 7200 rpm hard drive on this box so I couldn't repeat the third test in any meaningful way (which is a measure mostly of disk bandwidth).

In anycase, the point is clear, and the authors even mention it by suggesting that the ext3 write-back mode should only be used with NVRAM. Still, I don't think they realize that their RedHat box likely isn't even *writing* the data to the disk/NVRAM until it absolutely has to, so arbitrarily delaying writes for what is supposed to be a mail system is not a good evaluation of performance. Postmark does not fsync() any of the operations it tests whereas any real mail system worth its salt does, and even with three drives striped together this would put a big crimp on the reported numbers unless you have a whole lot of NVRAM in the RAID controller.

I do not believe RedHat does the write-behind optimization that FreeBSD does. This optimization exists specifically to maximize sequential performance without blowing up system caches (vs just accumulating dirty buffers). But while this optimization is good in most production situations it also typically screws up non-sequential benchmark numbers by actually doing I/O to the drive when the benchmark results depend on I/O not having been done :-).

Last thought. Note that the FreeBSD 4.6 release has a performance issue with non-truncated file overwrites (not appends, but the 'rewrite without truncation' type of operation). This was fixed post-release in -stable.

-Matt