Tech —

More on Fusion Drive: How it works, and how to roll your own

It's not Intel SRT, it's not file-based, and it works on OS X right now.

More on Fusion Drive: How it works, and how to roll your own

Two blog posts by Tumblr user Jollyjinx have shed some more light on the inner workings of Apple's Fusion Drive. Announced last week at Apple's event in San Jose, Fusion Drive marries a solid-state disk and a spinning hard disk drive together into a single volume, relying on the speed of the SSD to accelerate all writes and reads on the most often-used files and the size of the HDD to hold the much larger mass of less often-referenced files.

Based on Phil Schiller's remarks at the event, I speculated that Fusion Drive was a software-based, file-level automated tiering solution. A Fusion Drive-equipped Mac will come with a 128GB SSD and a much larger hard disk, from 1 to 3 terabytes. Floor reports from the event revealed that the two disks are visible as a single volume, with the total amount of space in the volume equal to the two drives' aggregated capacities. Schiller's comments indicated that Fusion Drive keeps track of what files and applications are being frequently read, physically moving (or "promoting," as it's commonly called in enterprise tiering solutions) those files and applications from the HDD to the faster SSD. At the same time, files and applications on the SSD which haven't been referenced in a while are moved back down ("demoted") to the HDD, to make room for more files to be promoted.

Many questions lingered, though, in the absence of any real technical info from Apple (and its Fusion Drive tech document provides very few hard details on the underlying functionality). Is Fusion Drive really a tiering technology, actually moving the data, or is it more of a caching solution? Does it rely on Intel's Smart Response Technology, which is available in Ivy Bridge chipsets like those in the new round of Fusion Drive-equipped Macs? Does it use the volume management features Apple introduced last year in Core Storage? Does it move whole files or just pieces of files? How does it keep track of what it's moving? Will it work on older Macs, or only newer Ivy Bridge Macs with Apple-provided SSDs?

BYO Fusion

Some of those questions are now answered. In the first of two blog posts, Jollyjinx sets out to build his own Fusion Drive using a 120GB OCZ Vertex 2 connected to his Mac's SATA bus and a USB-attached 750GB hard disk drive.

Core Storage, explained by Ars's John Siracusa in his OS X 10.7 Lion review, is used as the logical volume manager to tie the two physical devices together into a single volume group. Once the volume group is created, Jollyjinx creates a usable HFS+ volume inside of it. This is all accomplished using diskutil, the command line version of Disk Utility, since the graphical version doesn't yet support the necessary commands.

Surprisingly, no additional configuration was necessary for the volume to begin exhibiting Fusion Drive-like tendencies. Jollyjinx created 140GB of dummy files and directories on the volume using the dd command, and the system automatically placed about 120GB of those on the SSD before dropping the rest onto the HDD (easily observable by the drop in write speeds as dd's ouput was redirected from SSD to HDD). After the files were all in place, Jollyjinx then triggered a whole bunch of read activity on volume, using the dd input file flag to constrain the reads to the directories which had landed on the HDD.

By monitoring the throughput of both the HDD and SSD at the device level with iostat, it's possible to track what happens next. As soon as Jollyjinx stops the reads and the file system goes idle, the SSD lights up with write activity, sending about 14GB worth of writes from the HDD to the faster disk. After another hour of re-reading the same directories as before, they begin to show SSD read speeds instead of USB-attached HDD speeds.

Intel SRT does not handle writes this way—whether it's operating as write-back or write-through cache, SRT mirrors writes (immediately or within a short amount of time) down to the hard disk, which is not the observed behavior. Plus, as has been noted, SRT currently doesn't work with SSDs larger than 64GB. It is absolutely clear that Fusion Drive does not use SRT.

Based on these findings, Fusion Drive is indeed a base operating system feature, either contained within Core Storage or built into OS X 10.8.x (Jollyjinx notes at the bottom that he's using 10.8.2). It appears that Fusion Drive detects the SSD-ishness of a drive based on SMART info read across the SATA bus, though it's possible that Apple might be using Microsoft's SSD detection method and simply testing attached drives' throughput. If a Core Storage volume contains an HDD and an SSD, Fusion Drive appears to be automatically activated.

Block- or file-based?

Another question, though, is whether or not Fusion is "block" or file-based—that is, does it promote entire files, or merely promote the parts of files that are being referenced? The difference is important: if you have a 50GB Aperture library full of photos, for example, or a big multi-gigabyte virtual machine, will Fusion Drive promote the entire thing or just the parts of it that you're repeatedly reading?

Jollyjinx tackles this in his second post, again using dd to only read the first megabyte of several 100MB files located on the HDD side of his home-grown Fusion Drive. After giving Fusion Drive some idle time to work, telling dd to read the entirety of the 100MB files generates significant IO on both the SSD and the HDD—the first megabyte of each file is coming off the SSD, and the rest is coming off the HDD.

Clearly, Fusion Drive is operating at the "sub-file" level, which is good news. I had speculated that it was purely a file-based technology, which does have some advantages, but sub-file neatly works around the disadvantages that file-based tiering brings when working with very large files that exhibit high rates of change.

Also settled with this experiment is the question of timing. Fusion Drive behaves itself, waiting for uninterrupted idle time in order to do its tiering rather than stealing IOs away from the user while the system is active. It's not an instantaneous technology (nor should it be, since the user's reads and writes should always be prioritized over system housekeeping activities like this). There are still questions about the nature of the data movement—are the sub-file chunks promoted by being moved, or are they copied?—but the question is largely academic at this point, since even if the chunks' bits still exist on the HDD after being promoted to SSD, it's clear that their canonical location changes. This makes Fusion Drive fundamentally a tiering technology—not a cache.

We have many more questions about Fusion Drive, and we hope to get some answers soon. Our Fusion Drive-equipped Mac Mini has shipped and should be arriving within the next few days. We'll dive deep once it's here!

Channel Ars Technica