Slashdot Mirror
Benchmarking Linux Filesystems Part II
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.
An interesting analysis in every aspect, and it's fine and dandy for the person who uses 400 GB drives and a ATA controller on a 500MHz computer but I'd like to see how the filesystems compare on a bigass RAID system run by a Power5 server, or a few Itaniums that usually have with a few hundred connected users. Something a bit more "entreprise" - where the choice of a filesystem is a bit more critical than a small server or a home PC.
wow, what a dry article.
However, scroll to the bottom. More latin translations than you can shake a stick at, including my personal favorite:
I have a terrible hangover.
Crapulam terriblem habeo.
-S
One thing this does show is that you need to be very careful to match the filesystem type to the main tasks the PC is going to be used for. Personally, there's no real clear winner as all have major gains or deficiencies in some areas. One very interesting point was the vast difference in the amount of available space after a partition and format between the different filesystems.
Conor "You're not married,you haven't got a girlfriend and you've never seen Star Trek? Good Lord!" - Patrick Stewart
Is "First Prime Factorization" is what you do when you have too much time on your hands? Persoanlly, I would put my time to better use by playing Quake 4 and blowing zombies to kibbles 'n' bits on a fast hard drive subsystem. :P
It is widely known that Reiser filesystems are heavy on CPU usage 4 more than 3. These benchmarks seem to show a CPU bound IO situation as opposed to an IO bound IO situation. As an earlier comment pointed out, the hardware used in this test was a 500mhz CPU. My slowest computer is a 1000mhz system, which is usually IO limited, not CPU limited. I'd be interested to see these same benchmarks run on real hardware, or some more complex benchmarks (random RW, DB load, etc.). The hardware used for this test would be suitable for a fileserver, but not much else. In that situation, E2, E3 or XFS are probably the right choices as it points out. What about desktop loads, enterprise loads, or something more interesting?
--Brandon
Here's what's missing. They forgot to tell you how well the drive performed after being used for 1 year, and having constantly moved data from one place to another, and constantly deleting and creating new data. It would have been a better test if the drive was about 75% full, with data from 2 years of use, and then the same tests were performed.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
How about some SATA benchmarks? PATA is good, but I suspect things will be much improved with SATA and NCQ. Does anyone have any links?
today is spelling optional day.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
So he's benchmarked two different file systems on two almost completely different hardware setups (different drives, different raid controllers, different ammounts of RAM) and produced completely meaningless results? This is news how?
Remember, fastest!=best. Some filesystems cannot shrink. Some cannot change size at all. If you're doing anything with LVM or RAID, generally ext3 is the way to go. If you're just formatting a disk and using it without anything on top of it, these FS's may be for you. Then again, ext3 looks damn good in the tests as stands. XFS looks like the clear loser.
Since when has this country used intellectual elite as a pejorative term?
I'll leave aside the fact that all the other benchmarks I've seen are very favourable to Reiser4 and this is very unfavourable, and concentrate on the discrepancies.
Reiser4 is the slowest in searching, creating and removing. It performs a lot better when tarring and untarring, which indicates that reading and writing is much better than other filesystems. However, when you get to copying and creating large files, it loses again.
Why the discrepancy? These benchmarks contradict others, but don't make sense when taken alone. I'm inclined to believe the other benchmarks.
I love the CPU utilization graph for "touch 10,000 files".
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.
Actually, what I take from this is there's no need to switch from a safe, standard EXT3 FS which is the default of many distros.
[quote]
COMPUTER: Dell Optiplex GX1
CPU: Pentium III 500MHZ
RAM: 768MB
SWAP: 2200MB
CONTROLLER: Maxtor Promise ATA/133 TX2 - IN PCI SLOT #1
DRIVES USED: 1] Seagate 400GB ATA/100 8MB CACHE 7200RPM
2] Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM
DRIVE TESTED: The Seagate 400GB.
[/quote]
It's comforting to know I'm not the only one still using one of these! Those are almost the exact same specs as my linux server!
His benchmark data is ruined by using a gross unrealtistic piece of hardware - modern fast hard disks coupled with a cpu which is absurdly slower than anything you can buy.
I have to agree with you, I got fooled looking at these charts.
It would be a lot more helpful to me from a practical standpoint
(i.e. which filesystem to choose) if all CPU graphs were scaled
from 0 to 100. That would help me understand which differences
were important, and which were irrelevent.
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 "I can achieve this result +-10%".
Of course, if a particular benchmark can't even hit a cpK of 1, then maybe there is room for improvement in the coding of the driver.
For those of you who haven't done much with statistics, cpK is a measure of "capability" in a machine or process. It shows how repeatable the measured process is. A higher number indicates that you have a highly targeted, low deviation process whereas a low number (1 or less) indicates that your process is incapable of repeatability and/or accuracy.
Ron Gage - Westland, MI
There were some current (recent 2.6 kernel with XFS, JFS, possibly Reiser4, etc) benchmarks done on highend servers (or at least something with drives a few steps up from the CompUSA weekly special), especially if anyone wants to see Linux succeed in the enterprise.
Based on the geometric mean of all the benchmark times for each filesystem, which effectively weights all benchmarks equally:
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.
Everyone knows Reiser4 uses a lot of CPU, and these guys run the test on a 500MHz machine!!
Reiser is not designed for slow CPUs. AFAIK, a key part of the design was the Hans Reiser realised that CPUs were vastly underused. IO resources were maxed out and CPUs were sitting idle. So he found ways to use the CPU to make more efficient use of the IO resources. So this benchmark on a 500Mhz machine will of course show Reiser in a bad light, and moving lower down to a 266Mhz will make it even worse.
For a decent benchmark of how filesystems work on modern hardware: use modern hardware.
Please help publicise swpat.org - the software patents wiki
I'm looking at the all test times chart and it seems to mis-represent the time taken to cat a 1Gb file to /dev/null
http://linuxgazette.net/122/misc/piszcz/group002/i mage018.png
In the last set of data points shows REISERv3 as the 4th best but...
http://linuxgazette.net/122/misc/piszcz/group002/i mage017.png
is showing it as the clear loser.
Also, the data at the bottom of the article confirms it.
WTF??
I call shenanagins (sp?)
~ELF
It would be interesting to see the results of the same tests running against a SCSI drive system where there is less IO overhead to see if the results differ.
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
It seemed to be either first or second at most of the benchmarks. I really don't consider that mediocre.
I was pretty surprised by ext3's performance. I also read the article.
Part III of the test should feature the filesystem behaviour during a Slashdot Effect.
I must say the filesystem they're trying in the current effect is really failing. No pages served booh!
What I take away from these benchmarks is that Ext3 is still the most reasonable choice: mature, well supported, and good overall performance.
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.
I want to know the SANTA benchmark. How did he travel all over the world and when will he not be able to handle anymore?
I prefer the "u" in honour as it seems to be missing these days.
Aside from specific needs like constant-speed streaming (XFS), it's a processor thing:
Do you have lots of CPU time available?
Yes: ReiserFS will extract the most of your computer.
No: Don't use ReiserFS; maybe JFS or something...
Just my personal opinion, not endorsed by anyone here.
Anyway, how is the average user supposed to be concerned by these results?
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.
1) the physcal machine is the same? but you've just said you've replaced the HD and the HD controller!
2) I notice in small print at the bottom what I believe to be the case too, after looking at the overall figures. XFS seems to be the best performer overall in terms of CPU load and speed of file system for day to day tasks. okay, it loses big time ona few items. I'd never realised how painfully crap reiserFS is for many many files....and yet its constantly been 'bigged up' as the choice to make for MAILDIR systems. why?? who would do somthing like use reiserfs for a mail server?
ext3 without -j (journal mounting option) is no more than a ext2 partition and -j with defaults of 2 to 4 seconds of commit is just pushing luck for AC blackouts as for xfs, it repairs itself without external tools :)
p.s. and just for the record:
I have used so far ext3, ext2 and xfs partition types for / and data partitions and to tell the truth
I dont like ext2 at all because I get errors too often. Unlike it, xfs has never failed me except once, when I had to mount a partition readonly to repair it (still debugging this case)
ext3 without -j is just the same although my brain didnt realize it until repair to the partition (brain still intact) was fruitless.
ext3 with -j was slower than my granma.
sex is better than war!
NOTE5: All tests were run 3 times and the average was taken,
if any tests were questionable, they were re-run and
checked with the previous average for consistency.
The total free space graph is poor statistical representation
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%
Are those graphs really created in MS Excel?
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.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
I'm *sick* of reading filesystem benchmarks of people who doesn't even care about even reading the documentation of the filesystems they compare
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.
It's missing the most critical stuff from the tests, but I guess those things are hard to measure without manually creating a hardware failure.
I'm glad for this information, though. It affirms my choice of Ext-3 as the best all-around filesystem for my Linux servers and workstations. It's not the fastest, certainly not the slowest, but it's well-supported with utilities, and standard in every bootdisk kernel.
What's with the Microsoft Excel style graphs? They're not very precise or professional-looking.
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 from the very nicely done BSD and Linux benchmark at http://bulk.fefe.de/scalability/
> 500mhz is at least 8 year old technology if I remember correctly.
Close. When I bought a computer in Jan 1998 (8 years ago this month), the fastest processor available from Dell/Gateway was a PII-300. I'd say it's more 6-7 year-old tech.
Of course JFS won, since it was designed to be as simple as possible ... it's originating from OS/2, afterall. On such a machine as used in this test, this is a huge advantage.
EXT3 has a lot going for it, but the default compile options (at least the ones used by several of the popular packagers) make it incompatible with large files. "Large files" is, of course, a relative term, but more than a few people deal with 4+GB files nowadays, like DVD ISOs, so it's not just billion-record databases that blow up EXT2/3.
If I wanted small files, I'd have used FAT32! :)
ext2/3 are actually the clear speed winners.
Almost the only useful part of the article is the table "File Benchmark II Data". Scrolling through all the bar graphs is a waste of time. (Unfortunately, the first few pieces of data appear only in bar graphs, and not in the table.) The "All Test Times" plot would be very useful, except half the points don't have a corresponding label on the x-axis!
And what's important for the kind of evaluation you're doing are only the real world benchmarks like "UnTAR Kernel 2.6.14.4 Tarball", "Copy 2.6.14.4 Kernel Source Tree", "Mount Filesystem", and so on. ext2/3 are the fastest in almost all of these benchmarks. Then comes XFS and JFS, then ReiserFS, and finally Reiser4, which appears to be something of a dog so far as these benchmarks are concerned.
Obviously benchmarks don't tell the whole story. There are advanced features for Reiser4, ReiserFS, XFS, and JFS which could easily be more important for a user than these small differences in speed. And although ext2 is apparently fast for real world use, it is not journalled, which should disqualify it for most users.
The more fundamental benchmarks like "Make 10,000 Directories" are not useful for choosing which filesystem to use. ext2/3 stink on ice when making large numbers of directories, but it's not obvious what fraction of time users spend making directories. Plus, most directories that are created will eventually be removed, at which point ext2/3 win back most of the speed that they lost. What the fundamental benchmarks are good for is figuring out why a particular filesystem is unusually fast or slow at some benchmark, and so how that filesystem could be tuned or otherwise improved.
Anyway, it really looks like ext3 is a decent choice for the general user. I think it's bad to mandate the use of ext2/ext3 at install time, but that's a separate issue.
If you are thinking about a file server, it's very important to match the file system to the type of network protocol (NFS, SMB, whatever).
Ext3 and NFS work ok, except that writing a bunch of small files (as in untarring to an NFS mounted dir) is as slow as, well, swimming in cold tar (:P. An untar that takes less than a second to a local ext3 filesystem can take over a minute to the same file system mounted via NFS. Yes, that's run from the same fast server. It's a bad interaction, having to do with how NFS and ext3 deal with write commits. Even with all the NFS tweaks in place, it's still a couple of orders of magnitude slower.
Similarly, if your Samba server uses a non-Windows authorization backend, such as NIS or MIT Kerberos/LDAP, your filesystem really doesn't matter -- it's going to be slower than needed due to the overhead of translating the protocols.
A web or other server that does primarily read, read, read all day, should avoid ReiserFS, because if you get slashdotted you want your CPU as free as possible. That's not the only factor, but the point is that a lightweight, non-journalled FS can be your friend if you aren't writing to disk much.
Well. Wow. A benchmark that runs for between 0.03 and 0.07 seconds sure is quite precise, free from random variations and stuff. I bet most of the time was taken by spawning the "touch" process 10k times anyway.
About the "free space" issue, some filesystems count the space used by their internal data structures, some don't ; so for instance reiser has less free space after formatting but that doesn't mean you can put less data on it...
Also the results are pretty useless. I'm not really interested by knowing how long it will take to sequentially access a small (10K) number of files which are cached in RAM anyway, so it's CPU-limited and not disk-limited. I'm more interested in what happens when the dataset is larger than RAM, how intelligently stuff is cached, etc. These make a lot of difference in the way the computer feels, between sluggish and responsive, but there is really no benchmark for that...
All I know is that reiser4 is the only filesystem that made my crap slow laptop harddrive at least usable. That's a good enough benchmark for me...
As you and other have pointed out running the benchmarks with a slower CPU is useful.
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. Because you can't be too sure if flash drives might overtake harddrives for price AND speed. Some people use flash drives regardless of the cost.
These tests are also application independant which limits their usefulness a little. When somebody benchmarks a new 3d video card they'll start with 3dMark. But then they'll continue on and test with actual games.
So I'd like to see some practical benchmarks. Compiling something large is a great start. Then try various database loads. Some workstation or home pc desktop apps. Games. Some of the tests done by the folks at StorageReview.com might be relevant too.
Editors: Please don't post links to such garbage ridden pages like this. I got at least three or four prompts in konqueror 3.5 to save a .swf file or cancel.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
no NTFS, no fucking care.
Reasonable test plan (clear and reproducable,) but not much theory. (Why was he running the untar? Is there a special feature of a file system optimized for tar? Would have been nice to see what he was trying to measure.)
Also, it would have been nice to see a run of iozone against the competing filesystems. Iozone (or bonnie, for that matter) is a pretty standard benchmark, and should have been included.
Finally, these are basically synthetic tests - it would have been a little more useful to see something like database access tests. One thing that quite a few benchmarkers ignore is the impact of the unit under test on the overall system: that sort of thing is more readily discernable with a application test.
I use EXT3 because it is supported by Norton Ghost 2003.
Does anyone know if newer Ghost software supports one of the newer filesystems?
Dan
I believe that the current maximum filesize limit for ext3 is 2 terabytes (possibly more by now).
Is anyone working on porting Sun's ZFS to Linux? Now that's a really cool filesystem.
I can't think of ANY time where a sample size of 1 was meaningful for anything.
I bumped into my neighbor yesterday and she complained about the size of your sample not being meaningful, too.
I not sure what distributions your are using, but the biggest users of ext3 are RHEL and Fedora, and they have had large file support for years.
Havoc Penington, the bane of my Linux desktop.
If someone does not know that filesystem benchmarks that take less than a tenth of a second are meaningless, it makes you wonder if they made errors in other aspects as well. These results are not consistent with the results that we have had. I bet he did not make an effort to ensure that you had to read the disk for these benchmarks, that he did not copy his file set from the same fs as he was measuring (makes a HUGE difference to performance and it is the mistake every beginner makes), etc. You'll note that the way he makes his graphs makes 1% differences look huge, etc.
XFS is a nice filesystem, I like it. Not enough to use in production, but I like it. Personally I use reiserfs3.6 on many production servers, and have never seen a problem. I am experimenting with 4 at home.
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.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
the first impression is JFS is the winner, but i have find some errors at the comments about graphs, CPU is slow (im not asking for a benchmark using an opteron or something like that neither) so it may have influenced directly over the benchmarks results. Another problem is the benchmark as commented before is based in a result of one only test (apparently) so the results may be completly different if a file system benchmark part III is done. it would be a great idea to make public the scripts which where used to realize this benchmark so this might be used to do some more benchmarks in different hardware and lot of times.
I would rather see these benchmarks on a computer less than 5 years old. I would also appreciate an open source version of the tests so they could be reproduced. For ease of reading, I think the article should be on a separate page on the site as well.
/usr/bin/touch
/dev/zero stuff is completely bogus. No indication of the blocksize that was used.
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.
<blink> Test is flawed! </blink>
/w and w/o softupdate benched.
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
What are you grievances with Mr. Pennington. Just curious, thanks.
Myren
I have a few systems here at work that have many Tb of storage and bandwith requirements >1G/sec. It would be nice to see someone accually test this kind of setup with the linux file systems. From what I've personally seen XFS is just about the only legitimate solution for our application (its not exactly optimium either, its getting its butt kicked by NTFS). This is because linux simply uses to much CPU to maintain any reasonable throughput (aka >500Mb/sec) and the larger file systems tend to either get so slow as to be unusable, or they simply don't work.
Yes, the theoretical maximum is comfortably large... But, that limit is not what is compiled in by RH, Mandrake, and a few others I've tried. I haven't tried RedHat's "Enterprise" kernel, but most are compiled with a 4GB limit on file size.
> How much better are we talking here?
See my second post in this thread, I give a link to a benchmark where Reiser is twice as fast as its nearest competitor.
Please help publicise swpat.org - the software patents wiki
All the tests where done on a 500 mhz PIII machine.
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?
Mail server?
What about data integrity?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Wow. They must have a super slow file system if they are just now getting the results of the tests and the first half of the article ran in the first half of last year! :) This is supposed to be funny by the way.
Charles Wyble System Engineer
Debian Woody has LFS for ext3 (although I belive it was a backport and 2.4 only) and that was released on 19th of July 2002; what distro are you refering to?
I ran a few standard deviation checks on the statistics, and the winner of the benchmark would be... JFS, believe it or not. ReiserFS is the clear loser here. Then again, Reiser would benefit from having more up-to-date hardware. Not totally unexpectedly, Ext2/3 is average. So is XFS.
Huh? Sorry, did you read the same graphs or are you just trolling?
Yep. It almost seems as if he thought the longer bars meant it was better. *Sigh*
From what I can see, the one outstanding statistic is that ReiserFSv4 still needs allot of work if it's going to catch up with v3 (if you're into that kind of file system..)
It really looks to me that EXT3 is THE standard if performance in the areas that really matter are what you're looking for. It is way ahead of the pack at finding files and making directories. And, it keeps up with EXT2 in almost every other area which is impressive considering the added complexity.
I really don't think you should touch something like ReiserFS with a barge pole unless you're paranoid about losing data.
Put it this way, if you want to run a super computer and still keep integrity, you can do that with EXT3. All you have to do is copy dat every now and then and you will do this MUCH faster than with ReiserFS's integrity measures. In reality, you will have failsafes, you will be able to resolve a power failure downtime easily. You'll do it better with ResierFS but the cost in performance is just too high.
Better to do it manually with EXT3 and have a Ferrari in terms of performance. Actually, JFS and XFS look excellent too.
I can't see any reason to not use EXT2/3. For me, my main use for a good file system is all round performance. You can ALWAYS build in your own integrity measures easily. The dilemma with ReiserFS is that you you use it's integrity measure but that makes IT slow.
I think a Windows server would beat the heck out of a ReiserFS based Linux server in terms of performance. Why bother?
You can bet google are not using ReiserFS on their servers!!
http://users.adelphia.net/~apiszcz/piszcz.html
You can view them here for now until Linux Gazette gets a chance to fix them!
Thanks,
Justin.
Question for Linus: Why are you not letting the Reiser4 drivers into the mainline kernel? Imnsho you are doing the Linux user community something more than a mere disservice by not allowing everyone simple access to these excellent file system drivers.
I've seen those benchmarks before, and last time I saw them, I decided Reiser was for me. I've been using it ever since.
Based on the new benchmarks, I'm serious considering moving to JFS. It seems to be much faster for my typical desktop usage.
I'm curious what hash function he was using with ReiserV4, though. TEA produces a more responsive filesystem, for me, than R5. Reiser defaults to R5, so I'm guessing he was using that, but I'd like to see the difference that TEA produces.
Secondly, you don't need to give every option to everyone. Red Hat's installer already lets you pick whether you're installing on a desktop, a server, or a custom system - so that automatically tells you which filing systems are likely to be wanted.
(eg: If you are installing for a desktop, you don't - probably - want a filing system geared for high-end servers. Likewise, a server box won't want a desktop-optimized filesystem. Custom installs should be exactly that, allowing you to custom-pick whatever you damn well like for the filesystem.)
So, uh, fedora developers are stupid and you're smarter than them?
That's easy. Yes.
The entire release cycle methodology is flawed (development needs to be split into alpha and beta, where alpha is the latest release and beta is the set of RPMs that will co-habit the hard drive. When RPMs are built, a complete dependency map should be constructed and compiled.
Since "development" basically means "it'll compile, but it's not tested", you could cross-compile development trees for EVERY architecture Linux supports, on the grounds that you don't give a damn if unsupported binaries will actually run, but if they do, you've increased interest in that distribution and are in a position to expand and support other architectures if the interest turns out to be there. Costs nothing, but potentially earns lots.
It is obnoxiously difficult to get 3rd party RPMs into even the extras branch. Many programs have multiple configurations possible, but are often compiled with random, unexplained ones that make no obvious sense. RPMs that are present are sometimes ancient (HDF5 is at 1.6.5 with no szip support, in the extras, but the current version is 1.7.52 and szip is at 2.0. ATLAS - a very important maths library - is at 3.6.0, but the current "recommended" release is 3.7.11! The version of LAM is ancient and should be replaced with OpenMPI anyway.)
Yes, I would regard the Fedora developers as too slow, too entrenched and not interested in producing the optimal distribution, only the best one they can produce at minimal effort. To me, that is wholly unacceptable. Towards the end of the last ice age, you could understand people conserving effort. That is no longer the most efficient way to get things done.
(If anyone out there cares to provide some disk space, I'd be more than happy to show how Red Hat could be done better, with greater versatility, yet with fewer headaches for the novices.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
PERL CPAN users will likely also be familiar with the notion of massive numbers of directories being created. Programs that create workspaces in the
So if you are in any of these categories, ext2/ext3 should NOT be used for your workspace partition or the partition on which the
There will be other cases, but those are the clearest to me.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
That if you like to delete files, EXT2 or 3 is the way to go!
Also, studies show that Reiser v4 and v3 were obviously swapped, because normally subsequent versions are supposed to IMPROVE performance.
Speed is the most unimportant aspect you can think of...
First off:
People pissing and moaning that it's a old 500mhz machine should realise that very rarely in real world your cpu is completely dedicated to managing files.
That is when your running other proccesses it's likely that you'd only have '500mhz' worth of performance for a single proccess's file system accees left after the kernel is finished scedualing all the other proccesses and thread.
So stop bitching. It's a good as any benchmark.
Secondly if you value your data at all you should be running Ext3.
It's not so much that XFS sucks or JFS sucks.. it's that YOUR HARDWARE SUCKS.
Yes. That PC sitting in front of you with the nice big SATA drive and nforce chipsets is a hunk of shit. All PCs are like that and it's a reality you have to live with with PC-class hardware. Even on the server.
It maybe fast. But fast ain't everything.
With XFS and JFS they are designed for a different class of hardware.
These are machines that are built specificly for a task and the operating system modified/designed to suite that specific hardware and that specific task. These have nice big harddrive caches with battery backups (just for the harddrive's cache), they have big capaciters in the power supplies with all sorts of redundant ways to monitor different aspects of hardware. They are designed to be used with nice UPS and redundant power supplies.
If the power goes out to the machine and the UPS fails there is enough time on the machine to abort proccesses and make sure that the file system and data on the system is in a consistant state in the second it takes for the hardware to finally fail. And the hardware fails in specific orders to avoid data corruption.
This shit is expensive. This is the 'high end unix iron' stuff that people talk about. This isn't your Dell dual cpu crapbox with Windows 2003 thrown on it. The only way to get close to this level of reliability with PC hardware is to use Linux clustering with multiple multiple redudant redundancies and failover network file system support and such... and even then there is limitations.
This is what XFS and JFS is designed to do. Even low end versions of AIX and IRIX-using hardware had special features to assist the file system in protecting itself.
Ext3 on the other hand is designed specificly to work with your crappy PC hardware. That's it's purpose. That's what it is designed for and that is why 'enterprise' style Linux distros like Redhat use it almost exclusively, that's why they helped create it.
When your PC hardware looses power it craps out randomly. Your cpu could still send data to your harddrive while the delicate memory is busy flipping out and sending random garbage down all the channels on it's bus. There is no intellegent way for the OS to handle power failures and hardware failures because the hardware has no intellegent way to handle this stuff.
That's why Ext3 still has fsck. XFS, for instance, has the ability to journal your directory system.. but not data. Ever noticed that? Ext3 supports multiple journalling features including full data journalling.
That's also why ext3 is tied into linux clustering with things like Lustre and GFS.
That's why you, in my opinion, should use Ext3.
It may not be as cool as ReiserFS, but if your data matters then use Ext3 AND backups.
It would be a shame if 2.6 came with that kind of a performance penalty.
Also, I don't think I can consider a benchmark on such an old system to be representative. The relationship in timing between the filesystem and the spinning platters themselves is bound to yield quite different results under a 2x or 3x faster CPU.
If you are ready to throw your computer out the window, I recommend trying the slightly less destructive # rm -rf / which can be just as satisfying. Sometimes you just need to start fresh, and ext3 can get you there in seconds.
We store images. Lots of images. Customer images. We recently bumped into the EXT3 4TB files system limit.
Redhat will only support GFS in addition to EXT3 and EXT2. I know we can carve up a >4tb volume into several smaller filesystems, but the nature of our storage architecture is that larger volumes are more efficient. I have seen very little mention of GFS and we strongly desire to maintain vendor (RH) support on these production systems.
Comments?
I think your post would have been more "insightful" in the context of the discussion if you had actually posted some scores from different file systems. Basically all I gathered was that you ran some benchmarks and they were different from the articles on your machine.
I want this account deleted.
> Question for Linus: Why are you not letting the Reiser4 drivers into the mainline kernel?
This has been flamed to a crisp several times over on LKML. My guess is that it's because they let Hans and his ego do the negotiation. Flame ensues, technical issues don't get solved, no merge.
O I C. Pity. Shame when personalities get in the way.
Not that I need to care 'cos I run the -mm kernel tree, which seems to go pretty well for me.
hmm, don't know. it always sounds bad to me to have such large filesystems. are all files in there without subdirectories? perhaps you can move the subdirs of to other volumes. if you care to shell out large amounts of cash for support etc. you could go with veritas fs/vm.
in that case the OS will be supported by RH and your fs by veritas.
On a long enough timeline, the survival rate for everyone drops to zero.
Note that real file systems life-cycle is not :
format, create some files, delete some files, create some directories, delete some directories, format.
in real world, a file system can last for years, and file fragmentation can have very a serious effect on performance.
I think a real rest would be to create a random sequence of file related actions (create dirs/files, delete dirs/files, move, rename), mix it very well, and run it on several file systems.
this will create fragmentation, and will show how well each fs handles it.
Omry.
Han Reiser will giving a presentation on the Reiser4 File System at SCALE 4x.
The so-called review was intersting in that it is good from time to time to raise one's head and make sure your not living in a dream world or on outdated info or presumptions.
;)
This article made me re-evaluate my use of R4.
Beyond that is was a serious waste of time. So-called reviews that take on the air of scientic evaluation but dont stand up to five minutes critical analysis abound on the internet.
what is surprising is that this even got linked by slashdot.
dec(slashdot.cred,5)
Think before you link.