Slashdot Mirror
Linux Filesystems Benchmarked
smatt-man writes "Over at Linux Gazette they ran some tests on popular Linux filesystems (ext2, ext3, jfs, reiserfs, xfs) and the results may surprise you."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
The original article
I support the Center for Consumer Freedom
Dupe
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
tests on popular Linux filesystes
So did the tests come back positive or negative? Systes are nasty things, and early detection is important to increase chances of survivability.
Remember kids. Test early, and test often. You files will thank you.
Karma: Chameleon (mostly due to the fact that you come and go).
EXT2 has better throughput
EXT3 has better file handling capablities
Reiser has better search ablity
XFS has better delete capablities
JFS may be a better choice in regards to file manipulation Subject to debate of course...
This is good information to know, but for a project I'm working on I need to know which filesystem can take the most abuse. I'm talking about power-outages and hard-resets mostly. I know I should go journalled, but which one? What else should I keep in mind.
Maybe slashdot needs a filesystem update to one with more powerful meta-data support like something that can detect when the same URL has been used in more than one post within a certain time. Sheesh.
That is, before it melted.
"Overall, one should choose the best file system based upon the properties of the files they are dealing with for the best performance possible!"
There you have the results!
Duplicate, spelling errors, and nothing but the short submission. Google is relaunching its blogger service -- tell me again what slashdot provides over it?
I've finally had it: until slashdot gets article moderation, I am not coming back.
will be their bandwith bill after having their site posted on /.
In C++, friends can touch each others private parts.
....Will they be faster than WinFS
You're right, that was a total surprise.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
The original article
Actually it is that much to ask. If you mirror anything without permission, you'll get some serious (deserved) copyright troubles. Let's hope CmdrTaco realy likes lawyers.
Well what ever distrubution they have running right now obviously failed the /. test......
"Over at Linux Gazette they ran some tests on popular Linux filesystes (ext2, ext3, jfs, reiserfs, xfs) and the results may surprise you."
The benchmark on spellcheckers surprises me as well...
--JC
I wish he'd make his mind up on whether to put his bars horizontal or vertical - I'm getting a seriously cricked neck.
And then a couple of 3d ones, just for fun. Sheesh.
He should read some of Edward Tufte's stuff.
And the reason is that you used jpegs. jpegs are for photographs; use gif for images such as this. The text won't end up unreadbly blurry and you'll save tons of disk space/bandwidth.
Do you have ESP?
The only thing that surprised me was that the author used jpeg for graph images. So not only are the colours in the legend not clear, and the text bearly readable, the images are actually much bigger than they would be with PNG or gif.
I mean, really. "Mad about You" was a fine TV show... but this good?
How long until we see McKellenFS?
http://209.81.41.149/~jpiszcz/index.html
:)
it's not slashdotted yet
i meant to say, but never could, that you are free to "borrow" back the XHTML-1.1 compatible stylesheets i made from yours, and you are also welcome to my image page's PHP and my blog setup (which will encoroprate your style nicely!). i noticed you needed those things from the entries on your webpage.
here is the winner. FAT 16
Site already /.'ed (when will slashdot ever learn to use a cache - either freecahce or make their own?)
Anyway, all rants aside, here's the conclusion from the tests (there were some graphs as well but I couldn't make sense of them anyway):
CONCLUSION
For those of you still reading, congrats! The conclusion is obvious by the "Total Time For All Benchmarks Test." The best journaling file system to choose based upon these results would be: JFS, ReiserFS or XFS depending on your needs and what types of files you are dealing with. I was quite surprised how slow ext3 was overall, as many distributions use this file system as their default file system. Overall, one should choose the best file system based upon the properties of the files they are dealing with for the best performance possible
See the whole article and a full range of hideously colored full sized graphs here before it gets slashdotted too. Speaking of which, there has got to be better graph making software out there in Linuxland......
I Am My Own Worst Enemy
Right now I'm running reiserfs under gentoo and I recently lost some rather important data, which has made me a little skeptical in using it in a production system. Therefore I'm asking you guys which filesystem do you think is good for a webserver that will be handling a medium sized database and a significant number of transacations each day.
Man, that site must have been running on the tester's machine (a P3-500). Slashdotted at 6 comments.
I managed to get the article, but by the time I had read through it all the site was completely gone.
Either that or the webserver was running ext3... slow as molasses by the test results.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
... Slashdotted!!!
;)
And that didn't surprise me at all
Privacy is terrorism.
I'm actually not surprised at the results, because the results, as usual, come down to: "the best filesystem is the one that is best for your needs". *sigh* I know that benchmarks can't determine things like that, but still a part of me just wants there to be a winner! I mean what good is a race where everyone wins?
Chaos is Divine *
Article with larger images (the site had the larger images separately in a tarball)...
http://theory.cs.iitm.ernet.in/~arvindn/mirror/lin uxfs/piszcz_large.html
Not a clickable link to avoid hammering my poor server.
While they do measure stuff like access times in ms, they don't mention recovery times (chkfs) that are mentioned in ms for reiserfs and mins for ext2. And they don't mention reinstallation times (measured in hours) which occurs for ext2 a lot more than the journalling filesystems :-)
Cyde Weys Musings - Scrutinizing the inscrutable
Personally I could care less which file system is fastest. The most important aspect to a file system is how stable it is with my important data. All the speed in the world means absolutely nothing if the file system is not stable. EXT 3 has never ever let me down so I intend to stick with it, at least until RedHat releases their version of GFS.
Got Code?
It would be nice to see an unbiased comparison with NTFS (though it would be difficult seeing as how you can't get it to run natively on *nix afaik)
I've been using ReiserFS _EXCLUSIVELY_ since about 2.4.11 and I've never had a single problem. It's important to format with the defaults and not specify 'special' arguments to mkreiserfs or you can run into trouble.
I've got three systems currently running reiser on Gentoo, from my PowerPC/SCSI/NFS/Samba file/print server to the ancient Compaq laptop with a 4GB drive. I've never had as much as a hiccup from ReiserFS.
Under what circumstances did you lose data?
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I've never understood why they don't move to ReiserFS, at least for new installations. With Fedora you have to use a kernel option to enable ReiserFS installation and with RHEL you can't install to a ReiserFS root, even the reiserfs kernel module is in their kernel-unsupported RPM which means don't call for help. I love RH but they need to get the ball rolling on this one!
What I'd like is a file system for which there is actually a defrag-tool. Sure, ext2/3 may try to reduce fragmentation as much as possible, but when it happens (as is likely when you have a near-full disk) you've got little or no way of fixing it. Or actually there is a defrag tool for ext2 (not ext3) but my experiences with it are not the best -- it took forever and I don't know that it actually did anything to the disk (fdisk didn't report a 0% fragmentation level afterwards anyway).
on a global scale FAT is becoming the top health problem.
Here's a mirror of the article:l
http://www.gutenpress.org/links/LG/102/piszcz.htm
RFC2119
I'd be curious to see how ext3 would fare in these tests (especially the "lotsa files"-tests) if you use mke2fs with the "-O dir_index" option.
There just might be a reason you can't find many unix filesystem defragmenters. Like they don't need it.
I'm guessing you started out on computers using DOS or pre-NT Windows.
... no pie charts?!? Line... Bar... 3D even... but no pie charts?!?
I've never understood why they don't move to ReiserFS, at least for new installations.
Because for most uses, it's not the best option. So, if you're going to junk ext2 compatibility, why would you go to Reiser?
"....mirror anything without permission..."
Who in their right mind would do that? Of course permission was implied, moron.
The link to this article was posted on Librenix earlier today so I got to read the whole thing before it got slashdotted. Is slashdot getting slow? Anyway I think I will switch to ReiserFS since that is what is recommended by Gentoo anyway.
My boy, my boy!
From FreeBSD, that is... Would be nice to see that compared to Linux' FS-es. As in this earlier benchmark (PDF).
In Soviet Washington the swamp drains you.
I've been going through similar benchmarking to try to figure out what filesystem to use for an NFS server. I don't have anything comprehensive yet, but it is frequently the case that a filesystem that appears the fastest locally is slower than others over NFS.
mkfs.jfs actually gives a warning that you might lose data on the partition?
What is the world coming to?
...making Linux just a little more fun!
/dev/zero. /dev/null.
Benchmarking Filesystems
By Justin Piszcz
INTRO
I recently purchased a Western Digital 250GB/8M/7200RPM drive and wondered which journaling file system I should use. I currently use ext2 on my other, smaller hard drives. Upon reboot or unclean shutdown, e2fsck takes a while on drives only 40 and 60 gigabytes. Therefore I knew using a journaling file system would be my best bet. The question is: which is the best? In order to determine this I used common operations that Linux users may perform on a regular basis instead of using benchmark tools such as Bonnie or Iozone. I wanted a "real life" benchmark analysis. A quick analogy: Just because the Ethernet-Over-Power-Lines may advertise 10mbps (1.25MB/s), in real world tests, peak speed is only 5mbps (625KB/s). This is why I chose to run my own tests versus using hard drive benchmarking tools.
SPECIFICATIONS
HARDWARE
COMPUTER: Dell Optiplex GX1
CPU: Pentium III 500MHZ
RAM: 768MB
SWAP: 1536MB
CONTROLLER: Promise ATA/100 TX - BIOS 14 - IN PCI SLOT #1
DRIVES USED: 1. Western Digital 250GB ATA/100 8MB CACHE 7200RPM
2. Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM
DRIVE TESTED: The Western Digital 250GB.
SOFTWARE
LIBC VERSION: 2.3.2
KERNEL: linux-2.4.26
COMPILER USED: gcc-3.3.3
EXT2: e2fsprogs-1.35/sbin/mkfs.ext2
EXT3: e2fsprogs-1.35/sbin/mkfs.ext3
JFS: jfsutils-1.1.5/sbin/mkfs.jfs
REISERFS: reiserfsprogs-3.6.14/sbin/mkreiserfs
XFS: xfsprogs-2.5.6/sbin/mkfs.xfs
TESTS PERFORMED
001. Create 10,000 files with touch in a directory.
002. Run 'find' on that directory.
003. Remove the directory.
004. Create 10,000 directories with mkdir in a directory.
005. Run 'find' on that directory.
006. Remove the directory containing the 10,000 directories.
007. Copy kernel tarball from other disk to test disk.
008. Copy kernel tarball from test disk to other disk.
009. Untar kernel tarball on the same disk.
010. Tar kernel tarball on the same disk.
011. Remove kernel source tree.
012. Copy kernel tarball 10 times.
013. Create 1GB file from
014. Copy the 1GB file on the same disk.
015. Split a 10MB file into 1000 byte pieces.
016. Split a 10MB file into 1024 byte pieces.
017. Split a 10MB file into 2048 byte pieces.
018. Split a 10MB file into 4096 byte pieces.
019. Split a 10MB file into 8192 byte pieces.
020. Copy kernel source tree on the same disk.
021. Cat a 1GB file to
NOTE1: Between each test run, a 'sync' and 10 second sleep were performed.
NOTE2: Each file system was tested on a cleanly made file System.
NOTE3: All file systems were created using default options.
NOTE4: All tests were performed with the cron daemon killed and with 1 user logged in.
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.
CREATING THE FILESYSTEMS
(snipped. too many junk characters0
BENCHMARK SET 1 OF 4
In the first test, ReiserFS takes the lead, possibly due to its balanced B-Trees. (If the images are hard to read on your screen, here's a tarball containing larger versions of them.)
All of the files systems faired fairly well when finding 10,000 files in a single directory, the only exception being XFS which took twice as long.
Both ext versions 2 and 3 seem to reap the benefits of removing large numbers of files faster than any other file system tested.
To make sure this graph was accurate; I re-benchmarked the ext2 file system again and got nearly the same results. I was surprised to find how much of a performance hit both ext2 and ext3 take during this test.
Finding 10,000 files seemed to be the same except for XFS; however directories are definitely handled dif
As he wanted a test of how people really use the file system, he should have included a simulation of when people forget to remove all the junk they've put on the disk.
What was the reason for the panic? I've been running my system HARD for years without any panics.
If your hardware or kernel has problems you can hardly blame a filesystem that's expressly designed for high-reliability hardware for data loss.
'journalling' is not any better than none when it comes to flaky hardware or a badly compiled kernel. All it means is that you don't have to wait an hour for fsck to run. The whole point of a journalling FS is that it 'knows' what files are suspect after a major outage and it quarantines them, it's not any better at preventing them from being corrupted.
All in all, I can say that Linux an other Unices are VERY sensitive to improper halts/panics/shutdowns. I've hosed several OS X machines by not exiting gracefully, and several Linux boxes too. Your number-one priority when setting up a system is to do what it takes to keep it from crashing, ever.
When I built my desktop I carefully selected components that were 100% Linux-compatible so I wouldn't have issues like the ones you described.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I have been using XFS on a Laptop for 2+ years who's hardware was bleeding edge at the time of purchace.
Because of hardware/configuration issues, I have had to hard-reboot the laptop countless times during the months that hardware support in the kernel caught up. (It works pretty well now).
I have never borked my filesystem.
I'm using JFS on a really large volume (800GB, >15 mio files iirc, >300.000 dirs) for mission-critical data and it has recovered from the heaviest outages.
Performance is good (write performance is a bit weak, 1Gbit/s is not possible), and it does scale well (~30s after a unclean shutdown) with more and more data added.
A full fsck runs something between 30-60mins.
I use a seperate journaling volume on the native and fast raid1 disks of my server (my volumes are on an external RAID).
If you can sacrifice performance, ext3 with data=journal may be good for your "abusing".
Redhat 9 and Fedora Core 1 both ship with JFS support -- the graphical installer, however, does not offer it as an option.
So, what I usually do when installing a new copy of Fedora or Redhat is to drop to a console, and use fdisk + mkfs.jfs manually. Then, when I get to the right page in the installer, I can simply set it to not reformat the partition but to use it as the "/" mount point, and voila -- my computer has JFS.
There are options, or settings, that you can do for ext3, the default is slower, but it saves your data. Ext3 not only journals metadata, like XFS, etc... but it also journals data, which is the only filesystem that does that, if I understand this correctly.
/etc/fstab and reboot, no big deal.
"data=writeback" mode does no data journaling, only metadata journaling, and you would probably see better performance here. Although, you could lose data in the event of a power outage (no fun). Same thing applies to XFS, JFS - you could lose data because only metadata is being journaled, not real data.
"data=ordered" mode - inbetween, still no data journalling, but there are provisions that make it less likely to lose data in the case of a power problem. It has something to do with the way it journals the metadata and the way the filesystem interacts with the disk that makes is a little slower than data=writeback but also a little more secure than data=writeback if you get a power outage.
"data=journal" mode - this journals data and metadata, and with the exception of a few situations, is the slowest. The least likely to lose your data, but also much slower.
I am assuming, or at least it looks like, these tests were run with the default data=journal - so to be fair, they should have been run in data=writeback, or maybe even all three modes. Again, all you have to is specify in
It would probably be better to compare the ext3 in data=writeback mode.
Does anyone have any statistics for how HFS+ (testable with Darwin stacks up against these other filesystems?
mbbac
Am I the only one who still uses it?
Lynx.
It doesn't support GIF either though.
I use ReiserFS, because on average - it is a faster filesystem than EXT3 for most desktop purposes. I personally feel that EXT3, however, is a more reliable FS when it comes to recovering bad data on the hard disks. I recently had some failures due to a failing motherboard, which corrupted some data on my drive, but the reiserfsk tools have cryptic descriptions for failures and don't always seem to do the job right when it comes to recovering bad data. I've had reiserfsck work properly, but the few times that I have had hard drive failures, I've had little success in recovering bad data on a ReiserFS partition.
I must admit though, that any problems I've had on a ReiserFS system weren't necessarily the fault of the filesystem (instead were related to failing hardware). I've run several machines, with multiple drives, which all use ReiserFS. It's been quite reliable in that sense.
I guess that the only way you're going to get true reliability is to make redundant backups.
Why is it that every benchmarking article contains the words "The results may surprise you?"
Have any of you ever been surprised?
I don't much care about ReiserFS, but why don't they at least offer XFS as an *option*?
Well, the simplest answer is that Stephen Tweedie is their filesystem guru, so why not use his baby in their OS. However, that's not the real answer. SCT is a clever guy, and mature enough to not let pride get in the way of the best possible system. (a similar question: Why does sun still use UFS?) For Redhat, EXT3 is probably the best general purpose filesystem, particularly for the root drive. Redhat is interested in selling on servers, where the root filesystem is not the bottleneck. You install the OS onto EXT3, which has decent performance and is very mature. Then you install your database / exported directories / mail spool / whatever onto the filesystem that is best for that job.
Ext3 is a very close cousin to Ext2, which has been around for a very long time, and changes very slowly. Reiser has grown and changed a LOT in the last three years, including some metadata changes that effect on-disk structures. Though it has stabalized lately, Redhat is correct to be cautious. XFS and JFS, though very mature filesystems on other OSes, have only recently become tightly integrated with the Linux kernel. Though technically controlled by the linux kernel community, all three of these other filesystems are really controlled by little cabals of people within IBM/SGI/ and then Hans Reiser. While these groups try to be transparent in their development process, Ext3 is very transparent in its development and direction.
One other tremendous advantage that Ext3 inherits from Ext2 is a fast, versatile, and effective fsck program. Journals are great in the event of power failures. However, they do not protect against Windows, or a faulty fibre channel driver, or uninformed sysadmin who accidently writes over the first 1 MB of the disk. Fsck.Ext2 is one of the best around.
You know - if it works, don't fix it!
Ext3 is stable and there's a lot of useful available tools for it.
If, for the end user, the difference is marginal, why bother to make things more difficult than necessary for yourself?
Or maybe they've received unusually many bug reports for ReiserFS and thus concluded it's not stable enough for them to push it. After all, they want to be associated with (amongst other things) reliability.
Stop the brainwash
Sorry, but there are a few reasons these results are questionable. As one poster has already pointed out, ext3 by default journals both meta data (i.e. directory structure) AND data. The other three by default only journal meta data.
But more importantly than that is the fact that in linux, that IDE drive is responding immediately to fsync requests before it's actually done them. I.e. when the journaling file systems says "hey, did you get that stuff written out to the disks?" The drive says "yes sir!" Then writes it out whenever it gets a chance after that.
This means that you may well have a corrupted directory structure should the machine lose power in the middle of writing data, because the hard drive LIED to the OS, and the journaling file system flushed out it's journal when it wasn't actually written to the disk.
To get trustworthy results, you need to either 1: turn off the write cache on the IDE drive or 2: Use SCSI, which doesn't lie about such things.
As long as you're writing to an IDE drive with an enabled 8 meg cache, the results are worthless, because you don't actually have the reliability you think you have, and the numbers might change drastically when you start using drives (like SCSI) that actually fsync properly.
--- It is not the things we do which we regret the most, but the things which we don't do.
"Both ext versions 2 and 3 seem to reap the benefits of removing large numbers of files faster than any other file system tested." If that's not a joke, it should be.
What the heck is a 'sig'?
I think Reiser4 beats NTFS in pretty much any aspect, and, communti willing, will also beat WinFS, at least in performance.
Please correct me if I got my facts wrong.
it's not slashdotted yet :)
it's not slashdotted... yet. >:)
Live today, because you never know what tomorrow brings
I did a bunch of tests like this, but in 2.6 instead of 2.4. My conclusions:
* Ext2 is still overall the fastest but I think the margin is small enough that a journal is well worth it
* Ext3, ReiserFS, and XFS all perform similarly and almost up to ext2 except:
o XFS takes an abnormally long time to do a large rm even though it is very fast at a kernel `make clean`
o ReiserFS is significantly slower at the second make (from ccache)
* JFS is fairly slow overall
* Reiser4 is exceptionally fast at synthetic benchmarks like copying the system and untaring, but is very slow at the real-world debootstrap and kernel compiles.
* Though I didn't benchmark it, ReiserFS sometimes takes a second or two to mount and Reiser4 sometimes takes a second or two to unmount while all other filesystem's are instantaneous.
Whole thing available here
Seriously, all the time we see benchmarks like this that are just done on the same machine with the same setup. Who knows if there is some unseen problem or bottleneck (in this particular case the CPU is weak).
We need a large sample base. Different types of chipsets, CPU's, hard-drives, etc. Then we can better see the big picture or at least see how the filesystems might perform on a system similar to your own.
So I'm calling for a "filesystem benchmark" page were people can post their results from a standard set of benchmarks. Something where they can include their system specs/setup and everything.
Then maybe we'll get useful information.
The ratio of people to cake is too big
I would hope to think most people storing vast amounts of data aren't just using their hard drives as a scratch disk and actually want to STORE them for some amount of time. For that reason you'd think stability would be something important to look into instead of just raw unrelenting speed.
Is there such as thing as an ACID complete filesystem in the works? That's the name of the game for RDBMS reliability and the reason why MySQL blows and loses data all the time (it doesn't even TRY for ACID completeness, just speed).
Is version 4 of ReiserFS done yet and in the new kernel? I am interested in seeing benchmarks of that puppy. Reiser seems to be interested in revolutionary improvements for the filesystem.
A bunch of months ago I formatted several of my partitions with ReiserFS and I was happy with it, it was fast and more space efficient than ext3... until I was trying to get UT2003 working with my ATI Radeon... the system locked up hard and after the hard reset some files (my lilo.conf, which shouldn't have been written to at that time) were hosed. I'm back with ext3 as data integrity is important to me.
Judging from posts here, it appears that ReiserFS is still experimental and shouldn't be used by those that care about their data, hey?
... text on his graphs/charts very well. The text is a bit small, so I just skipped down to his conclusion. I'm glad to see that ReiserFS is one of the "performing" file systems because that was my choice.
Free Firefox news reader.
There is also some commentary and recommendations based on their results.
One more note about the tool... it's not well documented but works well when configured... note that you need a kernel that supports the filesystems to be tested (duh!), Use python 2.2, the database schema is somewhere in the comments.
the results may very well surprise me, if only i could read them, maybe indexed PNG would've been a better choice, but even then i'd probably still need the FireFox image zoom extension to make out the bloody legend.
Software Freedom Day!.
Maybe it's because they'd have to increase the support contract costs to cover a higher incidence of serious filesystem related problems?
ReiserFS is nice, but it's not even close to corporate production stability.
Datacorruption issues are what keeps people working extended rotating shifts for days until they get stressrelated breakdowns in corporate environments.
Performance issues are what keeps people working normal days mulling interesting issues and eventually deciding to throw hardware at the problem.
Performance just isnt as important in most cases.
Which one you should choose depends on your needs and etc.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
I'm thinking a sample size of 1 isn't enough to reliabily comment on the overall usability of these file systems... just my 2 cents...
He benchmarked 2.4, which these days is a bit...pointless. Ext3 has a lot of improvements only in 2.6, just like the other FSs. 2.4 filesystems are in "mainteinance mode" where in 2.6 there's been a large amount of development. If he'd run 2.6 he could benchmark reiser4 too.
So, what I usually do when installing a new copy of Fedora or Redhat is to drop to a console, and use fdisk + mkfs.jfs manually
You're making things unnecessarily complicated. At the "boot:" prompt, just type "linux jfs". The graphical installer will then offer it as an option. Works with reiserfs, too.
You can see benchmarks of it at www.namesys.com/benchmarks.html
And the Ext2 debugfs is one heck of a powerful file system debugger. It is the Swiss Army Knife of file system tools. Most folks will never need to use it. But if one ever does need it, he can thank his lucky stars that it is available.
Although not a linux filesystem, OSX being based off BSD uses it, and is *nix based in a way. You can mount it from Linux (read only I think).
I no longer will even attempt to use EXT3 for a filesystem ~500GB or larger. Had problems repeatedly with a couple of 1.6TB filesystems and switched to Reiser3 and haven't looked back...
/ /boot /data /dev/shm /usr /var /raid1 /raid2
# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 4032092 548856 3278412 15%
/dev/sda1 505605 19171 460330 4%
/dev/sda7 41729164 31165820 8443572 79%
none 2000568 0 2000568 0%
/dev/sda3 10080520 6437952 3130500 68%
/dev/sda2 80636072 45306536 31233364 60%
/dev/sdb1 1600772128 1462009904 138762224 92%
/dev/sdc1 1600772128 760247416 840524712 48%
PS. No, it's not pr0n
Arg, I hate hate reiserfs. It has even with the latest incarnations of distros been crash-prone relative to other filesystems, and more painful to recover than other filesystems in the event of a crash (>90% of the time when the fs needs help, it needs to rebuild tree, and read-only mount *still* screws that up, so you have to boot rescue)....
XFS also I've hit numerous issues (seems not to track free space correctly in near-full conditions, and will panic when it tries to write as it suddenly realizes the fs is really full!). My test was in near-full 360 GB filesystem, make a 500 MB file, delete it, remake it, delete it. Now you should be at the same spot, but you magically have nealy 500MB extra free space according to du.. Really flaky...
I have good experience out of JFS and ext3 with respect to reliability, though ext3 has been a bit more sluggish.
I care about performance, but reliability takes priority.
XML is like violence. If it doesn't solve the problem, use more.
oh no, all those people running IE 3 can't see png, better not use it.
Snowden and Manning are heroes.
The results were what we knew already :
/usr and other such places, or a partition used for a lot of development work or website development.
-> reiser is really fast with small files but sucks when deleting/moving.
-> XFS is great at deleting, but slower than Reiser and it's not good at searching, but great with large files.
-> JFS seems to be great with large files too, but not much else.
So, in other words, ReiserFS would be great things like
XFS and JFS seem to tie when it comes to handling stuff like ISO images, large database backups...so you might want to use one of them for that, depending on your needs.
What I would have really liked to see is a benchmark with these against upcoming file systems like Reiser4 purely from a performance point of view. Now THAT would have been interesting.
As of now, the only interesting thing is that the results have not changed since early benchmarks on these file systems done more than a year ago. I wonder why.
Find a job you like and you will never work a day in your life.
....for all file system creation, default options were used.
Find a job you like and you will never work a day in your life.
I use JFS on servers that have netatalk (with bdb enabled) and samba because I can make a partition case insensitive. I think it was a feature developed for OS2 originally, but it works well. I use a -cO when formatting with makefs.jfs .. the O is for OS/2 (but makes the partition case insesitive). I had corruption problems with earlier versions, but ones that have shipped with 2.6 kernels and current 2.4 kernels are no problems. I have not tried it to see if it works on / partitions with linux system files. (Case insesitivity could cause problems with like named stuff)
Performance is good and reliability seems good as well. It was deff. faster than when I had it set up as ext3. My linux servers have had less problems then my OSX jaguar server with file corruption using HFS+ - the linux solution was a cheapo old Mac because we could not affored a Mac server at the time.
-Ron
It put every file on my PC into lost+found.
Less look fast, more go fast.
Gah! The charts are shrunk so that the labels are hard to read, and the order of the results and color assigned to each FS seems to have been picked randomly for each chart, so once you squint and decipher one of them...you have to start over on the next.
While I appreciate the information greatly I found it extremely difficult reading the graphs as the text was entirely too small and the bars, were proportionally too big. Am I the only one who has trouble reading this stuff?
TT
Here are some of the programs from
. info/
h ttp://rlplot.sourceforge.net/
the list I made:
http://pyx.sourceforge.net/
http://www.gnuplot
http://plasma-gate.weizmann.ac.il/Grace/
I've used gnuplot before, it's ok. I've
never used Pyx, but the output on their
website looks nice. (I've always had a bit
of a soft spot for the looks of Latex
output, so ymmv.)
You could also look at Guppi. OOo and KOffice
have to have some graph making ability in it,
too. Those may be better for the casual graph
maker.
Hm, just looked at Guppi's home page they
have a link on the left to other graphing
programs available, some of which I've missed
entirely. Anyway, there are a ton of them
out there, it would be tough to even make
a complete list.
J
A superior string of tests would be to simulate, to as close a degree as possible, a real, live high-use environment such as a scaled-up Perforce server, a supremely busy mail server, a giant busy database, or a massive web server.
A single process running through 10,000 files isn't particularly realistic: since when does a scaled-up server sit there and hammer the filesystem with just a single process? What about contention? Caching?
And what about recovery from errors? I didn't once see what happens if something blorts over random parts of the filesystems.. how does Reiser handle this? Ext3? XFS? Are there recovery tools in case of catastrophe?
What about these file systems stuffed into RAID volumes of various stripe sizes and configurations?
Straight deletes, creates, or modifications are useless because the only time you're going to be doing something like that is when you rm -rf * or building a new environment for.. something. Daily use, however, which eats up far more time (and thus would save the most user time if improved) is something which should been better accounted-for.
Just out of curiosity, why wouldn't one go for ext2 on root filing systems? Typically a root FS isnt that large anyway, I think I can live with a fsck for a few minutes.
All the extra overhead that journalled filing systems bring don't seem to be worth a little speedier error recovery..
I'm rapidly approaching the point where I need support for file sizes greater than 2GB. Quite frankly, most of what I've found about file sizes and file systems is 2 to 4 years old... Everyone's too concerned with speed!
I'd like to see a set of benchmarks regarding stability and fidelity of the various filesystems. Which ones are the most durable? Which ones get corruption the most, and what are their corruption/data-loss ratios? Performance isn't the end of the world for me....but losing data *is*.
Don't become a regular here, you will become retarded. -- Yoda the Retard
Did anyone else notice that the orientation of each graph was different than the preceding one? Was this done to deliberately make it harder to compare results?
I can't see what possible motivation there was in this decision. I'm also having a hard time imagining how much more WORK it was to arrange the graphs so.
I think that he could use a refresher with Edward Tufte's The Visual Display of Quantitative Information-- quite possibly the best book on graph theory every written.
The cure for cancer is coming: Reovirus
I stopped reading when it said he was usin a 2.4 kernel.
2.6 performance is that much better.
Get a clue, guy.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
Might be useful to also mention which of these have support for large files. At one point I settled on XFS for my systems (which has worked without flaw for me so far), since it has large file support.
It seems to me that Linux filesystems are rather behind the times when it comes to this area.
The graphs wouldn't have looked so bad if they'd have kept the orientation and order in the graphs the same from one graph to the next.
In some xfs is on the top, others it's on the bottom. Thankfully in the l2r graphs XFS is always on the right and ext2 on the left. Also, they seem to abitrarily switch between 2d and 3d graphs. Plus the switch between bar and line graphs.
I'd start my focus not with the tools but with the ways in which the tools are used.
--JLockard - "Some mornings, it's just not worth chewing through the leather straps." - Emo Phillips
Journal size! By specifying a larger journal size at creation time (or late with tune2fs) you can gain significant speed. The default is 32megs. If you're pushing a lot of data into and off of disk rapidly (busy mailserver), increasing this to 128mb will help (along with things like mounting with "noatime" ).
Being able to tune your tools for a specific purpose is what makes all of these filesystems great. But you've got to learn to use them properly!
this test didn't cover random access, and incomplete information regarding blocksize and no benchmark program involved. besides, the results are very hard to been seen. this is just another newbiz test posted into Slashdot somehow, like the one couple months back comparing U320 and SATA.
Wow...I'm really surprised that I don't see anyone else around here bashing this "benchmarking" as totally ridiculous. Get it together, people! I mean, how does a group of folks that typically pride themselves on shredding the foolish articles that come by miss these beauties:
1) This guy goes out with the stated goal of evaluating real-world performance...so he starts by throwing out all real benchmarks. Of course, those tools are designed by experts to try to represent real-world performance, but who cares, right? Instead, our jackass throws together a bundle of random operations and times them. No thought is apparent in the choices of the operations, and no discussion is given as to why the choices were made.
2) The conclusions are drawn by simply adding the times of all the tests together. If you haven't figured out why this is dumb as a rock, let me explain: test #1 took 23-40 seconds, while test #2 took .02-.04 seconds. So, in his conclusion, test #1 was weighted 1000 times as heavily as test #2. I don't know about you all, but I for one don't feel that touching speed is 1000 times as important as finding speed.
3) Even if he had normalized all the times so that the mean in each test was the same and then added those, he would still be wrong...various tests ought to be weighed differently, because real-world usage doesn't do all of these things the same amount. That said, the weight given to the tests needs to be well thought out and planned, rather than arbitrarily assigned (accidentally) without paying any attention. Interestingly enough, this sort of purposeful weighing of tests is exactly the sort of thing done by the real benchmarking tools that this idiot threw away.
4) Perhaps this one isn't as important...but this guy can't make a graph to save his life. Half the bar graphs put time on X and the other half put time on Y. Graphs that obviously should be bar graphs are made into dot-line ones. The text is blurry and you can't tell the colors in the key.
Anyway, I still don't get why everybody around here seems to have missed all this...it was painfully obvious to me when I just took a cursory glance at it.
Given a choice between free speech and free beer, most people will take the beer.
Worst. Bargraphs. Evurrrrr!
-- Having a Creationist Museum is like having an Atheist place of worship
Ok, a bunch of us are talking about past experiences with catastrophic hardware failures, and losing data on Reiserfs filesystems. But we need to remember - it is not smart to draw conclusions from anecdotes!
/tftpboot directory (sob). During this copy, the hard drive crunched and snapped and ground like a dying beast, while my trusty old reiserfs kept slowly pulling off the files.
Do you really think you would NOT have lost the same data if you had been running ext3 when that hardware failure happened? It sounds to me like it was just a *coincidence* that you were running reiser.
My main server experienced a nasty-blue-smoke power supply failure this past January. I had all my precious 200G of data on a pair of linux-software-mirrored hard drives on Reiserfs. After replacing the power supply, I noticed that my mirrors were not successfully re-mirroring. One hard drive was completely dead. Soon it became apparent that the other one was half-dead as well. So I dug around for my trusty Knoppix CD and booted it up (Klaus - you da man!), an was able to copy the entire 200G of data off the remaining hard drive, with the sole exception of my
So, of course, now I've sworn to run nothing but reiserfs on my server till the end of time! I still run ext3 on my laptop because of the simplicity, but nothing but reiser will ever run on my server.
Still, I can NOT claim that reiser is any better than the other filesystems, because I've never experienced the same problem with an ext3 server or XFS or JFS, etc. I'm just sticking with what I know.
Not much more than 200 years ago, the scientific community fully believed and taught that rats spontaneously generated from garbage. Why? Because they observed that if you leave a pile of garbage in your basement overnight, you have rats in the morning. This was a severe lack of critical thought, and a widely accepted conclusion drawn from anecdotes. Please tell me our thinking has progressed at least somewhat since then!
Here's some real world information on the state of large file support in 2004. Filesystem driver support is the least of your worries -- almost any linux filesystem you can think of (except for maybe umsdos) supports over 2GB files at the kernel level. The Linux LFS page, dated April 2004, contains reasonably updated information on large file support in linux.
The bigger problem is that many userspace applications cannot yet read or write to the large files. This failure arises from non-use of the LFS API combined with just plain unfortunate use of a signed 32-bit int in the wrong place. So for instance mkisofs will reject all input files larger than 2GB in size, and cdrdao will simply abort at 2GB if you try to rip a DVD larger than 2GB in size. In some extreme cases there are programs that can't even handle large files off of the disk; one example is
wget http://mirror.linux.duke.edu/pub/fedora/linux/core /test/1.92/i386/iso/FC2-test3-i386-DVD.iso
which fails spectacularly on any x86 linux system (hint: the DVD is not really 84MB in size). In general, the "core" system utilities such as dd, cp, mv, cat are fully compatible with large files whereas third party applications are much more hit-or-miss.
Even today, by far the most practical solution to large file woes is to migrate to a 64-bit system, the most affordable of which is AMD64 by a long shot. I've been using an Athlon 64 system for the past few weeks and it has handled large files perfectly in all respects so far.
Sun uses UFS because it is still the best filesystem for a root filesystem.
A more interesting question is: Why do Linux zealots incessantly rag on UFS?
so what happens in this situation? will all v3 partitions need to have their data moved to another partition so that it can be reformatted or is there some sort of utility that namesys provides to ease migration?
Yes, I have RTFA. Yes, I have a girlfriend. Yes, I'm new here. And no, I don't want a free iPod.
So dual boot a kernel that isn't crippled by a lack of open-source file systems being ported to it. Don't blame a file system for FreeBSD's lack of support, blame the BSD developers.
I do not fail; I succeed at finding out what does not work.
...time to fsck, and recovery after a crash for the journaled file systems ? These are of greater importance to me than 10000 deletes. How long will it take to verify my file system of 300GB after the sysadmin killed power to the wrong server ? Did I lose any data ? you know the drill.
Plus the results are normalized against ext2 for quick comparison. You don't have to interpret fuzzy jpeg graphs. You can grok the results at a glance.
Skip the LinuxGazette article and read the parent link instead.
With all due respect, as your website states:
and (on the download page):I would say benchmarks need to be performed with released products. It doesn't help most users if Vendor X claims his vaporware beats all competitors. Now, I know this isn't the case with ReiserFS here -- it isn't vaporware -- but it isn't production-ready either according to Namesys. You're just unfortunate in that this benchmark was performed just before the release of your next version which would have performed better.
On the other hand, any benchmarks published on the Web ought to be updated whenever a new version of a tested product is released -- add the results of the new version and keep the old one as well, for comparison purposes.
CONCLUSION
For those of you still reading, congrats!
Am I the only one who just read the conclusion for these tests?
If you mod this up, your slashdot background will turn into a beautiful sunset!
Just some datapoints to counter yours:
We (ISP) had about 5 major data loss disasters with ext3, 3 with XFS and only 1 with reiserfs.
And we use far more reiserfs than ext3 or xfs. So from a reliability standpoint for us, reiserfs is by far more reliable than ext3 or xfs.
And here I was thinking that almost all of the current distributions (meaning not ones announced/released yesterday), like Red Hat 9/ RHEL , Fedora, Suse 9, Gentoo 2004.1, Debian... -- were shipping with default 2.4 kernel?
Although less hyped, JFS is doing pretty well so I see. I've been checking out other benchmarks as well. Some people mentioned it's even faster than XFS in some cases. I myself am using Reiser but I'm looking forward to checking out JFS in the future. It's been in the kernel long enough to have stabilized. XFS in kind of young in 2.4. Yes it has exsited before as a patch but I won't use anything on production systems until Linus accepts it in the mainstream kernel.
let's see you make a better one then.
I didn't realize it wasn't case sensitive. It can be turned on in newer versions, so I take it it is off by default? How exactly does one enable that? I don't know enough about macs, only reason it was mentioned bc a friend on OSX burned me a dvd of all my files, only he screwed it up and (by default) the cd came out as HFS +. Apparently, I didnt have the kernel mod enabled by default and it caught me offguard ona busy day. Also didnt realize it was a journalized FS. Im considering going with a mac laptop, so all this info is useful.
So I wonder how the speed would compare to EXT2/3, or any other aspects as far as file systems are concerned. Or NTFS (which I also have unsecessfully tried to write to with shaky results).
Is V4 in Kernel 2.6.x yet? I want to check V4 out for myself.
Trying to socially engineer a Linux virus?
if you really matter about filesytem performance you'll use some options like disabling access time updating.
ext2 should be mounted with noatime, reiserfs with noatime,notail,nodiratime etc..
not using the usual performance-oriented mount options (only the ones that don't compromise FS security) :(
makes this benchmark a lot less meaningful
Is there any alternative to NFS?
Is there any filesystem one can use to "mount" a directory (with gigs of ready to run applications) directly from Internet server (i.e. from his Internet Service Provider)?
How is open source prevented from overwritting kernel memory? All you need is mapped memory and port access in a user-level shared library, plus a daemon to switch back to text mode if the library's process dies without a clean shutdown.
ext3 keeps hitting the disk. you could just remount that ext3 as ext2, havent tried randomly going back. doing a "real" convertion is probably safer...
I was thinking that myself. Running both Linux and FreeBSD it seems important to run UFS.
Its more stable and solid then ext2 anyday.
http://saveie6.com/
Many of the ext2 filesystem errors are "easily fixable" by losing the affected file. I remember losing several system files due to unclean shutdown, and once even had a system that was rendered unbootable because /sbin/init was lost. I was very annoyed, having used FreeBSD before on really crappy hardware and never lost files unless they were open for write at or very near the time of the crash.
Nowadays I _always_ use journaling filesystems. In my experience, ext2 is an unreliable piece of crap unless your hardware, software, power source, and operator are all 100% reliable.
I've been using ReiserFS on my home box for several years now with no problems at all, though I've heard of serious problems with it so I've been reluctant to use it for servers. I've used ext3 on servers and my laptop and seen unclean shutdowns (mostly on servers not yet in production) with no problems either. I'll probably try XFS in the near future.
The Internet Archive Petabox seems to use ReiserFS. Interesting, to say the least. Even more interesting would be if one of the developers that helped make the call shares some insight.
Must-not-watch TV!
Because ReiserFS is a pile of dung, designed to make sure you lose data, make your computer unreliable, and make people scratch their heads and swear of linux in general. Here's my scorebook with reiserfs so far:
/home partition went to hell twice, at power failure. /home partition smothered at power failure, had to rm -rf .kde for the system to get up'n running again.
- Laptop
- Two various machines at previous work got open files in
- Mums computer. Had to travel 500km to fix a reiserfs fuckup due to repeated power failures.
- Dad's laptop got a partition trashed by reiserfs when he forgot to put in his power cord and the battery time were used up.
I've tried using ReiserFS on and off quite a bit during the last 3 years. I don't think I'll ever do so again, unless rumors says it's stable in 5 consecutive years or something like that. I've had no other filesystems cause me as much grief as ReiserFS. It's a pile of dung. I'm not grateful that the developers developed it. If I knew how shitty it was I would never have put data on it. I don't have time to travel 500km just to reinstall a linux distribution every two months, due to ReiserFS fucking things up badly.
The reason some distributions doesn't move to ReiserFS is quite simply that they've realized that ReiserFS is one unstable piece of horse dung.
"Rune Kristian Viken" - http://www.nwo.no - arca
Test 002 is meaningless: the times are too short to have any statistical significance whatsoever.
Some of the comments are foolish; for example, Test 009: "Surprisingly, ReiserFS wins". Why is that surprising? Perhaps it follows from the design of ReiserFS. It's as if the benchmarker does not realise that different algorithms and design goals are involved in each filesystem.
Finally, I agree completely about the graphs, they're illegible. It's indeed amazing nobody has pointed this out. The guy desperately needs to buy and read a set of Tufte's works.
For this to be a useful benchmark, at least twice as much intelligence and effort would need to be applied...
you had me at #!
OffTopic
Whom should I sue for hurting my eyes with those microscopic legends by the charts?
yes I am lazy enough not to download the tarball, extract it and switch between the article and each of the images
To me, the ability to both shrink and expand the filesystems is also essential. In brief, ext3 can be expanded and shrunk offline. XFS and JFS can only be expanded. ReiserFS supports both shrinking and expanding. IIRC, ReiserFS can be expanded, but not shrunk, online. XFS can probably only be expanded offline. I think JFS can only be expanded online (which I think is a bit weird, but OK
On my computer (with enough CPU power for it to probably not be a bottleneck - Athlon XP 2600+), these are some timings for operations like extracting a huge
(this looks terrible because I couldn't get even the ecode tag to work nicely, so it's a hack)From this it seems to me that overall reiser4 would be the clear winner when CPU is not the bottleneck. Unfortunately reiser4 didn't seem very stable although it was claimed "it's usable but still not recommended for production environments". Even during my tests I got repeatedly data loss, and after typically a couple of days of heavy reiser4 use top started to indicate that almost 100% of the CPU time was being spent in a syscall (and some processes became unkillable), a probable sign of a reiser4 operation in a syscall ending in an infinite loop (it didn't use disk in that loop though). I could not reproduce this kind of problems with any of the other filesystems.
I think reiser4 is definitely a promising filesystem with interesting concepts for systems with lots of CPU power, however as this is not the first time I've had problems with reiserfs (even production versions), it's going to be a while after it becomes stable after I'll be ready to even test it again and consider adopting it.
Perhaps you should check out this article (Journaled filesystems on Xeon) from Open, an e-zine covering open source and Linux. It takes a more scientific approach to benchmarking filesystems.
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
It's a bit miss guided to assume that fast disks / file systems make that much difference to the speed of a "typical machine".
The most important bottle neck, for most machines is the I/O system itself. This is typically 100 times (or more) slower than main memory. All the file systems quoted are several orders of magnitude slower than direct memory access.
If you stop a machine writing to disk, or make it write as little as possible it will obviously go much faster. But then we have the problem of what happens if the machine crashes. How much data have you lost ?
File system (disk) writes are typically 5 seconds / 30 seconds behind in terms of actual data written. For a busy web server this is a lifetime.