Contribute
Register

Guide - Fusion Drive using tonymacx86 Tools & Chimera

My org.chameleion.Boot.plist didn't have a "<key>Kernel Flags</key>" line to edit. Do I just add the line in?
 
Current thinking is that adding the kernel-flags is unnecessary and actually causes issue with iMessage and other Apple applications. I left it out when I built last week, and everything worked without a hitch.
 
Striping Fusion Drives Together for a Hackintosh

I experimented with several ways to use my two SSDs and two HDDs together (happily, they were bought with someone else's money).

I tried using the Gigabyte Jmicron raid support for SSD HDD caching and was underwhelmed.
I tried striping the HDDs in the Jmicron and building a fusion drive with one of the SSDs. It worked but I had a leftover SSD.
Finally I used the SSDs and HDDs as simple disks and built two fusion drives, pairing one SSD with an HDD and the second SSD with the second HDD.

I then used the appleraid functionality of diskutil to stripe the two fusion drives together. I used a command like this (for this example, the two fusion drives ended up as disk8 and disk9).

diskutil appleraid create stripe BigFuz JHFS+ disk8 disk9

This will create a new disk (disk10 for example) with a volume called BigFuz on it.

This is a good time to refresh the boot blocks and the boot file and Extras folder on each of the 4 drives involved in the fusion sets. It is not necessary to do the same for the striped disk because it is invisible to the BIOS booter.

From this point you can install a fresh system on BigFuz or restore a Time Machine backup to it, as I did.

The advantage of doing this is to improve both read and write performance over other solutions.

A simple fusion drive reserves 4GB from the SSD for quick writing and will later move that data to the HDD. After you have written 4GB, it begins writing directly to the HDD component of the fusion drive at a much slower rate than the SSD.

When you stripe two fusion drives together, each reserves 4GB for writes, allowing you to write as much as 8GB before you begin writing (much more slowly) to the magnetic media of the HDD. As a bonus, it may write as much as twice as fast while it is doing it. In my case, those writes tend to be > 550MB/sec to the SSD and almost 300MB/sec when we finally begin writing to the HDD (after 8GB).

After the write is complete, the fusion drive will wait a moment, then begin copying the data out of the reserved write area to the HDD. The speed at which this occurs is limited so that this background task does not interfere with foreground activity. When the devices are striped, both drives do the write copy simultaneously and double the rate at which the reserved write area is freed, making it available for more SSD-speed writing, sooner.

Reads benefit in much the same way. Whether the data currently resides on SSH or HDD the access is striped across both devices and may be read at a rate approaching twice what it was for a single drive.

I have verified that it is behaving appropriately with iostat disk0 disk1 disk2 disk3 1 and I see fast writes, delayed copy back to the HDD, migration of popular blocks to the SSD and demotion of those that have not been much used.

It boots and Time Machine backups of the combined drives work without issue. Disk speed tests and real-world compiles of large projects inside a VM are very fast.

Give it a try if you can scratch up the hardware.

Of course, like the fusion drive itself, a striped pair of fusion drives adds no redundancy to the system while adding points of failure. A Time Machine or other backup is a very good thing.
 
I am having a problem if anyone has a solution i would appreciate it. got the Fusion up and running no problem BUT now i have no audio. dont even have the audio thing on the top bar. when i go to change the audio i get a greyed out speaker and it doesnt do anything.

would like to fix this annoying problem if possible hah.

Thanks =)
 
How did you get Audio working, before you tried Fusion Drive?
If you used the HDA dylib from Chimera you have to use the Chimera EFI Guide, to get audio working, or you just install HDAEnabler.kext from a previous Multibeast Version.

Good Luck
theandy
 
Striping Fusion Drives Together for a Hackintosh

