Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Linux Filesystems Benchmarked

Comments Filter:
  • Not a clear winner (Score:5, Interesting)

    by stecoop (759508) on Tuesday May 11, 2004 @10:05AM (#9116155) Journal
    These charts make the choice of which file system to use clear as mud. What is the charts really saying? From what I gather, it appears that:

    EXT2 has better throughput

    EXT3 has better file handling capablities

    Reiser has better search ablity

    XFS has better delete capablities

    JFS may be a better choice in regards to file manipulation Subject to debate of course...

  • Slightly OT (Score:3, Interesting)

    by iReflect (215501) on Tuesday May 11, 2004 @10:09AM (#9116188) Homepage
    This is good information to know, but for a project I'm working on I need to know which filesystem can take the most abuse. I'm talking about power-outages and hard-resets mostly. I know I should go journalled, but which one? What else should I keep in mind.
  • Hrmmm (Score:4, Interesting)

    by nizo (81281) on Tuesday May 11, 2004 @10:16AM (#9116276) Homepage Journal
    See the whole article and a full range of hideously colored full sized graphs here [209.81.41.149] before it gets slashdotted too. Speaking of which, there has got to be better graph making software out there in Linuxland......
  • by dduardo (592868) on Tuesday May 11, 2004 @10:16AM (#9116277)
    Right now I'm running reiserfs under gentoo and I recently lost some rather important data, which has made me a little skeptical in using it in a production system. Therefore I'm asking you guys which filesystem do you think is good for a webserver that will be handling a medium sized database and a significant number of transacations each day.
  • by Anonymous Coward on Tuesday May 11, 2004 @10:23AM (#9116333)
    It would be nice to see an unbiased comparison with NTFS (though it would be difficult seeing as how you can't get it to run natively on *nix afaik)
  • It works for mine! (Score:5, Interesting)

    by MarcQuadra (129430) * on Tuesday May 11, 2004 @10:26AM (#9116369)
    I've been using ReiserFS _EXCLUSIVELY_ since about 2.4.11 and I've never had a single problem. It's important to format with the defaults and not specify 'special' arguments to mkreiserfs or you can run into trouble.

    I've got three systems currently running reiser on Gentoo, from my PowerPC/SCSI/NFS/Samba file/print server to the ancient Compaq laptop with a 4GB drive. I've never had as much as a hiccup from ReiserFS.

    Under what circumstances did you lose data?
  • by jaylee7877 (665673) on Tuesday May 11, 2004 @10:27AM (#9116376) Homepage
    I've never understood why they don't move to ReiserFS, at least for new installations. With Fedora you have to use a kernel option to enable ReiserFS installation and with RHEL you can't install to a ReiserFS root, even the reiserfs kernel module is in their kernel-unsupported RPM which means don't call for help. I love RH but they need to get the ball rolling on this one!
  • by molarmass192 (608071) on Tuesday May 11, 2004 @10:33AM (#9116427) Homepage Journal
    I use JFS and it's been pretty good thus far. It's been around for a long time and it's backed by IBM, so that makes it a pretty safe bet for production use in my mind. I used to use Ext3 before that and experienced a few data losses that caused me to make a switch. I can't comment on Reiser or XFS since I haven't used 'em.
  • by lord_dut (306314) on Tuesday May 11, 2004 @10:40AM (#9116503) Homepage
    XFS supports defragmentation
    http://oss.sgi.com/projects/xfs/manpages/xfs_fsr.h tml [sgi.com]
  • by Mr Smidge (668120) on Tuesday May 11, 2004 @10:42AM (#9116522) Homepage
    I have ran reiserfs on my fileserver ever since it existed, and like you it corrupted once and I lost data.

    However, I pinned it down to a faulty drive (Quantum Fireball, hehe, which never acted up under NTFS/Win2k.. oh well). I was close to blaming reiserfs, but once I put in a quality hard drive and reinstalled, it's run like clockwork. Perfectly.

    There sure haven't been too many stabilty issues with reiserfs in my experience. Try another drive as a test and see if the same happens.
  • by Lxy (80823) on Tuesday May 11, 2004 @10:44AM (#9116552) Journal
    I agree, it would be an interesting test. If I'm not mistaken, NTFS is a journaling filesystem as well. Its databasing design is really interesting to me.. is there something similar to this in linux journaling filesystems?

    WinFS is designed to utilize the database feature, I'd be really curious about the results of searching for a file in NTFS/WinFS versus a linux file system. Hopefully NTFS linux support improves to the point where we can safely use it as a linux filesystem.

    Data recovery is my biggest issue right now with linux. It's damn near impossible to rescue data off a failed linux disk. Even just deleting a file is tough to recover from. NTFS has a nice selection of tools (albeit non-free) to safely and reliably recover data.
  • by mi (197448) <slashdot-2012@virtual-estates.net> on Tuesday May 11, 2004 @10:49AM (#9116608) Homepage
    From FreeBSD, that is... Would be nice to see that compared to Linux' FS-es. As in this earlier benchmark [usenix.org] (PDF).
  • by MarcQuadra (129430) * on Tuesday May 11, 2004 @10:56AM (#9116671)
    What was the reason for the panic? I've been running my system HARD for years without any panics.

    If your hardware or kernel has problems you can hardly blame a filesystem that's expressly designed for high-reliability hardware for data loss.

    'journalling' is not any better than none when it comes to flaky hardware or a badly compiled kernel. All it means is that you don't have to wait an hour for fsck to run. The whole point of a journalling FS is that it 'knows' what files are suspect after a major outage and it quarantines them, it's not any better at preventing them from being corrupted.

    All in all, I can say that Linux an other Unices are VERY sensitive to improper halts/panics/shutdowns. I've hosed several OS X machines by not exiting gracefully, and several Linux boxes too. Your number-one priority when setting up a system is to do what it takes to keep it from crashing, ever.

    When I built my desktop I carefully selected components that were 100% Linux-compatible so I wouldn't have issues like the ones you described.
  • HFS+ (Score:3, Interesting)

    by mbbac (568880) on Tuesday May 11, 2004 @11:01AM (#9116738)
    Does anyone have any statistics for how HFS+ [apple.com](testable with Darwin [apple.com] stacks up against these other filesystems?
  • by 13Echo (209846) on Tuesday May 11, 2004 @11:06AM (#9116775) Homepage Journal
    I use ReiserFS, because on average - it is a faster filesystem than EXT3 for most desktop purposes. I personally feel that EXT3, however, is a more reliable FS when it comes to recovering bad data on the hard disks. I recently had some failures due to a failing motherboard, which corrupted some data on my drive, but the reiserfsk tools have cryptic descriptions for failures and don't always seem to do the job right when it comes to recovering bad data. I've had reiserfsck work properly, but the few times that I have had hard drive failures, I've had little success in recovering bad data on a ReiserFS partition.

    I must admit though, that any problems I've had on a ReiserFS system weren't necessarily the fault of the filesystem (instead were related to failing hardware). I've run several machines, with multiple drives, which all use ReiserFS. It's been quite reliable in that sense.

    I guess that the only way you're going to get true reliability is to make redundant backups.
  • by flaming-opus (8186) on Tuesday May 11, 2004 @11:15AM (#9116858)
    Well, the simplest answer is that Stephen Tweedie is their filesystem guru, so why not use his baby in their OS. However, that's not the real answer. SCT is a clever guy, and mature enough to not let pride get in the way of the best possible system. (a similar question: Why does sun still use UFS?) For Redhat, EXT3 is probably the best general purpose filesystem, particularly for the root drive. Redhat is interested in selling on servers, where the root filesystem is not the bottleneck. You install the OS onto EXT3, which has decent performance and is very mature. Then you install your database / exported directories / mail spool / whatever onto the filesystem that is best for that job.

    Ext3 is a very close cousin to Ext2, which has been around for a very long time, and changes very slowly. Reiser has grown and changed a LOT in the last three years, including some metadata changes that effect on-disk structures. Though it has stabalized lately, Redhat is correct to be cautious. XFS and JFS, though very mature filesystems on other OSes, have only recently become tightly integrated with the Linux kernel. Though technically controlled by the linux kernel community, all three of these other filesystems are really controlled by little cabals of people within IBM/SGI/ and then Hans Reiser. While these groups try to be transparent in their development process, Ext3 is very transparent in its development and direction.

    One other tremendous advantage that Ext3 inherits from Ext2 is a fast, versatile, and effective fsck program. Journals are great in the event of power failures. However, they do not protect against Windows, or a faulty fibre channel driver, or uninformed sysadmin who accidently writes over the first 1 MB of the disk. Fsck.Ext2 is one of the best around.
  • by Cthefuture (665326) on Tuesday May 11, 2004 @11:31AM (#9117017)
    Seriously, all the time we see benchmarks like this that are just done on the same machine with the same setup. Who knows if there is some unseen problem or bottleneck (in this particular case the CPU is weak).

    We need a large sample base. Different types of chipsets, CPU's, hard-drives, etc. Then we can better see the big picture or at least see how the filesystems might perform on a system similar to your own.

    So I'm calling for a "filesystem benchmark" page were people can post their results from a standard set of benchmarks. Something where they can include their system specs/setup and everything.

    Then maybe we'll get useful information.
  • by pclminion (145572) on Tuesday May 11, 2004 @11:31AM (#9117023)
    The old-school trick is to back up the file system to tape, reformat the disk and do a restore.

    These days you could just use a second disk. It would be faster, too.

    I wonder if there's some way for a RAID to constantly, dynamically optimize itself. After all, it's striped and redundant, there must be all kinds of funky tricks you can play to reorganize data on the fly...

  • by Lussarn (105276) on Tuesday May 11, 2004 @11:47AM (#9117157)
    I can't see the slashdoted page but if you have a mailserver and are using maildirs (qmail) ReiserFS is a good choice because you will have alot of small files. Reiser can use the space on your disk fully and are not limited to "at least as big as the blocksize".

    I have a mailserver which have about 20GB mail with Reiser. With Ext3 it would be over 30GB.
  • by flaming-opus (8186) on Tuesday May 11, 2004 @11:50AM (#9117182)
    While GFS is a fine filesystem for a cluster, I'm not sure what use it will be in a non-cluster environment. There's a lot of things you have to do in a cluster filesystem to ensure data consistency between nodes. It is true that a non-cluster GFS can replace a lot of these functions with a nop, but it still affects the way you structure the code.

    GFS has a nice, relatively asynchronous journal implementation. However, I don't know that it will perform well on small file I/Os, particularly deletes. It's also somewhat complicated to configure and manage. Seems like a real bother if you're not going to use it in a cluster.
  • by hansreiser (6963) on Tuesday May 11, 2004 @12:20PM (#9117527) Homepage
    ReiserFS V3 is being obsoleted by V4, which is 2-5x times faster.

    You can see benchmarks of it at www.namesys.com/benchmarks.html [namesys.com]

  • Re:Slightly OT (Score:3, Interesting)

    by LinuxHam (52232) on Tuesday May 11, 2004 @12:22PM (#9117556) Homepage Journal
    EXT3 can shrink, but I don't know about the others

    I've heard that EXT3 cannot shrink and that ReiserFS is the only one that can. While not a demo of shrinking, here's [ibm.com] part 2 of a 3-part series of articles on using ReiserFS with LVM. This segment shows off resizing a partition without even unmounting it!
  • by Anonymous Coward on Tuesday May 11, 2004 @12:28PM (#9117647)
    XFS's real talent is hidden in recovery. It is meant for DB of sizes in Terabytes++ , and it's XFSchk is usaully almost instant (definately compared to other FSes). Basically no one is going to wait 2 days for a 600 terbyte db to chkdsk when XFS will recover in hours (or less). Will you lose files? probably, but that is what back-ups are for, and now your DB is up and running. Restore and go in hours not days....
  • by demon4 (778594) on Tuesday May 11, 2004 @12:45PM (#9117878)
    so what would be a good filesystem to use for a pvr (personal video recorder)? How about for a mail server or web server? XFS i am guessing for the pvr and reiser for the others.
  • by sudog (101964) on Tuesday May 11, 2004 @01:44PM (#9118610) Homepage
    A superior string of tests would be to simulate, to as close a degree as possible, a real, live high-use environment such as a scaled-up Perforce server, a supremely busy mail server, a giant busy database, or a massive web server.

    A single process running through 10,000 files isn't particularly realistic: since when does a scaled-up server sit there and hammer the filesystem with just a single process? What about contention? Caching?

    And what about recovery from errors? I didn't once see what happens if something blorts over random parts of the filesystems.. how does Reiser handle this? Ext3? XFS? Are there recovery tools in case of catastrophe?

    What about these file systems stuffed into RAID volumes of various stripe sizes and configurations?

    Straight deletes, creates, or modifications are useless because the only time you're going to be doing something like that is when you rm -rf * or building a new environment for.. something. Daily use, however, which eats up far more time (and thus would save the most user time if improved) is something which should been better accounted-for.
  • by NerveGas (168686) on Tuesday May 11, 2004 @03:19PM (#9119556)

    My mail server's been chugging along for about 4 years now, and is terrifically reliable. So, I turned off the fsync() calls, so things like that don't really matter any more, as the kernel's disk cache can do what it was designed to do. Throughput went up by more than a factor of ten.

    Some day, a fan, power supply, or UPS will die. But getting 10x the performance for 4+ years justifies losing the two minutes worth of email that wasn't flushed to disk when that day comes.

    steve
  • Sun uses UFS because it is still the best filesystem for a root filesystem.

    • It supports software mirroring of the root FS in solaris.
    • It's backwards and forwards compatible.
    • It does not require any license fees, since it's been worked on in-house.
    • It already supports logging, which provides the benefits of journalling and a substantial performance boost.
    • UFS also has alternate superblocks, like all modern filesystems. (Including JFS and XFS!)

    A more interesting question is: Why do Linux zealots incessantly rag on UFS?

  • by Brandybuck (704397) on Tuesday May 11, 2004 @03:42PM (#9119773) Homepage Journal
    Except that Softupdates isn't a journaling filesystem. Linux users have been brainwashed into believing that they need journaling.

    For more info on softupdates versus journalling, see Soft Updates [usenix.org] and Journaling versus Soft Updates [usenix.org].
  • by haute_sauce (745863) on Tuesday May 11, 2004 @03:53PM (#9119875)
    ...time to fsck, and recovery after a crash for the journaled file systems ? These are of greater importance to me than 10000 deletes. How long will it take to verify my file system of 300GB after the sysadmin killed power to the wrong server ? Did I lose any data ? you know the drill.
  • by bani (467531) on Tuesday May 11, 2004 @05:14PM (#9120661)
    Just some datapoints to counter yours:

    We (ISP) had about 5 major data loss disasters with ext3, 3 with XFS and only 1 with reiserfs.

    And we use far more reiserfs than ext3 or xfs. So from a reliability standpoint for us, reiserfs is by far more reliable than ext3 or xfs.
  • JFS (Score:3, Interesting)

    by oohp (657224) on Tuesday May 11, 2004 @05:31PM (#9120794) Homepage
    Although less hyped, JFS is doing pretty well so I see. I've been checking out other benchmarks as well. Some people mentioned it's even faster than XFS in some cases. I myself am using Reiser but I'm looking forward to checking out JFS in the future. It's been in the kernel long enough to have stabilized. XFS in kind of young in 2.4. Yes it has exsited before as a patch but I won't use anything on production systems until Linus accepts it in the mainstream kernel.
  • by jean-guy69 (445459) on Tuesday May 11, 2004 @07:27PM (#9122091)
    because no mount options where used.
    if you really matter about filesytem performance you'll use some options like disabling access time updating.

    ext2 should be mounted with noatime, reiserfs with noatime,notail,nodiratime etc..

    not using the usual performance-oriented mount options (only the ones that don't compromise FS security)
    makes this benchmark a lot less meaningful :(

  • by arcade (16638) on Wednesday May 12, 2004 @02:32AM (#9124401) Homepage
    Now, you will not hear me say that you should not use ReiserFS, for a desktop it is probably the best choice, but for servers, please think again.

    It's only the best choice if used by computer literate people.

    I've had to travel 500km one time too much to fix a reiserfs-using-desktop-computer that didn't want to boot due to ReiserFS spitting out strange error messages and waiting for input.

    Not having heard the messages before, nor managing to discern them over the phone, I finally had to travel far too long just to fix the damn computer.

A bug in the code is worth two in the documentation.

Working...