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
EnzoFX - Saturday, January 19, 2013 - link
Yes, exactly. This is the point of computers. It always bothers me when self-proclaimed experts come on tech sites dismissing anything of the sort. I can imagine them saying " Well just do RAID, or just manage the files yourself" and then stating that such a solution as this as unnecessary, when they clearly don't understand the point. They only work to slow such efforts down.name99 - Saturday, January 19, 2013 - link
If your friend has a mac, and if they can borrow enough temporary storage (to copy and hold the files while you make the change over), what I would recommend is that they stripe their 3 HDs together as a single volume. This can be done easily enough using the Disk Utility GUI.(Honestly they should have enough temporary storage anyway, in the form of Time Machine backup).
This will give a single volume (less moving around from one place to another) with 3x the bandwidth (as long as each hard drive is connected to a distinct USB or FW port).
[If the drives are of different sizes, and you don't want to waste the extra space, it is still possible to use them this way, but you will need to use the command line. Assume you have two drives, one of 300GB, one of 400GB --- the extension to more drives is obvious.
You partition the 400GB drive as a 300GB and 100GB partition.
You then
(a) create a striped RAID from the 300GB drive and the 300GB partition
(b) convert the 100GB partition to a (single-drive) concatenated RAID volume [this step is not obviously necessary but is key]
(c) create a concatenated volume from the volume created in (a) and that created in (b).
This will give you 600GB of striped storage, plus 100GB at the end of slower non-striped storage. Can't complain.]
Not a perfect solution, but a substantial improvement on the situation right now.
I don't know the state of the art for SW RAID built into Windows so I can't comment on that.
guidryp - Friday, January 18, 2013 - link
Really this seems like a solution for the lazy or technically naive.Manually managing your SSD/HD resources allows you to speed up based exactly on your own priorities, instead of having some software guessing and making a bunch of unnecessary copies to/from the SSD/HD.
You get faster performance of pure SSD where you want it. Less hiccups from background reorganization, and less unnecessary stressing of the SSD.
Also it isn't exactly difficult to manage manually. Use the SSD for your main OS/Application drive and whatever else you deem important for speed up.
zlandar - Friday, January 18, 2013 - link
"Really this seems like a solution for the lazy or technically naive."If everyone was technologically literate spam wouldn't exist and computer companies wouldn't need customer service for stupid questions.
jeffkibuule - Friday, January 18, 2013 - link
Aren't a lot of solutions built for the technologically naive?NCM - Friday, January 18, 2013 - link
Apple's principal market, especially for the iMac, is to home and small business users. Once again dragging out the familiar, but still applicable, automotive metaphor, I'll point out that most people don't want to work on their cars. They just want to drive reliably to wherever they're going. That's the need that Apple's FD addresses, and it seems to do so rather well.Sure, the price adder is a bit higher than one might hope, but probably not so much that it'll frighten away prospective buyers.
Interestingly though, it lost our sale. I was ready to order another iMac with a 256GB SSD and a 1TB HD for the office. We keep most of the files on the server, but a 128GB SSD application/boot drive is a bit tight. However a 256GB SSD is just right, allowing plenty of free space to maintain SSD performance. The additional 1TB HD is then repurposed for local Time machine backup.
But that's not an option for the new iMac, which offers only HD or FD. And I'm not about to make a risky and warranty busting expedition into its innards in order to roll my own SSD solution (although my own MacBook Pro has a self-installed 512GB SSD).
Instead I ordered up a 256GB SSD Mac mini, plus what turned out to be a very nice 24" 16:10 IPS monitor from HP. Although I would have preferred the all-in-one iMac solution for a cleaner installation without gratuitously trailing cables, the Mac mini with SSD, i7 and 8GB RAM options is fast and effective.
ThreeDee912 - Friday, January 18, 2013 - link
Wasn't this the kind of thing said about virtual memory in the 60's and 70's? Some people back then thought manually managing the location of everything in memory would make things more efficient, until some guys at IBM (or was it Bell Labs?) showed you saved heck of a lot more time letting the machine do it instead of trying to move things around yourself.This Fusion Drive really does reminds me of virtual memory. RAM and HDD mapped in a way so it appears as a single type of memory. Most stuff gets placed into RAM first, some stuff spills over onto the HDD, and stuff gets copied back and forth depending on how frequently it's used. The fast RAM is first priority, but there's the HDD as kind of a backup.
It's a bit different from a caching setup, where the computer has to "guess" a bit more about what should really be on the SSD. It's like the HDD is priority here, while the SSD is secondary.
And just like with virtual memory, none of this would matter if you had a huge amount of RAM or a very large SSD.
web2dot0 - Saturday, January 19, 2013 - link
Great comment ThreeDee9. Someone with a rational mind.To all those "experts" who claim that it's better to manage it yourself, you can also write every program in ASM. It'll be fast and small, but I'll be done with the project in 1/10 the time. The point is .... the product is not meant to provide "absolutely the best possible configuration". It's meant to be best all around solution.
If you guys still don't get it. Well, I guess all these years in the education didn't really help you because logical people think rationally.
psyq321 - Monday, January 21, 2013 - link
Hmm... is it just me who finds it slightly disturbing that we are comparing memory management (and, in some posts later, C vs. assembly coding) with the decision on how to organize documents/files?I would say that the intellectual investment is not really to compare.
Which does not mean that I have anything against SSD caching solutions - on the contrary, I see nothing wrong with ability to transparently manage the optimal location for the content.
TrackSmart - Friday, January 18, 2013 - link
A month ago, I would have said the same thing, but see my other post to understand why more people need this than you think. The proportion of people who can handle manually segregating their files is much, much smaller than most of us realize. I have three systems setup with both an SSD and a HDD and have no troubles. But we are a tiny, tiny minority of users.