Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I asked this question on the Apple web site and didn't get any answers from anyone. One guy gave some decent opinions, but no real answers, so I'm posting it here.

One of our systems is a 2009 MacBook Pro, 13". We started getting a lot of spinning beach balls and I/O errors on it, so we used Scannerz (http://scsc-online.com/Scannerz.html) to check it. The drive failed. Bad sectors spanning a 5 GB range on the drive. We're tossing the drive..as far as I'm concerned, it's dead.

  A local computer store has some Sandisk SSD for dirt cheap (about $55.00 for a 65GB model.) 65GB isn't going to cut it space wise, but I started thinking maybe we could create our own Fusion drive. I found this article telling how to use disk utlity in ML to create (at the very least) a volume group:  

http://reviews.cnet.com/8301-13727_7-57550128-263/how-to-make-a-custom-corestorage-drive-in-os-x/    

Here are some of my questions:  

  1. Are there any statistics available on the web that accurately report on SSD reliability? I know they're fast but a lot of people seem to have problems with them "disappearing" for no known reason. Some even seem to suffer more block corruption than real HDs. I know this is still an "emerging technology" but I'm not in the mood to be a guinea pig for SSD makers!

  2. Does the linked article above actually create a Fusion drive, or just a volume group? It isn't clear whether a true Fusion drive is a volume group AND control software that maps data between the HD and SSD, or whether just being a volume group does it.

  3. How does a Fusion compare to a stand-alone SSD performance wise?   We're figuring the 65GB SSD along with a 320 GB HD would make a good combo ... fairly low price, high performance, hopefully.

I'd really appreciate the opinions of anyone that's tried this. I would have thought the SSD would have been like a super high speed cache, but this isn't the case. Volume groups are nothing new (at least to anyone that knows anything about Unix systems) but is the set up described in the CNET article REALLY a Fusion drive? Apple seems to be keeping the technology behind it somewhat of a secret.  

Thanks.

share|improve this question
    
"How good are SSDs, really? I know they're fast but a lot of people seem to have problems with them "disappearing" for no known reason." – that's not really a good question as it's opinion-based and only relevant to the point in time it was asked. Your third question is not a question as well, so please consider rewriting. –  slhck Sep 10 '13 at 10:04
    
How do you accurately report on reliability? I've heard of entire drives failing, normally due to h/w or s/w issues rather than the flash itself. There's some old-ish data here. Who is suffering SSD block corruption - do you have a link for that? Here's how Fusion compares to an SSD and an HDD. Not surprisingly, it's in the middle. –  sblair Sep 11 '13 at 23:49
add comment

4 Answers

In answer to your questions:

  1. No. SSDs are a growing and rapidly changing market. Every manufacturer seems to have different tactics for handing error correction, garbage collection, etc. etc. I suspect about the time someone were to try and collect data on a model, the model's probably already obsolete. Manufacturers, I'm sure have that data, and I suspect they're not about to share it with anyone.

  2. Once again, I don't think anyone knows for sure (yet.) Volumes created by spanning multiple volumes or drives is nothing new. It's been going on in Unix for probably 20+ years. Whether creating a Core Storage unit means "Yes, you really are creating a true Fusion drive" is something only Apple knows for sure.

  3. I created a Core Storage drive and I'm using it as I write. I like to play with hardware, probably because I'm crazy. I ran tests on the SSD alone, the drive alone, and then the CoreStorage unit. The Core Storage unit outperforms a standard SSD, but it doesn't even remotely approach a standalone SSD. I would guess it's likely comparable to some RAID variants, with the best comparison being RAID 0.

I actually did some tests on the core storage unit using programs I wrote and Scannerz. Scannerz was one of the first products on the market to support Core Storage, but they do it in what (initially) appears to be an odd way. A Core Storage unit will be presented by Scannerz in 3 units: 1 for the SSD, 1 for the HD, and 1 for the entire combined volume. They recommend testing the SSD and HD separately. I presume this is because, theoretically, the HD is most likely prone to failure, but the entire volume is presented, I assume, for someone that just wants to verify there aren't any problems. It seems archaic, but it's actually not a bad idea.

When you run a scan on a Core Storage assembly using Scannerz it's blatantly obvious that a Core Storage unit isn't interjecting some elements from the hard drive into the areas of the SSD. By this I mean there's no really sophisticated, tricky, or potentially confusing interjection or remapping of blocks or sectors, it's all straight forward. When you start a scan, Scannerz will literally haul through the SSD just like it would any other SSD, and when you get to the drive limits of the SSD and hit the HD, it slows down to what seems like a crawl (compared to the SSD).

When we created our Core Storage unit we used the Phoenix tool that comes with the Scannerz to clone the original IDE to a FireWire drive, and then once the Core Storage unit was created, we used Phoenix to clone the FireWire drive to the Core Storage unit. What was interesting was that by looking at the drive space readout on Phoenix (not the progress bars which are apparently task based) you could see some of them fly at very fast rates and others work slowly. For example, to my surprise, the Applications directory transferred at HD speeds, but virtually any of the OS directories, such as /System, /Library, /lib, /usr, /var etc. etc (i.e. the core OS) appeared to transfer at SSD speeds. To me this implies that Core Storage appears to be allocating or at least initially managing what goes where, and it appears to be doing this based on core OS components. What it does later on in life, I can only guess.

