“These are the results of a series of tests I did using IOZone to determine the performance of various filesystems under Mac OS X. I tested HFS+, HFS+ w/ journaling, HFS, UFS, and Ext2 . Due to wide variation in the results, I did at least 4 runs of each configuration and then used the best score for each test.” Read the benchmarks here.
Mac OS X Filesystem Performance Comparison
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Didn’t I read somewhere that OSX will sync with FreeBSD 5X, which would then include UFS2? I am curious what the difference in speed would be if any.
What would be more interesting than UFS2 would be having UFS + SoftUpdates available by default (which is the case in 5.x). SoftUpdates greatly speeds up writes, because metadata (like file-size changes) do not need to be written synchronously to disk. I don’t know if OS X can do SoftUpdates, but if it can’t, that might explain the slow read results for UFS.
since mid of April delault FS on FBSD is UFS2+SoftUpdates. FBSD 5.1 will default to UFS2+SoftUpdates.
The only conclusion I see (I could not open the charts) is that HFS and all its incarnations is slow, and other FS’s are slow too on Mac OS X because these are not optimized for Mac. I dont know what is compared to what (see reason above). I hope that these charts include linux/ext2 and FBSD/UFS. That would give approximate estimation of specific FS performance under OS X.
Apple did hire the guy that developed the BFS. I would certainly hope that they have that talent being put to good use to develop a more modern filesystem which is less prone to corruption, and less affected by fragmentation.
HFS has been a pretty darn good filesystem considering the support it has for extended meta-data, and it’s database like structure, but it is undoubtedly getting a little long in the tooth.
MacOS X is supposed to provide a good VFS shim to make the system less filesystem dependent, but in my dablings with trying to build a VFS plug-in for an alternative filesystem I was left coming up short on documentation as well as functionality. The biggest problem seemed to be that the primary app development frameworks, Carbon and Cocoa, in some instances make too many assumptions about the filesystem that they’re running on thus making it difficult to realize the benefits of the VFS architecture.
Here’s to hoping for a next-gen BFS-like filesystem in Panther.
When FreeBSD5 was released, there was a comment on http://www.macslash.org presumably by an Apple developer. He said that UFS2 is interesting and they would look in to it.
On the other hand: I’m Bill Gates, and I say that we will make Longhorn opensource under the BSD license.
Could someone summerize the charts? What could be the conclusion?
All those benchmarks are pretty meaningless considering that only HFS+ gives you full OS X functionality in a file system. I find it interesting that they made relative comments like “kind of slow for this type of read”… but they have no baseline. You would think they would make HFS+ the baseline (since it is the standard) and then compare to that. Oh well.
ext2 almost keeps up with HFS+?
I’d like to see how reiserfs and XFS compare. Both I think are really good for small file sizes, but I don’t know anything.
It’s interesting that UFS’ speed is so bad since most larger systems have the same bit orientation as PPC/MC68K. I can’t imagine trying to run web serving from a different file system since it is case-sensitive, not just case-preserving as is HFS+. I found it quite unreasonable when I tried to load Mac OS X onto a UFS-formatted drive. The time for the installation ballooned from 30 minutes to 90+ minutes.
UFS2 seems to be more useful for capacity gains than anything else.
It would be nice to see if the developer of BFS can bring about positive changes. I think it’s quite possible already, if we let go of the need to handle traditional resource/data forks. Bring on the Nibs!
I just wanted to let you guys know that I fixed the broken links to the main charts, and will redo the whole report at some point (just exported from Excel for a quick turnaround – unfortunately it is unreadable HTML for many browsers).
As for the baseline issue – that was the whole point. All the charts and reports are against HFS+ as the baseline. At the bottom of each report is a summary of differences in performance for every test. Check it out with IE or Safari – it should work fine. Only bummer is that the HTML is so massive. If I had known how many people were going to view it (20k+), I would have spent more time testing it and fixing it up…
Jason
What I was referring to is that the charts aren’t comparisons, they’re just charts of raw data. I think comparison charts would be more useful. Unless of course I’m not seeing something obvious, which is entirely possible.
It’s hardly surprising that Ext2 is able to keep up with HFS+. First of all, HFS+ is was already antiquated when Giampalo wrote his book about filesystems, and that was years ago. Second, Ext2 was designed to be an extremely fast filesystem. In many cases, Ext2 is still faster than more “modern” filesystems that suffer a journaling penalty. As for ReiserFS and XFS, they’re quite different. ReiserFS has incredible small-file performance (which is supposed to *double* with the upcoming Reiser4) while XFS has just mediocre small file performance. ReiserFS’s performance on large files is relatively slower, while XFS has steller large-file performance.
4 data points is insufficient to start with but doing four and taking the best result is ludicrous! He should average the results. This study really is as good as worthless unless you yourself look at the data and can observe that the best data point correlates with the in-your-head average.
I haven’t read the article so I can’t comment further.
Well, for not having read the article you are full of opinions….
I am doing 4+ iozone runs of extended reads and writes (2+ hours per run, more than 200 datapoints per run) on a mostly idle system on a freshly reformatted hard drive (formatted between every run). The variance is due to background processes, etc. I fail to see how taking the highest score for a given test across several runs is not scientific (especially as this is done for ALL of the compared filesystems).
As for the charts – they are comparisons to the baseline. The charted number is the PERCENTAGE POINT CHANGE between the baseline and the new filesystem.
People should really read what they are commenting on before they go mouthing off.
Ignore them. This place is full of amatuers.
I have no links to back it up, but I do remember coming across some post (from Jordan Hubbard IIRC) about the ancient implementation of UFS on OS X. The post was asking if anyone was interested in bringing it up to date. I never followed it up, but it definitely explained why my UFS performance on my laptop was so terrible.
Out curiosity: this is what I found about ext2 for OS X at sourceforge:
“Release Name: 1.0a1
Notes:
First alpha release (May 3, 2003 I added the current release date here – MP). There will be no new features added between now and final; bug fixes only.
———————————————————————- ———-
Changes:
Upgraded to e2fsprogs 1.33 (mke2fs, e2fsck, etc)
Fixed a bug in the fs util that could cause a volume to mount as “UNKNOWN” instead of the actual volume name.
The kext will no longer unload if there are active mounts.
Removed some debugging code.
Changed the partition label hint to “Ext2″ to be more inline with Linux. This fixes the bug where drives formatted with Linux would fail to automount. Please note, that if you formatted a drive with a previous version of Ext2 for OS X, it will likely fail to automount.”
SOME debugging code removed not all, so it is going to be slower than ext2 with completely removed debugging.
Also this is alpha release. I understand that UFS support for OS X is also not optimized.
So if you used for benchmarking pourpose filesystems that are not optimized for OS X you should mention that.
If this is the case (I don know too much about OS X so I may be mistaken) and you are using alpha versions against HFS/HFS+ what is your point?
I don’t defend superiority of ext2 or UFS over HFS but the value of banchmarking alpha versions (with debugging code) against optimized versions of anything (not only FS) is questionable.