Benchmarking Linux Filesystems Part II 255
Anonymous Coward writes "Linux Gazette has a new filesystem benchmarking article, this time using the 2.6 kernel and showing ReiserFS v4. The second round of benchmarks include both the metrics from the first filesystem benchmark and the second in two matrices." From the article: "Instead of a Western Digital 250GB and Promise ATA/100 controller, I am now using a Seagate 400GB and Maxtor ATA/133 Promise controller. The physical machine remains the same, there is an additional 664MB of swap and I am now running Debian Etch. In the previous article, I was running Slackware 9.1 with custom compiled filesystem utilities. I've added a small section in the beginning that shows the filesystem creation and mount time, I've also added a graph showing these new benchmarks." We reported on the original benchmarks in the first half of last year.
Very interesting article... (Score:5, Interesting)
Re:Very interesting article... (Score:3, Insightful)
Re:Very interesting article... (Score:2)
Re:Very interesting article... (Score:3, Interesting)
If you're actually using that disk, still, have a look at it with smartctl. In particular, run "smartctl -t long" on it, and have a look at the results. If it doesn't pass that, don't even think of trusting it with your data.
Re:Very interesting article... (Score:3, Interesting)
I'd look through the Namesys page, but it's large and the TOC didn't reveal any warnings.. or I wasn't looking hard enough.
I think trying on a P2 266 is a bad idea (Score:5, Interesting)
For a decent benchmark of how filesystems work on modern hardware: use modern hardware.
Re:I think trying on a P2 266 is a bad idea (Score:2)
It actually sounds like Reiser would do really well as a disk controller in a dedicated drive array. I wonder if anyone has put embedded Linux on such a device, to act as a Reiser RAID controller...
Re:I think trying on a P2 266 is a bad idea (Score:2)
Consider the purpose of the computer when choosing the filesystem? Yep, can't argue with that.
One other point I thought of just after posting my first comment is that CPU power is growing far faster than IO resources are growing, so changes in the technological environment are causing CPU-using filesystems to be increasingly a good idea.
And here's a benchmark which backs up what I was suggesting [kerneltrap.org]. It shows Reiser4 as being the fastest, and the most CPU-using, of the 5 main journaling filesystems. And
Re:I think trying on a P2 266 is a bad idea (Score:4, Insightful)
If you look at the charts, the "editing" doesn't help either. For example one cpu usage chart showed a range starting @ 92% and ending @ 94%. The Rieser4 bar was 3x as long as the next bar, but guess what, it was using something like
Re:I think trying on a P2 266 is a bad idea (Score:2)
How much better are we talking here? (Score:2)
See my second post in this thread, I give a link to a benchmark where Reiser is twice as fast as its nearest competitor.
Re:I think trying on a P2 266 is a bad idea (Score:3, Informative)
OT: Sig (Score:2)
Myren
Interesting? How about a DECENT one? (Score:5, Interesting)
OK, so ext3 is not the fastest filesystem on earth. But it has some default options which makes it suck even more than it usually do, and those options are *documented* in Documentation/filesystem/ext3.txt
* Ext3 does a sync() every 5 seconds. This is because ext3 developers are paranoid about your data and prefers to care about your data than win on benchmarks. Syncing every 5 seconds ensures you don't lose more than 5 seconds of work but it hurts on benchmarks. Other filesystems don't do it, if you are doing a FAIR comparison override the default with the "commit" mount option
* ext3's default journaling mode is slower than those from XFS, JFS or reiserfs, because it's safer. When ext3 is going to write some metadata to the journal, it takes care of writting to the disk the data associated to that metadata. XFS and JFS journaling modes do *not* care about this, neither they should, journaling was designed to keep filesystem integrity intact, not data, ext3 does it as an "extra", and it's slower because of that. But if you want to do a fair comparison, you should use the "data=writeback" mount option, which makes ext3 behave like xfs and jfs WRT to journaling. Reiserfs default journaling mode is like XFS/JFS, but you can make it behave like the ext3 default option with "data=ordered"
ext3 is not going to beat the other by using those mount options, but it won't suck so much, and the comparison will be more fair. And remember: ext3 tradeoffs data integrity for speed. There's nothing wrong with XFS and JFS, but _I_ use ext3.
Re:Interesting? How about a DECENT one? (Score:2)
Re:Interesting? How about a DECENT one? (Score:2)
It still loses on others. benchmarking it properly can change things...
Re:Interesting? How about a DECENT one? (Score:2, Interesting)
touch files - slowest
find files - fastest
remove files - fastest
make directories - slowest
find directories - second best
remove directories - best
copy tarball to cur disk - middle of the pack
copy tarrball to other disk - middle of the pack
untar kernel - fastest
tar kernel - second best
remove kernel sources - fastest
copy tarball - fastest
create 1GB file - fastest
copy 1GB file - fastest
spilt 100MB -
Re:Very interesting article... (Score:2)
Furthermore, once you get into that high-end of a system, you're generally not all that interested in "general purpose" benchmarks. I have a lot of experience benchmarking filesystems on high-end systems. (15GBytes/s and so on) I
Re:Very interesting article... NOT! (Score:5, Insightful)
I've got a screaming Dell 1.6 GHz P4 to test with and here are my results for a couple of tests it only has ext3 and a whatever cheap harddrive came with the box. I'm not sure if dma is enabled or if I've done any hdparam tunings, but I'm not sure of their test system either:
my touch 10,000 files: 24.314 seconds theirs 48.25
I used a shell script that called
Now if I use a Perl open() call, I get 8.887 seconds
Now with a cheesy C that uses fopen() and fclose() I get 4.639 seconds
my make 10,000 directories: 56.832 seconds theirs 49.87
that is a shell script
If I user perl, I get 35.171 seconds
The
The copy kernel stuff to and from a different slower disk with an unknown filesystem on it is useless.
The split tests are not indicative of anything in real life, and they took on order of between 60 seconds and 130 seconds to perform on their 500MHz system with most being in the 130 second range. I got 16.547 seconds.
I do not see how any relevant information can be obtained from this article. I'm disappointed in the Linux Gazette and Slashdot for printing this information.
Need to be careful... (Score:3, Insightful)
I would agree (Score:2, Informative)
Re:I would agree (Score:5, Interesting)
There is the classic example from the Reiser website. If your password file gets hacked, you have to ditch the whole file if you're using traditional file systems. You only know whether or not the file's been changed. However, with the Reiser system, it can tell you *what line*, and thus which user/password, was changed.
That's just a taste of where you can go with the ReiserFS. There are other things coming down the pipe; check out the reiser website for a better idea of the new features that ReiserFS promises.
How is ext3 mediocre? (Score:2)
I was pretty surprised by ext3's performance. I also read the article.
How is ext3 mediocre? Default limitations is how (Score:2)
EXT3 has a lot going for it, but the default compile options (at least the ones used by several of the popular packagers) make
Re:How is ext3 mediocre? Default limitations is ho (Score:2)
Re:How is ext3 mediocre? Default limitations is ho (Score:2)
Re:I would agree (Score:5, Insightful)
Huh? Sorry, did you read the same graphs or are you just trolling?
This article shows that ext2 and ext3 are close to the top performer in most tests and do not have many "worst-case scenarios" (unlike, e.g. Reiser3 and Reiser4).
If there is anything that you can conclude after reading this study, it is that ext3 is a reasonably good default choice for a filesystem.
wrong conclusions (Score:2)
JFS, XFS, and ReiserFS are small players with a fraction of the user community and a fraction of the tools and support; their performance would have to be astounding in comparison to Ext3 to even consider them, but it isn't.
Unfortunately, benchmark-happy people like you, people who optimize for the wrong thing, are far too frequent in this industry.
Re:wrong conclusions (Score:2)
Re:I would agree (Score:2, Redundant)
I think the ReiserFS mount times in the benchmark are misleading. From my experience, mkreiserfs creates an extremely basic file system; the first time you mount it, the file system driver itself will do a lot of heavy housekeeping, which takes ages. Subsequent mounts ar
Re:I would agree (Score:2)
D'oh!
But what's the sleep in aid of? It'll achieve precisely nothing --- the sync will block until all I/O is complete.
Re:I would agree (Score:2)
D'oh!
But what's the sleep in aid of? It'll achieve precisely nothing --- the sync will block until all I/O is complete.
Maybe it's to flush from the internal drive cache to the platters? Just because the OS says the data is flushed doesn't mean the data is flushed...
Re:I would agree (Score:3, Interesting)
Reiser4 now defaults to journalling everything - file data as well as metadata. If they left it like that, then no wonder it's slower - but it's the best choice if data integrity is important.
Re:I would agree (Score:2)
Best choice for you, perhaps. If data integrity is important, then reiserfs is the last place I'd be looking. I'd be going with ext3 with data journalling enabled.
Re:I would agree (Score:2)
Re:I would agree (Score:2)
Reiser eats filesystems like popcorn. I have used it for around a couple of months on two boxes, and in both cases every file bigger than around 4KB went to hell; in one case on the whole filesystem and in a big subtree in the other. I'll be damned if I ever give it another try, especially considering that other FSes trump it speedwise as well.
Why? ReiserFS has an order of magnitude more code than ext3, and more than twice a
Re:I would agree (Score:2)
Well, that's the opposite of my experience. When I got fed up with fsck times with ext2, I tried ext3 only to have it unreadably corrupted within a few months. Since then I've used reiser on every system I have, with no problems (including the same disk that was trashed by ext3
Re:I would agree (Score:2)
Re:I would agree (Score:3, Interesting)
Any time I've lost a drive to data corruption it was formatted Reiser, every attempt at using Reiser eventually resulted in massive data corruption. This was various hardware and distros. I don't know about the newest version but trice bitten forever XFS for me.
Re:I would agree (Score:3, Insightful)
How the hell did you come up with that opinion ?
Ext3 came 1st or 2nd in 24 out of the 40 tests done. If you were producing an OS for general purpose computing, would you use a specialist fs or the best performing general purpose
Re:I would agree (Score:3, Insightful)
It's amazing that such commentaries are moderated interesting these days. So, uh, fedora developers are stupid and you're smarter than them?. Please take a look at this [slashdot.org] commentary to understand why such decisions aren't so simple. You can tune your car's engine and it'll be faster, right? But why not everybody tunes their engines?
Let me quote a ext3 paper: "The ext2 and ext3 filesystems on Linux are used by a very large numbe
excep (Score:2)
Not exactly what I would call state of the art. The test results seem valid for a home server that you built out of left over parts but not for much else.
Did he compile the FSs himself? If so what optimizations did he use with the compiler.
I don't get the importance of deleting thousands of directories. Do you do that all that often? Why would you?
What was the point of the test? What environment where they trying to test for?
Desktop?
Home server?
Small office
Re:ZFS? (Score:2)
Re:Need to be careful... (Score:5, Insightful)
Unfortunately, that graph is rather misleading. The ext2 and ext3 filesystems keep some percentage of the disk space as "reserved" and only root can write to this reserved area. This is useful if the disk contains /var or other directories containing log files, mail queues and other stuff. Even if a normal user has filled the disk to 100%, it is still possible for some processes owned by root to store some files until an administrator can fix the problem. On the other hand, if your filesystem contains only /home or other directories in which users are not competing for disk space with processes owned by root, then it does not make much sense to have a lot of disk space reserved for root. That is why you should think about how the filesystem is going to be used when you create it, and set the amount of reserved space accordingly.
The default behavior for both ext2 and ext3 is to reserve 5% of the disk space for root. You can see it in the section Creating the Filesystems from the article:
You can change this behavior with the -m option, specifying the percentage of the disk space that is reserved. The article did not mention how the filesystem was supposed to be used if it had been used in production. However, I would guess that the option -m 0 or maybe -m 1 could have been used in this case. This would have provided a fair comparison and suddenly you would have seen all filesystems in the same range (close to 373GB available), except maybe for Reiser3.Re:Need to be careful... (Score:3, Informative)
As
Hardware mismatch (Score:5, Interesting)
Re:Hardware mismatch (Score:3, Informative)
From TFA: ReiserFS takes a VERY long time to mount the filesystem. I included this test because I found it actually takes minutes to hours mounting a ReiserFS filesystem on a large RAID volume.
Looks like this guy makes a habit out of using systems with 500MHz CPUs... my dual 3GHz xeon box m
Re:Hardware mismatch (Score:3, Insightful)
> even 500mhz is overkill.
Not for ReiserV4
Seriously though, there's nothing wrong with designing a new filesystem to take advantage of modern CPU horsepower as long as everyone understands the system requirements.
Here's what's missing (Score:5, Interesting)
Re:Here's what's missing (Score:2)
Thanks.
Re:Here's what's missing (Score:2)
Re:Here's what's missing (Score:2)
Re:Here's what's missing (Score:3, Informative)
Since the benchmarks presented are so rudimentary anyway, this is maybe not the first thing to worry about.
SATA? (Score:2)
Re:SATA? (Score:3, Informative)
There are patches for libATA that enable NCQ, but they're not in the mainline yet.
The only thing worse than testing without the new technologies would be testing with half-baked implementations of them. Let's wait until NCQ is done before we try testing
Re:SATA? (Score:2)
Forget SATA (Score:2)
Warning (Score:3, Informative)
Re:Warning (Score:4, Insightful)
Re:Warning (Score:3, Interesting)
ext3 and reiser at least let you fsck read-only mounted filesystems.
I brought up this problem to xfs developers and their response was "well, it's not a problem on SGIs so we're not going to fix it". Nice.
Re:Warning (Score:2)
Re:Warning (Score:2)
Re:Warning (Score:2)
I don't know about the setup being tested, but when I ran Reiser on a very large (many Tb) file system I discovered it gets slower the larger the filesystem, after a while its simply to slow to use. So while it may "support" large file systems, I'm betting no one has plugged it into a 50Tb file system to see if it really wo
Re:Warning (Score:2)
XFS is a mature, stable, and very versitile filesystem. This FS shines best when used with fast disks and battery-backed caching RAID controllers. I am using it quite successfully with Slackware 10.1, and cheap IDE RAID controllers for homebrew NAS, as well as a PostgreSLQ server. SGI was very generous in releasing XFS source and dedicating resources to the OSS community. The CXFS, or Cluster XFS version of this filesystem would rock Linux if/when it becomes available.
how to lie with statistics (Score:5, Insightful)
A quick glance shows ReiserV4 as much more CPU intensive, you have to look at the scale to realize it only used 0.3% more CPU.
somewhat worthless (Score:5, Insightful)
Slow processors, compiling (Score:2)
So I'd agree that these tests aren't worthless, but they're only a start.
Also useful would be running these tests with a faster cpu to see how things change. The CPU might be a bottleneck in some cases it would be interesting to see how the picture changes. The CPU utilization went to 100% on many of his tests.
You could also try some tests with a filesystem mounted in memory to see where seek time becomes a bottleneck. Be
Sample size (Score:2, Insightful)
Am I reading this "benchmark" correctly? Did he base his results on a sample size of 1?
At the very least, you run multiple times and average the results to give statistically meaningful numbers. I can't think of ANY time where a sample size of 1 was meaningful for anything.
What would be really interesting is to come up with a reasonable UCL and LCL for each test, and then calculate out a cpK for each test. It's one thing to say "I got these results one time", it's something much more impressive to say
Re:Sample size (Score:2)
No you're not, and no he didn't. FTFA:
Re:Sample size (Score:2)
At the very least, you run multiple times and average the results to give statistically meaningful numbers. I can't think of ANY time where a sample size of 1 was meaningful for anything.
Why isn't there a -10 Wrong moderation option?
From the weak FA:
NOTE1: Between each test run, a 'sync' and 10 second sleep
were performed.
NOTE2: Each file system was tested on a cleanly made
It would be nice if... (Score:5, Insightful)
Normalized results (Score:4, Informative)
JFS won
EXT2 and EXT3 took 17% longer than JFS
XFS took 29% longer than JFS
Reiser3 took 38% longer than JFS
Reiser4 took 52% longer than JFS
Now, 1.52 seconds is not a whole lot longer to wait than 1 second. With any luck we'll see a post from Hans explaining why Reiser4 took longer, or what sacrifices were made to make the others faster, if there are any.
Re:Normalized results (Score:5, Insightful)
If you want to use parts from 1997 to build a computer, Reiser is not for you. 500mhz is at least 8 year old technology if I remember correctly.
Re:Normalized results (Score:2)
Re:Normalized results (Score:2)
Celeron 300A was Spring/Summer of `98. I cant imagine it took Intel a full 18 months to go from 450 mhz on the cheap end to 500 mhz on the fast end.
Those were the days. I still have a couple old Alpha heatsinks with what must've been an AMAZING 50 mm fan, weighing almost a whole third of a pound of solid aluminum. HA, fantastic. Two of the BP6's I built are still alive and kicking today. Dual powered celerons, whoo.
Compare that to my <a href="http://ww
Re:Normalized results (Score:2)
Re:Normalized results (Score:2)
Re:Normalized results (Score:2)
On the other hand, if you're running a database, yes, you need all the cpu you have. The question then becomes, how much I/O do you get per unit of CPU, but the situation is very complex; its not necessarily some easily reducable linear system. It could be that you get, for ex
Re:Normalized results (Score:2, Interesting)
While I basically agree with you, 500MHz is not four times slower than 2 GHz. However in this case it is probably worse, since a 500MHz PIII implies a slow 100MHz side bus, slow 33MHz PCI bus, slow PC100 memory. A terrible system for doing benchmarks in 2006! It is completely unrepresentative of anything.
Actually, I am getting angrier as I write this. It was just wrong to publish an article using such an outdated system. People worried about high FS performance are not going to be using anything like tha
Re:Normalized results (Score:2)
If you want to use your CPU for things other than handling the filesystem, Reiser is not for you. If you know that having enough RAM to hold currently used files, Reiser is not for you. If you want a filesystem that is good at quickly creating/deleting a lot of small files (compiling, etc: JFS), ReiserFS is not for you. If you want a good linear throughput (video processing: XFS), ReiserFS is not for you. If you want somethin
Re:Normalized results (Score:2)
It's bad enough when video games call you and idiot because you don't have last week's video card, but it's crossing the line with file system authors call you an idiot because you don't have last week's CPU.
If the CPU ain't broke, don't throw it away!
Re:Normalized results (Score:4, Insightful)
It's another to say "Let's use more CPU (which is usually relatively idle) in order to improve the normal bottleneck, which is IO."
I don't see what's wrong with that at all. Of course, it's no good if you've got a machine which doesn't represent the "normal" current situation, any more than using a graphics card for "acceleration" makes sense if the graphics card in question is 10 years old but you're using a fast new CPU.
Jon
JFS ... (Score:3, Interesting)
IDE Drives Cause other Overheads (Score:4, Insightful)
There are other considerations here as well. What about the I/O elevator's tuning options.
Yes, I'd much rather see this test occur against a SCSI drive or better yet against a RAM drive for pure software performance.
Cheers fellow slashdoters!
-Joe Baker
Re:IDE Drives Cause other Overheads (Score:2)
Re:IDE Drives Cause other Overheads (Score:3, Informative)
No. A single transaction comes from a single thread. So the IO scheduler has no freedom here. It consists of these operations:
1. write redo log
2. write
3. clear redo log
They must occur in exactly this order. There are flush operations involved as well but I am not an expert here.
Outdated hardware... (Score:3, Informative)
In my daily work I manage hundreds of GB's of data and have hardly seen a significative difference between XFS, JFS and ReiserFS v.3 on relatively modern hardware (Tyan S2882 Pro motherboard, two Opteron 244 processors, 4 GB RAM and two 250-GB SATA HD's) running OpenSuSE 10. I put the most important data on a XFS partition but also have a small ReiserFS partition which can be read from Windows.
-- Help us to save our cousins the great apes, do not use cell phones.
Bad graphs to prove a point (Score:2, Informative)
It starts at 345GB and goes to 375GB on the y scale. This makes the difference between 355 and 370 look like a 50% difference rather than that 5.7% increase.
He does it again in make 10,000 directories 99.5% is not double the cpu use of 97%
Nice stats... but wrong... (Score:4, Interesting)
What am I saying? I want to know how efficent these filesystems are in packing the data on the HD.
I'm glad that you get more data out of Reiser v4, JFS, and XFS at formatting time, but my feeling is that Reiser v4 (once profiled, tweaked and refined for speed and space) will pack data tighter than anyone else. Meanwhile, I'm looking for something like ext3 that packs better.
Poor benchmark writeup. MS Excel graphs? (Score:2, Informative)
You would have thought the author would use something better like gnuplot?
The author's opinion "Personally, I still choose XFS for filesystem performance and scalability."
is largely irrelevant here and sounds like bias, although the author acknowledges this.
There is no discussion of the results. The text between the graphs only mentions superficially
what is obvious to anyone looking at the graphs.
Seems a far cry f
benchmarks that take less than 1/10 of a second (Score:5, Insightful)
Re:benchmarks that take less than 1/10 of a second (Score:2)
XFS - UPS = Disaster (Score:3, Interesting)
I have a strong warning if you are considering XFS. If you don't have a GOOD power backup (UPS), then don't use it. XFS caches very agressively for writes in RAM. You lose power, you lose that data.
XFS was designed with datacenters with good power backups in place, not home users. So chose carefully.
Re:XFS - UPS = Disaster (Score:3, Interesting)
Anyway, for anybody interested, the results are at: http://staff.vbi.vt.edu/dom/iscsi/testing [vt.edu]
Old Shitty Machine, Shitty Results (Score:3, Insightful)
Checkout the CPU utilizations; reiserfs is pegged at 100% cpu utilization for ~8 tests. For a FS which describes itself as willing to use more CPU in order to achieve better I/O than the competition, running the benches on an antiquated 700 mhz machine is simply not fair.
OTOH, Untarring and tarring are notably NOT cpu limited, and still pretty lackluster for Reisers case. Disappointing, very disappointing. I was extremely impressed in the ext's; I simply had no idea how consistently well performing they were.
I'd also like to see FreeBSD's UFS
Myren
Slow filesystem? (Score:2, Funny)
Re:First Prime Factorization Post (Score:2)
Re:Uhm, whats with the chart? (Score:2)
Re:I use the same machine! (Score:2)
Heck, my main dev box is a dual 1 Ghz PIII coppermine with 1 Gig of ram, and the only issue I have with it is when it chokes on extremely large eclipse projects. I'm sure it can't play games worth a damn, but I don't need it to. I think I sunk a total of about $30 for this monstrosity.
Thinking about it, my entire business' network of
Re:Something's up (Score:2)
At fir