I experimented with several ways to use my two SSDs and two HDDs together (happily, they were bought with someone else's money).

I tried using the Gigabyte Jmicron raid support for SSD HDD caching and was underwhelmed.
I tried striping the HDDs in the Jmicron and building a fusion drive with one of the SSDs. It worked but I had a leftover SSD.
Finally I used the SSDs and HDDs as simple disks and built two fusion drives, pairing one SSD with an HDD and the second SSD with the second HDD.

I then used the appleraid functionality of diskutil to stripe the two fusion drives together. I used a command like this (for this example, the two fusion drives ended up as disk8 and disk9).

diskutil appleraid create stripe BigFuz JHFS+ disk8 disk9

This will create a new disk (disk10 for example) with a volume called BigFuz on it.

This is a good time to refresh the boot blocks and the boot file and Extras folder on each of the 4 drives involved in the fusion sets. It is not necessary to do the same for the striped disk because it is invisible to the BIOS booter.

From this point you can install a fresh system on BigFuz or restore a Time Machine backup to it, as I did.

The advantage of doing this is to improve both read and write performance over other solutions.

A simple fusion drive reserves 4GB from the SSD for quick writing and will later move that data to the HDD. After you have written 4GB, it begins writing directly to the HDD component of the fusion drive at a much slower rate than the SSD.

When you stripe two fusion drives together, each reserves 4GB for writes, allowing you to write as much as 8GB before you begin writing (much more slowly) to the magnetic media of the HDD. As a bonus, it may write as much as twice as fast while it is doing it. In my case, those writes tend to be > 550MB/sec to the SSD and almost 300MB/sec when we finally begin writing to the HDD (after 8GB).

After the write is complete, the fusion drive will wait a moment, then begin copying the data out of the reserved write area to the HDD. The speed at which this occurs is limited so that this background task does not interfere with foreground activity. When the devices are striped, both drives do the write copy simultaneously and double the rate at which the reserved write area is freed, making it available for more SSD-speed writing, sooner.

Reads benefit in much the same way. Whether the data currently resides on SSH or HDD the access is striped across both devices and may be read at a rate approaching twice what it was for a single drive.

I have verified that it is behaving appropriately with iostat disk0 disk1 disk2 disk3 1 and I see fast writes, delayed copy back to the HDD, migration of popular blocks to the SSD and demotion of those that have not been much used.

It boots and Time Machine backups of the combined drives work without issue. Disk speed tests and real-world compiles of large projects inside a VM are very fast.

Give it a try if you can scratch up the hardware.

Of course, like the fusion drive itself, a striped pair of fusion drives adds no redundancy to the system while adding points of failure. A Time Machine or other backup is a very good thing.


I have pretty much copied what you have done. I have two 250GB SSD's and two 500GB HDD's which I made two fusion drives from following this guide and then striped them using the terminal command you have stated. Everything seems to be working fine. Except when using black magic speed tests, the results are sometimes very slow, and others very fast. I have monitored HDD activity and there are slow reads from the SSD's to the HDD's, so I know that fusion is working (in part anyway). My question is, how does the fusion drive decide which data is moved to the HDD's and which stays on the SSD's. Now this has an obvious answer, it keeps the most recent used data on the SSD's. However, say for instance, I have a lot of data which was all accessed the same amount of times, fusion drive will store as much as it can on the SSD's (besides the 4GB per SSD it leaves for new writes). So my question is, which data has priority? This is all leading somewhere so bear with me.

The point I'm coming to with this particular set up is that, say for instance I have a data block, half on one side of the striped raid and half on the other. Is there a chance that the fusion drive - being automated and most probable having random data moves from SSD to HDD or vice versa if the data is being used a lot - that one half of my data exists on one of the SSD's, and the other half exists on the HDD of the other fusion array? Is this at all possible? If there is any element of randomness into how the fusion drive "decides" which parts of all my "unused" data exists on the SSD's, data sets will end up being mixed over both the SSD and the HDD within the raid array.

Does yourself or anyone else have any knowledge or experience of this? Could this explain why black magic speed test results are sometimes very fast and others very slow?

Thanks.
 
For those interested in upgrading to Yosemite, quick heads up that the instructions here still work great. One thing I noticed is that it looks like the Yosemite upgrade process automagically added a Recovery partition to my hard drive where previously I had two Boot partitions. Anyone else seeing this behavior?
 
@swinte: Same behavior here. The Boot partition on the SSD is still there, but the Boot partition on the HD was deleted and a Recovery partition was added there instead.
So far I didn't see any problems with this, except that my scripts for updating Chimera on the Boot partitions didn't work anymore.
 
For those interested in upgrading to Yosemite, quick heads up that the instructions here still work great. One thing I noticed is that it looks like the Yosemite upgrade process automagically added a Recovery partition to my hard drive where previously I had two Boot partitions. Anyone else seeing this behavior?

Same here but everything works fine so far.
 
For those interested in upgrading to Yosemite, quick heads up that the instructions here still work great. One thing I noticed is that it looks like the Yosemite upgrade process automagically added a Recovery partition to my hard drive where previously I had two Boot partitions. Anyone else seeing this behavior?

I would be very interested in a quick quide on how to upgrade to Yosemite when having a Fusion Drive setup.
I did my installation more than a year ago and didn't take a lot of notes...
Can you list the steps you used?

Thanks!
 
Back
Top