Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Ext3 vs ReiserFS benchmarks

Posted by CmdrTaco on from the numbers-and-rollbacks-and-journals-oh-my dept.

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

9 of 191 comments (clear)

  1. Writeback kicking it by jred · · Score: 3, Informative
    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.
    --

    jred
    I'm not a mechanic but I play one in my garage...
    1. Re:Writeback kicking it by Anonymous Coward · · Score: 3, Informative

      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.

  2. Journaled ext3 vs Reiserfs by Anonymous Coward · · Score: 3, Informative

    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.

  3. Re:Anyone care to explain ordered mode? by *xpenguin* · · Score: 4, Informative

    Your question is answered in the Linux ext3 FAQ

  4. Re:But Remember by EllF · · Score: 4, Informative

    *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
  5. Re:ext3 writeback vs ext2? by Guy+Smiley · · Score: 3, Informative
    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...)

  6. As always, it depends on what is on the filesystem by SwellJoe · · Score: 5, Informative
    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.

  7. For multimedia playback? by Jeremi · · Score: 3, Informative

    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.
  8. Slashdot fight agains standards. by Nicopa · · Score: 3, Informative
    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.