A Month with Apple's Fusion Drive
by Anand Lal Shimpi on January 18, 2013 9:30 AM EST- Posted in
- Storage
- Mac
- SSDs
- Apple
- SSD Caching
- Fusion Drive
The Application Experience
By this point I’ve talked a lot about the synthetic experience with Apple’s Fusion Drive, but what about the real world user experience? In short, it’s surprisingly good. While I would describe most SSD caching implementations I’ve used as being more HDD-like than SSD-like, Apple’s Fusion Drive ends up almost half way between a HDD experience and an SSD experience.
Installing anything of reasonable size almost always goes to the SSD first, which really goes a long way towards making Fusion Drive feel SSD-like. This isn’t just true of application installs, but copying anything in general hits the SSD first. The magic number appears to be 4GB, although with a little effort you can get the Fusion Drive to start writing to the HDD after only 1 - 2GB. I used Iometer to create a sequential test file on the Fusion Drive, monitored when the file stopped writing to the SSD, stopped the process, renamed the file and started the file creation again. The screenshot below gives you a good idea of the minimum amount of space Apple will keep on the SSD for incoming writes:
You can see that if you’re quick enough you can easily drop below 2GB of writes to the SSD before the HDD takes over. I don’t know for a fact that this is the amount of free space on the SSD, but that’s likely what it is since there’s no sense in exposing a 121GB SSD and not using it all.
In most real world scenarios where you’re not aggressively trying to fill the SSD, Fusion Drive will keep at least 4GB of the SSD free. Note that when you first use a mostly empty Fusion Drive almost anything you write to the drive, of any size, will go straight to the SSD. As capacity pressure increases however, Apple’s policy shifts towards writing up to 4GB of any given file to the SSD and the remainder onto the hard drive.
I confirmed this by installing Apple's OS X developer tools as well as Xcode itself. The latter is closer to the magic 4GB crossover point, but the bulk of the application ended up on the SSD by default.
The same is true for data generated by an application. I used Xcode to build Adium, a 682MB project, and the entire compile process hit the SSD - the mechanical side of the Fusion Drive never lifted a finger. I tried building a larger project, nearly 2GB of Firefox. In this case, I did see a very short period of HDD activity but the vast majority was confined to the SSD.
I grabbed a large video file (> 10GB) I cloned over when I migrated my personal machine to the iMac and paid attention to its behavior as I copied the file to a new location. For the first 2GB of the transfer, the file streamed from the SSD and went back to the SSD. For the next 2GB of the transfer, the file was being read off of the HDD and written to the SSD. After copying around 4GB, both the source and target became the HDD instead. Fusion Drive actually ended up caching way more of that large video than I thought it would. In my opinion the right move here would be to force all large files onto the hard drive by default unless they were heavily accessed. Apple's approach does seem to be a reasonable compromise, but it's still way more aggressive at putting blocks on the SSD than I thought it would be.
I repeated the test with a different video file that I had never accessed and got a completely different result. The entire file was stored on the hard drive portion of the Fusion Drive. I repeated the test once more with my iPhoto library, which I had been accessing a bunch. To my surprise, the bulk of my iPhoto Library was on the HDD but there were a few bursts of reads to the SSD while I was copying it. In both cases, the copy target ended up being the SSD of course.
My AnandTech folder is over 32GB in size and it contains text, photos, presentations, benchmark results and pretty much everything associated with every review I’ve put together. Although this folder is very important, the truth is that the bulk of that 32GB is never really accessed all that frequently. I went to duplicate the folder and discovered that almost none of it resided on the SSD. The same was true for my 38GB Documents folder, the bulk of which, again, went unread.
Applications on the other hand were almost always on the SSD.
In general, Apple’s Fusion Drive appears to do a fairly good job of automating what I typically do manually: keeping my OS and applications on the SSD, and big media files on the HDD. About the only difference between how I manually organize my data and how Fusion Drive does it is I put my documents and AnandTech folder on my SSD by default. I don’t do this just for performance, but more for reliability. My HDD is more likely to die than my SSD.
Facebook
Twitter
RSS
127 Comments
View All Comments
Richard Fairbanks - Saturday, January 19, 2013 - link
Thanks, Anand, for yet another timely article!I do almost all my work in code (i.e. text) with few graphics. I want to ensure reliability in case of disk failure.
Thus I am considering getting a 2012 Mac mini, opening it up, and adding a 256GB Samsung 840 Pro, in addition to the default 1TB HDD. (The 256GB capacity would allow me a 25+% spare area.) This is my ideal configuration for many reasons.
If I partition the HDD to match the 256GB SSD (leaving ~750MB for random, non-critical data), is it possible to create a RAID 1 array between the SSD and the 256GB HDD partition? (Full backups are made daily.)
In theory, this would allow all the array reads to come from the SSD for fastest response, and still maintain a mirrored HDD that could be booted from should the SSD fail. (If only the HDD partition could be a ZEVO ZFS format! ;-) )
Thoughts? Thanks!!
NCM - Saturday, January 19, 2013 - link
Richard asks: "If I partition the HDD to match the 256GB SSD (leaving ~750MB for random, non-critical data), is it possible to create a RAID 1 array between the SSD and the 256GB HDD partition?"That's an interesting question. I think the problem would be that there is no "master" disk in a RAID 1 array. Each slice is treated equally. You're hoping that read/write activity would be first served by the faster SSD, with the HD slice catching up in the background on its own time. I don't know that there's any evidence it would work like that, or, putting it another way, that anyone has written a RAID controller to make it happen that way.
It would be interesting to try it out.
We have some Mac Pro towers that I've set up SSD boot/application drives, but we rely on conventional Time Machine backups to an internal HD rather than a RAID mirror.
name99 - Saturday, January 19, 2013 - link
It is possible to create a RAID 1 in the way you are thinking using AppleRAID.What you want to do is simple enough that you can do it in DIsk Utility using the GUI.
If you really insist on going hardcore, hit Terminal and look at diskutil.
And you can boot off such an AppleRAID system.
HOWEVER I suspect you will be very unhappy with the results. A system like that can deliver snappy reads (because they'll mostly come from the SSD) but writes will be gated by the HD, and the system will frequently feel an HD system.
It is ALSO possible that you won't even get the read speeds you imagine.
When I used AppleRAID in this way (mirroring two HDs) a few years ago, it seemed to me that reads were also slower, and my assumption was that the system, assuming you cared primarily about data correctness (that's why you were mirroring rather than striping), performed both reads and compared the results before passing them up to the file system. Which suggests that your reads will ALSO be gated by the HD performance.
I'm also not sure what problem you believe you are solving with this. SSD failures are simply not that common. You can protect against them using Time Machine. If you REALLY are scared, you can have Time Machine alternate between two (or more) different backup drives.
It seems like a huge amount of pain to solve a problem that barely exists and that can be protected against much better in other ways.
name99 - Saturday, January 19, 2013 - link
To add to what I said, the AppleRAID mirroring stuff DOES work in terms of reliability, in that if one disk dies, you can just pop it out, replace it, and have the other disk copy to it. But, as I said, you pay a substantial hit in performance for this privilege.cjb110 - Saturday, January 19, 2013 - link
Gaming would have been an interesting 'use' case for the Fusion. When your playing you obviously want the fast access of SSD, but unless its your favourite game, it might not get used much and moved to the HDD.Also Games being much larger 'applications' would quickly fill the SSD if the Fusion just had a simple 'If App = On SSD" rule.
klaudyuxxx - Saturday, January 19, 2013 - link
They reinvented the wheel. 128 GB flash + 1-3TB HDD fused into a single volume?! AKA HYBRID SAMSUNG HARD DRIVESNCM - Saturday, January 19, 2013 - link
You really haven't bothered to read the article, have you? Or perhaps it's a reading comprehension issue.nerd1 - Saturday, January 19, 2013 - link
Typical apple - charging $$$$ for non-tech-savy people.It's way better to have a proper SSD (most laptops and desktops now have mSATA port) in terms of both performance and cost. Yes, I know that swapping the HDD of any apple device kills the warranty and most apple customers don't know how to upgrade a single component.....
Andhaka - Monday, January 21, 2013 - link
Nope, swapping the HDD with a SSD does not kill the warranty and many Apple users do that (I have done it on a 4 years old Macbook).But if other people find it better to pay for the Fusion solution (and a good solutions it seems to be) good for them.
Cheers
pichemanu - Saturday, January 19, 2013 - link
Hi Anand,i saw that in order to test a "pure ssd" setup you connected a 830 ssd to the imac over USB 3. As far as i know the best transfer rate over USB 3 is around 250 MB/s and the worst is well... terrible.
Considering the best case scenario for the iMac:
-USB 3 connected SSD would do 250 MB/s
-SATA 3 connected SSD would do 322 MB/s (taken from your article)
The performance would be 6.94 for fusion drive and 10.19 for a "pure SSD". This is an increase from 114% advantage for the "pure SSD" to 147% advantage for the "pure SSD".
If on the other hand your USB connected SSD did not write at max and a SATA 3 connected SSD would (that is 350 for the samsung 830 on an intel Z77 SATA 3 port) that difference would skyrocket.
Did you check that on your particular workload the USB 3 connection was not a bottleneck?
Thank you.