Slashdot Mirror
Linux File System Shootout
IpSo_ writes "Finally an extensive, human readable Linux file system benchmark has been unleashed upon us. Originally posted on the Linux Kernel mailing list, using two of the most popular benchmarking tools available, it compares all the major file systems, including their different mount options. The results are surprising."
Can someone with it open mirror it please - will not open. All I can get is a 685b file
The Singularity is closer than you think
Quant
Samba is not a file system, and as such is not in the benchmarks. RTFA and see http://samba.org
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
best: jfs
worst: ext3_journal
bonnie++ benchmark
best: ext2
worst: reiser4/reiser4_extents, ext3_ordered/ext3_journal
From what I've seen poking around USEnet, JFS seems to have the too little, too late problem. I've never seen it pwn a benchmark like it did today though.
I'm a little confused-I have been told XFS is the best designed, highest performing file system, and I would hate to think SGI is getting into a lot of this crap with SCO for a relatively slow journaling file system...
Hey, if somebody could organize this data into histograms, it'd be a lot easier to interpret the results..
IIRC, XFS is more about guaranteed performance under various stressful conditions than about getting the absolute peak speed in calm conditions.
I'm in a Unix state of mind.
Time to rethink things. The generally accepted opinions between the two are that JFS is faster for small files and XFS has a bit of an edge with larger files. Both perform very very well.
I don't know how JFS falls in the "too little to late" catagory, both file systems have been available for a long time on Linux, however very few Linux distributions embrase them during installs so they have gone unknown to a great deal of the non-storage geeks out there. Mandrake, much to their credit, has for a long time included these file systems as an install option for your root filesystem, which has always made me appreicate what Mandrakes doing.
I will say that even though JFS is probly the best high-performance choise for user workstations due to smaller file sizes on average, I prefer XFS because it has a much more robust toolset and you can get alittle more hands on with the filesystem thanks to the tools provided. But most users just don't care that much for low level tools so give JFS a twirl.
We did a lot of testing with various file systems for a product earlier this year. After a couple of terabytes of intensive reads/writes (and a couple of days...) the JFS kernel processes randomly locked up and blocked all disk I/O operations (1.1.0 and 1.1.1 versions). JFS was indeed the fastest of the file systems we tested, but we had to drop it for being unreliable.
I wonder if anyone has some experience with the reliability of the current version?
Score:1, Unread
Use XFS unless you want to do lots of deletes (as they are slow and expensive) in which case ext2 is probably a better bet since the files are probably temporary (Squid caches for example).
type "linux reiserfs" when booting the installer, and you will have access to reiserfs during redhat install.
i've been using this method for ~2 years now.
There is a difference between journaling DATA and METADATA. Don't get confused by that...
Have a look at Hans' benchmarks at namesys.com. Although he only compares Reiser4 to ext3, and may not be an objective party. But I'm surprised how well JFS performed anyway and that Reiser4 is unusually CPU-intensive.
I know we're used to seeing "benchmarks" used as corporate propaganda, but let's not forget what they're supposed to be used for
Don't let THEM immanentize the Eschaton!
Well ext3 might suck but when you've only got a resuce system that can read ext2 it can really save your neck. I would be intrested to see what is best in terms of stability though..
Rus
Cheap UK and US VPS
These benchmarks were performed on relatively old hardware, with a slow cpu and a disk only running UDMA2. And, as others have already pointed out, the data are statistically not really reliable.
Myself, I'd be much more interested in seeing numbers made on a setup more like my own.
Static benchmarks are never good for deciding "which is best".
Really? You must be looking at a different set of benchmarks to me, because as I see it, ext3 is running a close race with XFS to take second place behind JFS. Remember, ext3's journalled mode is journalling data as well, and hence it isn't fair to compare it to other filesystems directly as it's doing much more work (equally, ext2 comes out on top for a number of things because it's doing far less work). Others like reiserfs, XFS and JFS are journalling metadata only (c.f., ext3's ordered mode).
I tend to run ext3 on all of my servers, because while it's not necessarily the absolute fastest, it's fast enough, and more importantly, it's rock solid in terms of stability. I wouldn't touch reiserfs with a 10 foot bargepole for any of my machines, mostly because I don't trust it (or Hans). Now it seems even the touted performance benefits aren't really there either. I've been considering JFS for a while, and have had a test JFS filesystem running for the last few months. Maybe I'll switch, but even if I don't, ext3 is more than adequate.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Remember that this was a "perfomance test" not a "which FS is better" test. Benchmarks only show you which one is faster at specific tasks, it doesn't necessarily tell you which one's better.
As for complaints about Reiser's performance -- last I heard, it was more optimized for many small files -- precisely the domain that this thing didn't test.
"Evil company X is threatening to restrict our rights! Let's all get together to stop--OOOH! SHINEY!!!" -- AC
You forgot one thing. As an enterprise filesystem Novell was absolutely bulletproof long before RAID systems were in vogue. It took me awhile to even figure out why we needed one after years of running Novell as our main storage controller (flawlessly).
Novell could give *nix systems windows like (don't bash if you don't know) fine granularity over user access at the enterprise level along with true enterprise scaling. Again, if you have never worked in a cross enterprise environment, don't start bashing because you really can't appreciate some of Novells strengths until you need the features.
Since there was no legend explaining what the colors meant, I couldn't figure out anything from looking at them. Is the high number good? As in did the most work? Or is the high number bad? As in took the longest amount of time to do something?
Depends on the column. For K/sec, higher is better, so red cell shows lowest, and green shows highest. For %CPU, lower is better, so green shows lowest and red shows highest. It's not that complicated really if you take a few minutes to look at it. What you get from the data depends on what you were looking for in the first place.
I should probably add that I am getting quite different bonnie++ results for reiser4 vs. ext3.
0 03.09.30
They are available at reiser4 benchmarking page along with
hardware specifications.
http://www.namesys.com/benchmarks.html#bonnie++.2
Like I said, who cares about NTFS or FAT performance?
FAT performs well as long as you just do sequential access to large files. But don't access too many files at the same time, because there are only eight entries in the fat_cache. If you run over this limit or do random access FAT is going to be the worlds slowest filesystem. And that is so bad it has really caused me trouble some times.
The reality is minix is faster, cleaner, simpler, and more flexible than FAT. Just take a look on the source minix 47KB, fat 131KB. And keep in mind that minix use a a fast tree structure to locate blocks while FAT use an extremely slow linked list.
Do you care about the security of your wireless mouse?
For the same reason you would want to have email, or a file server, on a journaled system, recovery speed.
I have some clients with servers (that run squid) and when they take a power hit, long enough to drain thier UPS, the last thing I want to have to do is deal with a call saying "how come the server did not come back up..." Meanwhile the fsck is still running and they are hitting the power switch trying to "reboot" the problem away before the ext2 fsck can finish checking though the cache partition...
Thats just on reason.
If you can afford a little extra partitions, try reiserFS. Although it is not natively a part of windows, there are tools which let you use it. This means you cannot install windows on it, but you could get read-write access with it.
Back when I still dual-booted, I had this layout:
5 gig NTFS WindowsXP partition
5 gig XFS Slackware partition
1 gig swap parition
45 gig reiserFS shared storage partition
This also made me feel a lot safer in using the systems: Neither ever mounted the other system's Root directory, so all that was actually shared was what I used as my home directory. No matter what I did on one system, even if data corruption happened, it would never be so bad that I couldn't boot it. (Note: I never had data corruption, it was just a mental comfort issue)
There are some free and some commercial products which can offer full read/write + journalling access for ext3 partitions from Windows. I'd definitely recommend you pick ext3 over fat32.
Some examples..
Free: Explore2fs allows you to read ext2 and ext3. Limited write support is available.
Commercial: Ext2FS Anywhere don't let the name put you off as it has full read/write support for ext2, ext3 and I think reiserFS is supported now too.
These numbers are great, but only tell us a little about reliability or "real world" performance. When I did testing on these file system I used all the benchmarks here, plus a benchmark called postmark. This benchmark utility was released into the public domain by Net App and has to be one of the better "real world" benchmark suites.
The problem that we had with JFS during testing is that we had kernel panic with very large files. Thus we chose XFS - which has done an excellent job. I'm sure glad that the XFS file system has been merged into the 2.6 kernel, no more patching the 2.4's!
For more benchmarks on other file systems using postmark check out This
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
which makes the whole thing pretty questionable in my view, especially when you consider that Nikita got completely different results on his more modern hardware (see www.namesys.com/benchmarks.html)
I don't really target 200Mhz CPUs in my performance tuning....;-)
Hans
Never heard of Read-only filesystems?
Mount static filesystems read-only, and make them EXT2 for performance. Use a journalling FS for dynamic filesystems. Reap the benefits of both.
"You've got an invalid haircut" -Warren Zevon - Life'll Kill Ya
Um, why would you want to put squid on a journaled file system?
/etc/fstab. /var/spool/squid (or whatever) is on its own partition right? Perhaps on it's own disk?
If you're looking to restart quickly after a power failure you can always set a partition to ignore file system checks at startup, "0 0" options in
You have never waited over an hour to fsck 3 harddisks while over 100 people have no "internet".
I did some filesystem benchmarks myself and found that JFS performed well at raid levels 1 and 10, but XFS totally dominated on RAID5. At least when using dt as a benchmark program. I also ran IOzone, but do not have the results in a form that I can easily compare them.
He installed a hard drive. He didn't just format to reiser. The hard drive costs money.
If the proxy cache was formerly on a disk that was also doing other things, it would have sped up no matter what filesystem he used.
You will have to give us more information if you want your claims to have any merit.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If you read carefully, you'll notice that the name of the filesystem is SMB. Samba is software that interfaces with the SMB filesystem. Of course, SMB isn't really a filesystem either. When you want to share something you don't have to create and format a partition as SMB.
Jesus saves and takes half damage.
Think of different benchmarks as being like x-ray vs. infrared photographs. Each of them gives a different insight into the subject of the photo.
In this case, I think that this 200Mhz CPU benchmark is not highly worth optimizing for, but generally more views of a design are interesting.
One of the things reiser4 needs to do is not have a structure per unformatted node for large files, and you can see the need for that if you look at our CPU consumption when writing a large file using dd. We'll probably adjust that aspect of the design sometime in the next two months, and have a structure per extent instead of per unformatted node. If I hadn't been running benchmarks, I never would have understood that misdesign decision of mine so clearly. The nice thing is that the code will get simpler as a result of the change.