Using my own programs I essentially verified that the logical volume is laid out as I described. Read/write tests in the "early" region of the unit were at SSD speeds, once past the SSD they were at HD speeds.

What's my overall opinion? To be honest, I'm not that impressed. A standalone SSD is much faster. A standalone HD is slower, but not that much slower. If I had to compare it to another drive configuration, I'd likely compare it to a RAID 0 unit. Unfortunately, the way the Core Storage volume is configured you have to rely very heavily on backups just like you would with RAID 0. For example, if the SSD or the HD goes bad on either a RAID 0 or a Core Storage setup and you have no backups, to the best of my knowledge, you're hosed.

An interesting test would be to test the overall throughput and cost of Core Storage against RAID units. With RAID you could get tons of space and speed, and the speed wouldn't be erratic, which it can be on a Core Storage unit. Of course, you need a high speed interface to accommodate the RAID unit.

One of the things I'm considering doing is going back to an SSD standalone unit, but with symbolic links to larger data areas on an external drive. This way I could transfer files that are critical to the SSD as needed if I need to go portable without the external drive and still get true SSD speed. This of course, is a PIA, which is one of the shortcomings of the prices associated with SSDS.

I hope this write up is of value to you or someone else. Thanks.

share|improve this answer
add comment

The Fusion Drive doesn't sound to me like the worlds greatest idea. I actually like the virtual volume concept where many drives can be "assembled" into one volume, but if Apple has put "management" software on top of that's constantly redirecting file operations from one drive to another, that may work OK with SSDs but it would be a performance disaster on regular HDs.

The fact is, a real Fusion Drive is proprietary, and I don't think Apple is going to tell you what they're doing or how it works so you can build yourself a discount version. Take a look at the following comment:

When we created our Core Storage unit we used the Phoenix tool that comes with the Scannerz to clone the original IDE to a FireWire drive, and then once the Core Storage unit was created, we used Phoenix to clone the FireWire drive to the Core Storage unit. What was interesting was that by looking at the drive space readout on Phoenix (not the progress bars which are apparently task based) you could see some of them fly at very fast rates and others work slowly. For example, to my surprise, the Applications directory transferred at HD speeds, but virtually any of the OS directories, such as /System, /Library, /lib, /usr, /var etc. etc (i.e. the core OS) appeared to transfer at SSD speeds. To me this implies that Core Storage appears to be allocating or at least initially managing what goes where, and it appears to be doing this based on core OS components. What it does later on in life, I can only guess.

What that implies is that after a Core Storage unit is created, it appears to be "managing" which files go where (SSD or HD). Ok. Does this same thing occur if instead of being an SSD the first or primary disk in the set is a regular HD? If it is, it would imply Core Storage pays no attention to media type and simply favors the primary or "fast" drive. This is OK for SSDs, but it would be disaster for a volume made with only HDs. The HDs would be swapping contents from one drive to another just to maintain a status hierarchy defined by Core Storage and in this case, actually causing system delays, not performance increases. It would also absolutely make the idea of virtual volumes made by combining only HDs almost useless performance wise. This actually poses even more questions than answers.

The moral of the story is that you don't know what's really going on with a true Fusion drive vs. a "home brew" Fusion made using Core Storage. What we know for a fact is that a true Fusion drive uses Core Storage technology, but that doesn't mean that's all it uses. The CNET article implies that if you make a Core Storage unit for yourself, you've made a Fusion drive.

...I'm not really certain that statement is true.

share|improve this answer
add comment

As an FYI I created a fusion drive setup using the procedures you linked and as far as I'm concerned, it works great. It boots in about 20 seconds. Once logged in everything is up and running in about 10-15 seconds. If I do the same on an HD it takes up to 75 seconds to boot up, and an additional minute to reload everything after I log in.

As an FYI, I tried a standalone SSD and it made the my Fusion setup look slow, but the Fusion is still fast. I keep backups of the whole setup because I too have seen reports about SSDs being a bit on the flakey side.

Tons of storage plus very high speed. I can't complain. Whether this is technically a bonafide equivalent of a true Fusion drive from Apple, I can't tell you, but it seems to live up to what a true Fusion drive is supposed to do.

share|improve this answer
add comment

I have built two different fusion drives on a Mac Pro using Mavericks. The first used a 120GB OWC Accelsior and a WDC WD2002FAEX-007BA0. It was wonderful for a day or two, then started crashing and producing weird errors.

I split the Fusion drive, and reinstalled Mavericks on the OWC drive. Months later, this single drive works fine.

I tried another Fusion with a 250GB Samsung HD103UJ and the same WD drive. It is stable, but produces fair read speeds of ~250 MB/s and pathetic write speeds of ~30MB/s using Blackmagic Disk Speed test/1GB into a user directory. No better into system cache directory. The comparable raw OWC speeds are 160/600MB/s.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.