Find by % savings, by brand, by category:
Macs, 4K Television, Printers, SONY, Nikon, Canon, Olympus, ZEISS, ALL DEALS...
Fusion Volume Speed (OWC PCIe SSD + HDD)
For all these tests, Apple’s Spotlight was disabled on the test volume.
After setting up the 480GB PCIe SSD + 2TB hard drive fusion volume, I tested the speed using DiskTester by creating 1000 files of 256MB each (256GB total), using the disktester create-files command.
Since the PCIe SSD is 480GB, these files should all fit onto the PCIe SSD, and should all see full SSD speed when written. Indeed, the performance is at 672 MB/sec = FAST.
It turns out that a special procedure is needed to actually make a Fusion volume, not just something that looks like a Fusion volume.
So what follows LOOKED exactly like a Fusion drive, but was not actually doing more than running in JBOD mode.
Tested on a Mac Pro 6-core 3.33 GHz, internal bays.
Clearly the Fusion technology is smart enough to send all the writes to the PCIe SSD when SSD space allows, and to keep the files there.
But is the “Fusion” file migration/optimization working? Or just JBOD hitting the SSD first? Keep reading.
llcMule:~ lloyd$ disktester create-files -n 1000 -f 256M fused DiskTester 2.2b1 64-bit, diglloydTools 2.2b1, 2012-02-10 14:40 Copyright 2006-2012 DIGLLOYD INC. All Rights Reserved Use of this software requires a license. See http://macperformanceguide.com/Software-License.html Mac OS X 10.8.2, 12 CPU cores, 24576MB memory Wednesday, October 31, 2012 1:56:21 PM Pacific Daylight Time disktester create-files -n 1000 -f 256M fused Volume: fused Num files: 1000 File size: 256MB Transfer size: 8192KB Fill with: "0x0000000000000000" Verify: true Creating 1000 files of size 256MB on volume "fused" Speed shown includes file system create/open/allocate/write-- real world time. TARGET FOLDER: "/Volumes/fused/disktester-blobs" Elapsed File# Qty 2sec 5sec 15sec 1min 2min 5min 15min 30min 60min 2s:15s 1m:5m ClockAvg 5s 13 3.30GB 674 675 675 675 675 675 675 675 675 1.00 1.00 676 10s 26 6.57GB 674 671 674 674 674 674 674 674 674 1.00 1.00 672 15s 39 9.85GB 672 671 672 672 672 672 672 672 672 1.00 1.00 671 20s 52 13.1GB 683 676 671 673 673 673 673 673 673 1.02 1.00 672 25s 65 16.4GB 654 670 672 672 672 672 672 672 672 0.97 1.00 672 30s 79 19.8GB 687 686 678 674 674 674 674 674 674 1.01 1.00 674 35s 92 23.1GB 678 676 677 674 674 674 674 674 674 1.00 1.00 674 40s 105 26.4GB 674 670 677 674 674 674 674 674 674 1.00 1.00 674 45s 118 29.6GB 661 671 673 674 674 674 674 674 674 0.98 1.00 674 50s 131 32.9GB 679 676 673 674 674 674 674 674 674 1.01 1.00 673 55s 144 36.2GB 677 674 672 674 674 674 674 674 674 1.01 1.00 674 ...
Going beyond the 480GB capacity of the SSD
What happens when more than 480GB is written to the Fusion volume (480GB SSD + 2TB hard drive)?
When more stuff is stored than fits onto the SSD, the speed drops because the SSD has reached its capacity; Apple’s Fusion technology is not a caching solution.
At idle time, the Apple Fusion technology actively moves frequently accessed files to the SSD, and migrates infrequently accessed files back to the hard drive. Even portions of files (another consideration for recovery from a drive failure = a mess, be sure to have backups!).
Adding more files
After writing the first 256GB of files, DiskTester was used again to write an additional 256GB of files (total of 512GB). Since a 480GB SSD is being used, the 512GB overflows its capacity, and one can then hear the hard drive kick into use as DiskTester creates those files.
Once the SSD fills up under the unrelenting disk I/O of disktester create-files, the system is forced to write to the hard drive. Without idle time to migrate files, the reads are impacted the same way (create-files writes all the files, then reads them back). The graph below captures this behavior.
Adaptation to activity
After 256GB + 256GB were written to the Fusion drive, another 25.6GB were written in addition. Since the system had no time to adapt as yet, these additional 25.6GB of files ran at hard drive speed both when written and when read back.
Following this, determining whether the system adapts to frequently used files was simulated as follows:
- disktester read-files was used to read the 25.6GB of files, three times.
- The system was given some idle time to migrate files as it saw fit.
- I went for a nice bike ride, leaving the machine idle for ~2 hours (Energy Saver was set to not sleep for 3 hours).
- disktester read-files was used to read the 25.6GB of files.
And... no migration. Access to the 25.6GB of files is slow as mud, meaning hard drive speed. No migration was apparently done for that three hours. It’s just running at hard drives speeds.
disktester read-files --iterations 10 /Volumes/fused/test-folder
Reading that 25.6GB of data ten (10) times and giving the system idle time to migrate— no deal— no I/O (according to iostat) and no speedup reading the files— hard drive speeds only. So either I’m doing something wrong here, or the Fusion implementation code has some restrictions that make it inoperable in this scenario (e.g. sees that the Accelsior PCIe SSD is an “external drive”).
Also tested with a 200GB SATA SSD (internal to Mac Pro), the Fusion migration of files DOES NOT WORK (no files migrate to the SSD). Repeated (10 times) reads of 18GB of files shows that once the SSD overflows to the hard drive, the files stay there and performance stays at HDD speed (basic JBOD behavior).
The algorithm seems to be:
Keep 4GB SSD space free, push down items to the hard drive to maintain that 4GB.