New Wine in Old Wineskins

An Apple Fusion Drive in a pair of Glyph Firewire enclosures

When I left off from selling commercial disk drive systems back in 1991, disk space was about $11,000 per gigabyte and the highest transfer rate offered was 17 megabytes per second. The next decade of computer storage progress was absolutely stunning. Disk drive technology simultaneously became smaller, faster, cheaper and more reliable. These better disk drives were the wineskins for the new intoxicating multimedia technology, and the worldwide embrace was unprecedented.

Some of the then-new wineskins that were used by the digital media geek community during the late 1990’s were made by MOTU (Mark of the Unicorn) and Glyph, a high-end disk drive system integrator. By 2002, the two companies were doing some co-marketing and came up with a 1U Firewire enclosure that held two hard drives. You could specify it with the 40GB, 80GB or the unbelievable 120GB hard drive installed. The 40GB model had an MSRP of $899; only $22 per gigabyte, and you could have it delivered in a shopping bag rather than a truck with hydraulic lift gate.

http://motu.com/other/press/NAMM2002/glyph.html

Imagine the look that you’d give me today if I asked $900 for 40GB. Today, 40GB is that leftover PATA laptop drive in the kitchen junk drawer that you haven’t bothered to throw in the landfill. I happen to own two of those old MOTU/Glyph wineskins, and I don’t know why. I can’t remember anything about how I acquired them, but I’m very sure that they were already used, and were missing parts. I do remember calling Glyph to buy the internal mounting brackets for the hard drives. Having those things helped me to get going. So, what’s the new wine?

The new wine is the Apple Fusion Drive. Fusion Drive is an Apple OS X implementation of a smart drive hierarchy created by logically combining an SSD with a standard spinning drive. It sounds quite a lot like a hybrid SSHD drive that typically is offered with 8GB of flash NVRAM combined with a 1000GB or so spinning drive. Enterprise versions of SSHD’s have 32GB of flash NVRAM and somewhat smaller spinning components. These self-caching drives are moving data to the cache based on reading activity, and the hit rate in the cache is kept high by qualifying files based on frequency of use. The SSHD cache does not add storage capacity to the spinning component.

Unfortunately, large media files immediately expose the spinning mechanics because they’re not frequently accessed, and they’re too large to all be permanently co-resident in the cache. On a side note, the spinning element of a Fusion Drive cannot be an SSHD hybrid drive. I tried, and lost hours just dying on the ‘unmount’ problems and false error messages in the Terminal application.

The Fusion Drive combines the total capacity of the SSD+HDD, and actively manages the promotion of data from the HDD to the SSD as usage patterns demand, on a file block basis. That distinction is important because you don’t always use all of a given file’s content, and the total space of what you bought is all there for your benefit.

My intended usage is for my video editing projects. First came the testing on the 250GB Crucial BX100 combined with a Seagate 1TB drive, and that proved successful. The full implementation is that same 250GB SSD along with three 1.5TB Seagate ST31500341AS drives (at about $0.03 per gigabyte) that have the CC1H firmware. Earlier firmware versions had terrible symptoms in a RAID array.

I had hoped that I could justify attaching a RAID-0 pair of 360GB Corsair SSD’s to pump up the Fusion throughput, but a 5th member port powered up inside the Mac Pro while the external wineskins are powered down sounds like a recipe for software trouble. Another option to use only four ports would be a 2+2 configuration; a pair of SSD’s and a pair of HDD’s. The downside of a 2+2 is that the non-SSD traffic could expose a fall-off in throughput that is otherwise so marvelously balanced in the 1+3 configuration. I opted to stay with the 1 SSD plus 3 HDD plan.

My completed configuration is 250GB of SSD plus 4500GB of HDD. Its name in my system is Video4700. The largest Fusion Drive combo ever offered by Apple was a 128GB SSD with a 3000GB HDD. In October 2015, Apple reduced the capacity of its native Fusion Drive offerings. The former 128GB SSD portion is now a mere 24GB, even though the underlying HDD stays at 1TB. Given the studies of desktop users utilizing SSHD’s it’s not surprising that a small cache can still be effective. However, in the beastly world of video editing and photo management, having lots of space and gobs of speed is always appreciated.

The critiques of Fusion Drive implementations that I’ve read have been notably emotional, and barely have enough data to help me understand the underlying problems that caused the complaints. Invariably, the writers of these critiques campaign for manual control of file placement. Apparently, they have lots of time on their hands…time that they’re spending by doing manual file management. I’ve not gotten enough insight into their workflow or requirements to make a judgement of my own. I suspect it’s a matter of anticipation.

The anticipation problem is that they expect the OS X operating system to predict with files are going to need promotion. The operating system knows when the SSD is full, and knows what the current file segment requests are. However, it can’t instantly rebalance the position of data between the SSD and the HDD, so when the dour users see the slowdown to HDD speed on the first one or two requests to the previously unreferenced files, they say, “Bah, humbug!” I’ve seen the same anticipation problem with the learning caches as implemented in SSHD hybrid products.

My RAID implementation of the three Seagate drives should nullify the annoying anticipation problem with its 360 megabytes per second throughput for the HDD portion of the Fusion Drive. That's plenty enough speed to preclude any slowdown issues. Overall, the low latency of the SSD is enhanced by the high throughput of the RAID set. As the reading data rate of the HDD is evenly matched to the writing speed of the SSD, data promotion by the operating system should be seamless.

However, as we know, nothing in computing is without compromise. In this case, the high throughput of the RAID HDD's is achieved at the expense of tripling the statistical probability that the RAID-0 array will fail. Since it's logically blended with the solid state drive, there's no point in building it as RAID-5 (a parity drive for recoverability) since OS X will freak out when I try to use the NewerTech RAID SAS card utility to rebuild the array.

My old MOTU/Glyph wineskins have been also been modified; the original firewire controller and the fan have been removed, and some power splitters with Molex-to-SATA adapters have been added. An external data cable called an SFF-8088 extends from the NewerTech MaxPower RAID 8-lane PCIe card that's living in a 16-lane slot. It's not elegant, (a bit Mad Max, actually) but it works perfectly. Operationally, I must overtly select whether the external enclosures are allowed to power up because my Bootcamp Windows-7 cannot understand a Fusion Drive.

Performance benchmarks using the BlackMagic video tool work out as you'd expect, and is shown in the top picture at left. The Fusion Drive exposes only the SSD performance of 500 megabytes/sec reading, and 360 megabytes/sec writing. A full test of a configuration similar to mine was done at the barefeats.com website.

http://barefeats.com/hard158.html

Terminal Commands to make a Fusion Drive

/dev/disk7 is the SSD in my system

/dev/disk8 is the HDD in my system

lvgUUID is a long string of characters created by OS X with the Logical Volume Group Name

diskutil list

diskutil coreStorage create LVGname /dev/disk7 /dev/disk8

diskutil coreStorage createVolume lvgUUID jhfs+ FusionName 100%

Terminal Commands to undo a Fusion Drive

diskutil coreStorage list

diskutil coreStorage delete lvgUUID

diskutil coreStorage revert XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX