I understand it's possible to "build" a fusion drive using an SSD and HDD with a few simple terminal commands. I was wondering if anyone has tried this yet with the stock nMP and a 3 or 4 terabyte external hard drive connected via thunderbolt. If so, please comment with your read/write speeds. If not, would this even be possible?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
nMP DIY Fusion Drive???
- Thread starter tanker5
- Start date
- Sort by reaction score
the question to ask
What happens to the fused drive if the external drive is unplugged (either T-Bolt or power)?
If the system simply hangs until the external is reconnected, and then resumes without any corruption - then it may be worth pursuing.
If the drives become "unfused", then you've lost your data.
What happens to the fused drive if the external drive is unplugged (either T-Bolt or power)?
If the system simply hangs until the external is reconnected, and then resumes without any corruption - then it may be worth pursuing.
If the drives become "unfused", then you've lost your data.
absolutely not worth the risk. Buy a bigger SSD if you need more space, but there is no way I would make my internal drive's reliability depend upon an externally connected peripheral!
Same thing that happens if any drive fails while running the OS from it; kernel panic.
When starting up with the external drive missing the OS simply won't recognise the volume, though any other partitions on the internal drive (Recovery HD, Bootcamp) will remain available, though switching on the external drive should cause it to appear either right away or after a restart.
The drives won't become detached from each other unless you manage to corrupt the core storage data somehow, the worst thing that can happen is that a write won't complete properly due to the interruption, however that may not happen as most writes go to the SSD first, and are later moved to the HDD (copy to HDD then delete from SSD). So either the write to the SSD will get interrupted and you won't have that data (but nothing should be overwritten thanks to journalling), or the move between disks gets interrupted and doesn't finish, in which case it just carries on where it left off when you restart with both disks available.
When it comes to moving the HDD part out the only added risk is a data connection issue (cable comes unplugged) or a power supply issue (usually the same basic problem). If you're careful though then these issues are easily avoided. For example, I typically bunch all "permanent" cables coming out of a device together, which greatly reduces the risk of accidentally unplugging something. With the Mac Pro you probably want a hub for hot-plugging USB or you'll use the end of a daisy chain for hot-plugging Thunderbolt devices, as this will usually be more convenient than fiddling around with the back of the machine, same as a Mac Mini for example.
The only concern really is that many Thunderbolt devices, in spite of a premium price, use power bricks which aren't always the most reliable of devices (I've had loads fail on me over the years), and those that do have internal power tend to use relatively cheap power supplies. So it's something to research if you can.
But yeah, there's no reason you can't do it, I've tried it with a Mac Mini and would do it with a Mac Pro, as I just hate trying to work with files separated between an SSD and HDD/RAID; a Fusion Drive is far more convenient. Aside from the fact that you can prevent accidental disconnects from happening there's not really that much more risk involved, and the potential for loss is no greater than if an internal drive failed.
Not impossible, but also not likely for the writes in active progress. All writes in a CoreStorage Fusion set up only go to one drive; the SSD. Since the SSD is internal, it isn't very likely at all that the write to the SSD cannot complete when an external cord is unplugged.
Certainly CoreStorage should throw some kind of serious 'panic' and the OS shutdown. But only very sloppy coding by Apple would endanger the data write that was in flight at the time.
You may have lost unflushed data blocks from the file system cache but frankly there are numerous sources that can trigger an OS panic that puts those at risk. This particular panic vector is only incrementally marginally another addition to that pile.
It isn't a recommended configuration. Most folks don't really pay attention to how much unflushed file system cache data they are floating at any one time.
It is the other way around that is far more risky. An internal HDD and and an external SSD. There it isn't going to possible to shutdown in a graceful state unless the CoreStorage does some very significant "tap dancing" to write first where it normally doesn't. (a kind of emergency recovery log. )
Generally, it is far better to be consistent and not particularly dive into the nuances of the split location differences and just wave off these as a rule of thumb. But if hard pressed and fit the special circumstances it is a risk can take on.
----------
at 3-4 TB of more space it is also not worth the cost of a bigger SSD. For those prices of SSD can buy an TB enclosure with more than two drive bays and simply put both another SSD and HDD in the enclosure. "Split connector" problem solved.
Frankly, safer too with the OS (and being able to gracefully shut down from exceptional kernel events ) decoupled from any logical volume hiccup.
The core OS, essential apps, user basics ( .login/.cshrc , simple preferences0 , and RAM equivalent capacity ( 32GB RAM --> 32GB storage) worth of space is fine. The rest can be put somewhere else. Piling everything into one huge pile isn't a good idea once the pile gets abnormally large.
The internal drive's reliability doesn't change in any way shape or form.
The data is on a split logical volume.
So you are saying that if the external spinning drive fails (fails, not comes unplugged, but fails), then all of the data could somehow be re-built? It's not a raid, it's a spanned logical volume. Would the machine even boot with the second drive disconnected?
Well… there would be a big _risk_ of corruption. I think it would be _possible_ to build the Fusion software so that no corruption will happen, but it might not be high on Apple's list to do that. In the configurations that Apple sells, both devices plus the CPU would lose power at almost the same time, and I'd hope that works without corruption.
Especially since Fusion does things on its own (say you copied 2 GB to your drive, it's all in the 4 GB write buffer, and Fusion starts copying those 2 GB where they belong. Or Fusion moves data from HD to SSD or vice versa. Power loss in the middle of this should definitely not cause any damage).
The inflight data was never on the HDD. There is no "re-build" necessary because it was never part of the initial write process.
When Fusion is moving data from one to another it a logged process so that the copy isn't erased until the new write is confirmed finished. They wuold have to do that even if the drives are hooked together on same power and SATA controller ( SSD and HDDs aren't going to shut down the same either on power loss which has nothing to do with an split inside/out SATA connection. .)
The unflushed file system buffers are toast. But they are toast under a variety of other failures too. This isn't a new mode.
From a write perspective it is not spanning at all. From a read perspective it doesn't matter the data on the drives is persistant. (barring some whacked failure with the drives internal caches... again not a new failure mode. )
----------
Probably not with Apple's minimalistic blade SSDs. Suddenly pulling the power from a SSD greatly increasing the risk that its metadata wouldn't get flushed to persistent memory. All the more so with the kinds of controllers that Apple uses that have DRAM caches.
Typically better resistant SSDs have several capacitors to provide back-up power. I doubt there is room for these on the SSD. Maybe Apple stashed them on the motherboard near the connector's power supply pins, but I doubt it. I doubt they put much time or thought into it. In a large enough number of cases it will happen it work.... just like with most desktop usage of SSDs.
Even if pull the power from a HDD and SSD at the same time the amount of data that both have to write to shutdown in a coherent state is different.
but once it gets written....then what?
So, for example, program x is located on the ssd for fast loading, but has files located on the hdd....hdd fails, program x is now corrupted? Or will it keep all files associated with each program on the same physical disk?
I still don't trust it. Sounds like a problem waiting to happen. I'd rather treat them as separate volumes, and backup for redundancy...
So, for example, program x is located on the ssd for fast loading, but has files located on the hdd....hdd fails, program x is now corrupted? Or will it keep all files associated with each program on the same physical disk?
I still don't trust it. Sounds like a problem waiting to happen. I'd rather treat them as separate volumes, and backup for redundancy...
If the plug is pulled the longer term implications are immaterial. Internal/external ... none of them work if pull plugs. The root issue is whether can drop into a coherent state or not. that's it.
Even the unflushed logs are partially mitigated by the logged file system.
Technically that file isn't but the volume it resides on is fundalmentally broken. A cable coming out isn't a failure. The drive and mechanism are fine if simply plug them back in.
No. Individual file blocks can be split over two drives.
If want to slower, "safer" disk access fine. But "trust".... the same fundamental infrastructure provisions FileVault2 .
Last edited:
I think what deconstruct60 was saying that having the HDD disconnect shouldn't necessarily interrupt any data being written at the time. Though that's far from certain as well; the way Core Storage works is that it keeps at least 4gb of free space on the SSD for writing data into, but if that fills up then it has to write out to the HDD, so it's still possible the write could be interrupted, plus a system disk is rarely completely idle so having the HDD disconnect will almost certainly cause a kernel panic straight away.
Fusion Drives have zero redundancy unless you use a suitable RAID array in place of a single HDD, but even then a failure in the SSD leaves you scuppered anyway. Failure may not be quite as bad as for a RAID-0, since data may still be recoverable from the remaining disk (if any software can handle Core Storage volumes at least), but a Time Machine backup drive is pretty much mandatory if you want disaster recovery.
But in that respect you're still no different whether the HDD is internal or external; an internal drive can fail too. The only difference that an external device has some more possible issues such as power supply failure, or cable disconnect. The last one should be easily avoidable though, so you don't have a huge amount of extra risk.
I think there may be some confusion that I'm saying that the SSD 'half' of the Fusion Drive keeps running in some extended disconnected mode. I am not. However, there is all reasonable likely (presuming Apple's coders are minimally competent ) to shutdown in a coherent state (from a CoreStorage and down perspective ) if still have access to SSD.
This "spill data to HDD" is a non problem. That spill process would go something like
a. read block from SSD
b. write block to HDD
c. update metadata for that logical block ( on SSD )
e. 'discard'/'assign free' block on SSD
Even if get a interrupt at step b. the data is still on the SSD. It is still marked in the metadata as being located on the SSD. So if that write is lost, there is no coherence lost what so ever. Most of the writing is being made to the SSD and the data is incrementally, temporarily redundantly stored.
If "ejecting" non-dirty blocks from the SSD it is even bigger non issue because step b is a no-op if CoreStorage already left a copy on the HDD. Likewise similar issue if in middle of pulling data off the HDD (just don't update the metadata mapping until after have temporarily redundant copy).
CoreStorage still has time to write out whatever metadata updates that haven't been written to disk and clean up before throwing the panic. There is no good reason at all to just blindly scream panic and not clean up at all if still have access to the SSD. If going to have a 4GB 'write cache zone' it isn't hard to keep the "free" threshold large enough to take an emergency dump of the dirty metadata if need be.
The file system cache is toast but if apps/users didn't persist the data before, that is the gamble they took. There are several fail paths that also expose that risk... it isn't new.
Last edited: