“There are a lot of Linux filesystems comparisons available but most of them are anecdotal, based on artificial tasks or completed under older kernels. This benchmark essay is based on 11 real-world tasks appropriate for a file server with older generation hardware (Pentium II/III, EIDE hard-drive).”
Filesystems (ext3, reiser, xfs, jfs) Comparison on Debian Etch
About The Author
Follow me on Twitter @thomholwerda
2006-04-23 4:39 amcorndog
What would have been a nice addition to this article: To have the author pull the power plug from his machine in the middle of the large directory copy (maybe do it 10 times on each FS) and report on how recoverable they are.
That’s the single reason I use reiserfs – I’ve never lost data with it – even with ugly hardware failures. To me that’s worth the small deviations in CPU usage and top performance. ext3 has left me without data many times.
2006-04-23 7:55 pmrenox
The problem is that exactly the opposite occured to me, I lost data due to reiserfs (didn’t have a proper fsck at the time, not sure if it’s still true), while I found ext3fs more stable..
Your and my experience are just single data points, stats are needed to give interesting information..
Very good article! After reading it, and the (very informative) readers’ comments, it looks like the two best choices would be either ext3 (for reliability and recovery) or XFS (also very reliable, and fast). A lot of readers seem to think that reiserfs may not be reliable after a power failure. Hard to decide, but the author clearly believes that XFS is best overall. I’ve never used it, but I will have to give it a try.
2006-04-24 1:56 amaliquis
Considering everything I’ve heard about ReiserFS track performance when it comes to corrupting data I would never use it. XFS is faster than Ext3, and I would choose it over Ext3 any day.
Intresting that he points out that JFS uses less CPU, might matter for some environments I suppose but not to me.
I would definitly go with XFS.
Interesting read. Might give it a try next time, I’ll do major rearranging of my system. Until then I’ll just stick to ext3.
A side note: It could’ve been funny to see how these systems perform compared with FATx, NTFS, BFS, SkyFS, SylStor/AFS and several other file systems.
Since when has creating, mounting and unmounting a filesystem been performance critical? These are about the least performance critical operations the filesystem does.
Correct me if I’m wrong, but most servers spend their IO updating existing files (file servers, database servers, mail servers) or reading and serving static files (web, news, mail, ftp servers.)
Non-ext3 based FS are generally good for large numbers of files within a directory, historically the domain of email and news servers. But these earn’t the majority of test cases, but a minority.
I’ve never had good luck with reiser.. seemed to like eating my files and turning them into directories, and I didn’t notice it to be significantly faster than any other filesystems for desktop use.
Everyone was saying that “Reiser kicks ass” when I chose it for my desktop system a few years back :/
I’ve used reiser for years and it’s also used on a large multiuser system I use. I’ve never had any reliability issues despite numerous hardware issues. As to speed; choose what you need… I spend much more time waiting on large grep’s and finds and whatnots than copying large files. Small file performance is also handy because I run a few file-based wikis which consist of a very large number of small files. It’s not that I don’t do things with large files… it’s just those are things that I’ll let complete in the background. I have the feeling that’s actually quite normal and therefore such benchmarks are kind-of misleading. As to small fileservers, of which I’ve also run many, filesystem performance has never seemed to be anywhere near the bottleneck samba or NFS have, so I’ve never really worried (might be more of an issue with many simultaneous users).
In any case, this benchmark is pretty pointless… It just doesn’t test anything very practical. I’m sure it’s hard to test, but I’ld rather know the performance of disk-intensive apps then; application startup speed for one. Finally, XFS and reiser were “fast and CPU-intensive” on the ‘find’ test… of course, the CPU intensive is kind of misleading, because the _percentage_ usage may have been slightly higher, however the _time_ they used the CPU was a lot lower; obviously the amount of CPU time actually spent would be a far more useful measure (and frankly, if every single FS is this fast on pretty much the most CPU intensive test possible for and FS on a celeron 533, then I’m not too worried….)
I don’t know what is the cause of this but Reiser really shines when manipulationg large amounts of small files. When I used Gentoo I always put portage on separate partion – made updates of the tree much faster. For the rest XFS just felt faster and the test seems to confirm this.
…but reliability is what really matters, especially for servers. If you do any serious work on your computer, your data is far more precious than a few milliseconds. It’s something that most reviews/comparisons, including this one, are neglecting.
On that aspect, I had the best success with ext3. I did had some crashes with XFS, but the recovery utilities are quite nice. I had nothing but trouble with reiserfs3… Power failures or kernel crashes usually led my ReiserFS partitions to corruption.
On speed, ext3 might seem slower than the competition, but that is because the journal is written in ordered mode instead of writeback. Writeback mode allows data to be written after the metadata is commited to the journal. It might led to old data appearing in files after a crash. If you don’t mind this, you can change the default behaviour with tune2fs (tune2fs -o journal_data_writeback /dev/your.partition). It might give you a better performance. If you are paranoid, there is the data mode, where everything is commited to the journal before getting written on the filesystem (tune2fs -o journal_data /dev/your.partition).
Another nice tip is using the “dir_index” feature (hashed B-trees for directories). It will give you a small boost without affecting stablity. Again, tune2fs is your friend for changing the behaviour (tune2fs -O dir_index /dev/your.partition).
Unless you have specific needs for performance, I believe ext3 is the safest bet. Reiser4 do look nice and safe, but I guess it will have to adapt to Linux’s VFS before getting serious real-world usage.
this http://en.wikipedia.org/wiki/Comparison_of_file_systems is a much usable resource
capabilities and features are usually more important than 5% difference in speed, cpu or space allocation
and usually for home users doesn’t even really matter, most of them use ext3 anyway and most of them don’t even care about the rest
from my experiences I have come to use xfs on about every desktop and server that I use (reliability, good recovery tools, good handling of terrabyte partitions with both many small and many large files), and reiser3 on laptops (mostly for the speed, and since ext3 is on my blacklist for a while now)
There’s already plenty of benchmarks of those filesystems. They should’ve included reiser4. It would be really interesting to know if it can finaly can beat its predecessor.
2006-04-22 3:04 pmtihirvon
Maybe it wasn’t included because it’s not in vanilla Linux or because it is too unsafe. I have the impression reiser4 is complex CPU-hungry FS. It was advertised as the worlds fastest filesystem but the benchmarks where it sucked were not published.
2006-04-22 3:13 pmSEJeff
They should’ve included reiser4. It would be really interesting to know if it can finaly can beat its predecessor.
Reiser4 is actually slower in most of the tests. Check out this link for proof and try some of the tests out yourself:
2006-04-23 10:50 amNxStY
Yes I know, I didn’t ask for old benchmarks of reiser4. And I don’t have a reiser4 partition to test on myself.
Is the reiser4 design fundamentally bad? Otherwise it would be interesting with some fresh benchmarks to see if it’s improving.
.. all device manufacturers chose FAT?
2006-04-22 9:05 amevert
Are you serious or just trolling?
Just in case #1, which is very unlikely, you might consider the fact that all operating systems recognize the aged FAT, so you can plug and play your USB stick everywhere.
In case #2, you should be modded down, which I nearly did (and should have done anyway in case #1 for asking suggestive and very uninformed questions).
Edited 2006-04-22 09:05
2006-04-22 2:21 pmflobberchops
Well most devices come with CD’s for CONSUMERS to INSTALL which 90% DO! So they can install a LICENSE FREE filesystem that is MORE EFFICIENT no? So there must be antoher reason for them using FAT
There are no details on what settings are used on each filesystem. As an example, there are a few settings for ext3 such as dir_index that help it quite a lot. Were these used?
Without knowing how each partition is setup, it’s difficult to take this article at face value.
Ext3 does not actually lose that much space. It’s reserved for root. The amount that is reserved is configurable, and thus can be set to none.
The presentation of the article was pretty terrible, would it really have been that difficult to put all that data into tables? Would have made it much easier to read.
On my SUSE 10 system, I have it set up like this…
/boot 110Mb ext2
/ 20Gb ext3
/home 130Gb ext3
/dump 80Gb xfs
/store 100GB xfs
now I have /tmp and /var located on the /dump as it is on a second disk, and all my films are on /store.
The films are large files so they benefit from the fastest filesystem, and so does /var and /tmp
But, Suse has added its own patched to ext3 that makes it very fast for having root filesystem on it. Suse 10 boots fastest under ext3, if you have data=ordered option set. it will not allow data=writeback on / without some hacking.
Reiser is unreliable using past experiences with it…
I had also some problems with ReiserFS on my old computer I’ve set up fo my mom (Ubuntu 5.04)
After a crash, I couldn’t recover the superblocks on the ReiserFS partition. I had to reinstall the whole system. Now I gave ext3 a try…
that’s pretty much what keeps me on ext3. reiserfs doesn’t have it, not sure about the others but I don’t think they do… anyone care to correct me?
2006-04-22 1:27 pmvikramsharma
Reiserfs is a pretty fast filesystem but requires cpu, in other words reiserfs is optimzed for pentium 4s and the fast amds. Now it would be nice if they did a test of filesystem performance on recent hardware. People are not buying the latest hardware just for looks, they are buying them for performance. I haven’t tried XFS only have tried UFS (on freebsd), and reiserfs and ext3 on linux. In my opinion resierfs was the fastest, though I could be wrong. I am using a pentium4 3.2 ghz with 512 mb ddr ram.
I use XFS on my Linux desktop (Debian), and I’ve used ext3, FFS (UFS) too, and there is a huge difference when handling large files such as AVI clips. 😉
So for a Linux desktop, I’d recommend using XFS for mass storage which holds alot of multimedia data for example, and something like JFS or ext3 for the main system.
Article was short (good) but badly organized. Using tables for numeric data would have made comparison easier.
My choice is ext3.
mke2fs -j -m 0 -O dir_index -N max-files /dev/hdaN
-m 0 disables space reservation for root, useful for partitions storing music etc. non-system data
-O dir_index makes using big directories faster
-N N sets maximum number of files. Too big number (default) wastes disc space. For example if you are creating 200 GB partition for music files (avg 5 MB) good value for N would be 200*1024/5*2 = 81920 (*2 just to be safe). For system partition it might be wise to use default value.
Now when I’ve actually read the comments it seems like Ext3 can be made faster by sacrifing stability features. So maybe Ext3 is ok aswell.
Best is of course ZFS but it’s not the snappiest, atleast my simple tests doesn’t suggest so for using one disk:
It’s weird that copying of rared files on a filesystem with compression turned on seemed faster than without, it might be an effect of file cache thought (I don’t know how to turn it of for ZFS/Solaris.)
Doesn’t take too long to read and easy to understand.