Fusion drive on older Macs? Yes(jollyjinx.tumblr.com)
jollyjinx.tumblr.com
Fusion drive on older Macs? Yes
http://jollyjinx.tumblr.com/post/34638496292/fusion-drive-on-older-macs-yes-since-apple-has
14 comments
The moment I saw the fusion drive I was hoping I'd be able to get one as an upgrade to my current mac-book pro (still using a hard drive). But one of the big selling points was the automatic switching of commonly used files to the ssd. I couldn't tell from this blog post if the author was able to recreate that functionality (I'm not very knowledgeable about filesystems), but without it, a fusion drive seems significantly less awesome.
Just having the OS on the ssd is still a big win, though.
edit -- Poor reading comprehension on my part. The new OS X does automatically move files to the ssd. Pretty awesome. Now other world computing needs to start selling them.
Just having the OS on the ssd is still a big win, though.
edit -- Poor reading comprehension on my part. The new OS X does automatically move files to the ssd. Pretty awesome. Now other world computing needs to start selling them.
Apple's fusion drive is not actually a single part; it's a combination of an mSATA SSD and a standard SATA HDD. The way fusion drive is implemented, both devices will need to show up with their own SATA interface for it to work.
Seagate does make single 'Hybrid Hard Drive' parts[1]: an HDD plus 8 or 16GB of flash to improve performance, but you won't see the performance gains that you would with a 128GB flash fusion setup. The flash cache is managed by the controller in those cases, so it's difficult to have apps or OS pinned there.
Alternatively, you can take out the DVD drive in your MBP and use an adaptor[2] to put in a SATA SSD. This would allow you to use Apple's fusion software. I've used this setup before, but its number one drawback is poor battery performance. Moving data lazily between HDD and SSD is fine in a desktop with continuous power, but could draw multiple watts of precious battery in a laptop. It turns out to be better to go full flash.
[1]http://www.seagate.com/internal-hard-drives/laptop-hard-driv...
[2]http://www.mcetech.com/optibay/ ($20 copycat on eBay works fine)
Seagate does make single 'Hybrid Hard Drive' parts[1]: an HDD plus 8 or 16GB of flash to improve performance, but you won't see the performance gains that you would with a 128GB flash fusion setup. The flash cache is managed by the controller in those cases, so it's difficult to have apps or OS pinned there.
Alternatively, you can take out the DVD drive in your MBP and use an adaptor[2] to put in a SATA SSD. This would allow you to use Apple's fusion software. I've used this setup before, but its number one drawback is poor battery performance. Moving data lazily between HDD and SSD is fine in a desktop with continuous power, but could draw multiple watts of precious battery in a laptop. It turns out to be better to go full flash.
[1]http://www.seagate.com/internal-hard-drives/laptop-hard-driv...
[2]http://www.mcetech.com/optibay/ ($20 copycat on eBay works fine)
You have to be extremely careful with compatibility with these Optical Bay adapters and SSDs. I work at an SSD company and these are the #1 cause of issues in the field for users. While we don't officially support them, we still make sure we have functionality - which often requires special firmware customizations that we would not be making otherwise. I would also not expect any other manufacturers even test these.
What I can recommend though, is to go with either a Sandforce-based drive, any Samsung drive, or a Vertex 4.
What I can recommend though, is to go with either a Sandforce-based drive, any Samsung drive, or a Vertex 4.
Why? I also have one of these optibay's, and it doesn't contain any active parts: It's just a piece of metal to make your drive fit in the place of the CD drive. Why does this cause issues on the SSD's?
The same reason why putting SSDs in external enclosures is extremely inconsistent - power. An SSD needs significantly more power at certain times, depending on the controller. Most of the time, an optical bay does not provide the necessary amperage.
I think your facts are a bit off. The "superdrive" in macbooks require significantly more power than a SSD. When you burn a dvd using the superdrive, it requires between 40-50W of power. Even the most power hungry SSDs during heavy sequential write mode use less than 5W of power. If anything, the optical drive bay needs to provide more power than the HDD side of things.
It's more likely that the ebay-knockoff adapters were poorly made than it having anything to do with power requirements.
It's more likely that the ebay-knockoff adapters were poorly made than it having anything to do with power requirements.
Oh, that is exactly what I meant - the Optical drive bays are all made very badly, and intended for HDDs. The motherboard/connection can certainly power any drive fine, but the replacement bay cannot.
I never had any issues with my OWC kit either. Seems odd that there'd be issues.
I bought one for $10 and it too works fine.
Just a quick aside: jollyjinx is the author of JollyFastVNC and ScreenRecycler (among other apps) and apparently knows his way around OS X at a fairly low-level (i.e. under the hood).
To be clear, the author hasn't been able to use a Fusion Drive on an older Mac. He has instead found a way to create something a lot like a fusion drive by combining a consumer SSD and HD, and getting the OS to treat the combination as a single volume. Most impressively, he also was able to use the SSD "first", moving recently used apps and files to this faster drive.
Fusion Drive is just a fancy name for CoreStorage joining two independent disks with specific parameters.
Those specific parameters can be replicated using CoreStorage to join two independent disks. How, then, is that not Fusion Drive?
Those specific parameters can be replicated using CoreStorage to join two independent disks. How, then, is that not Fusion Drive?
All the details aren't out yet, so we can't be certain what is or isn't Fusion Drive. However, the speculation is that Fusion drive is more than merely a union of two disks, but with an OS level automatic tiering. (http://arstechnica.com/information-technology/2012/10/apple-...)
> with an OS level automatic tiering.
Yes, exactly. And citing the source you provide, "This [OS level automatic tiering] is almost certainly done using Apple's Core Storage logical volume manager, introduced in OS X 10.7. As a volume manager, Core Storage has the chops to weld the two separate drives together into a single entity and handle the relocation of files between one tier and the other."
So, then, if you can show that you can merge two disks with CoreStorage, and get it to tier them such that recently used apps and files get moved over to the SSD... what more details do you need?
See also the promoted comment on that ARS page: "First off, I am 100% certain this is HFS+ sitting on top of CoreStorage based on comments made to me by by certain former coworkers who are still at Apple."
Yes, exactly. And citing the source you provide, "This [OS level automatic tiering] is almost certainly done using Apple's Core Storage logical volume manager, introduced in OS X 10.7. As a volume manager, Core Storage has the chops to weld the two separate drives together into a single entity and handle the relocation of files between one tier and the other."
So, then, if you can show that you can merge two disks with CoreStorage, and get it to tier them such that recently used apps and files get moved over to the SSD... what more details do you need?
See also the promoted comment on that ARS page: "First off, I am 100% certain this is HFS+ sitting on top of CoreStorage based on comments made to me by by certain former coworkers who are still at Apple."
So, it's basically Linux's LVM.
Isn't this Fusion Drive in all but name? What is the difference between this and Fusion Drive?
Speculation: Perhaps Fusion Drive also is filesystem aware, that way it keeps important system folders, such /Applications and /System and /Users/*/Library, always on the SSD. That way, your OS and apps seem fast, and bulk files such as MOVs and MP3s are on the hard disk.
I used to do this manually when large sized SSDs were past the expense of mere mortals.
I used to do this manually when large sized SSDs were past the expense of mere mortals.
Anyone know if this would also work with an older laptop where you replace the optical drive with a HDD and put an SSD in the hard disk bay? That could breathe some life into my aging late 2008 Macbook 13".
I did this today on a 2010 MBP with a 250gb optibay drive. Nuked everything, ran the terminal commands from the Mountain Lion on usb stick, then installed mountain Lion. Installed and works great. Fast.
Yes, see some of the other comments here mentioning the Optibay.
My old-school first-gen Unibody lasted me quite a while thanks to the MCE Optibay. I installed an SSD in place of the superdrive for the os/apps and a 320GB old school spinning drive for music/photos/etc...
That old Core 2 Duo felt faster than most modern computers purely because IO was so much faster.
My old-school first-gen Unibody lasted me quite a while thanks to the MCE Optibay. I installed an SSD in place of the superdrive for the os/apps and a 320GB old school spinning drive for music/photos/etc...
That old Core 2 Duo felt faster than most modern computers purely because IO was so much faster.
I remember ZFS had fancy things like readzillas, writezillas, logzillas... Sadly, I never had an excuse to play with those.
And since the author mentioned ZFS, it's not hard to make another computer pretend to be a Time Capsule or other Apple-approved way to use Time Machine for backups. For me, my TM backups are on a Linux box with a BtrFS volume.
And since the author mentioned ZFS, it's not hard to make another computer pretend to be a Time Capsule or other Apple-approved way to use Time Machine for backups. For me, my TM backups are on a Linux box with a BtrFS volume.
WARNING: Off-topic ZFS blathering just because I like spreading the gospel. ;-)
I don't think I've heard of writezillas.
Not sure the origin, but a Readzilla was just a (rebranding I guess?) STEC Mach8 100GB SSD used as a read-cache. In fact, the Readzilla name is rarely used anymore. The technical name if L2ARC, or Level-2-Adapative-Read-Cache (Level-1 being the system memory ZFS consumes for caching). In operation, this will almost always be used close to capacity as long as you have that much data in the disks behind it.
A Logzilla was a STEC Zeus IOPS (18GB). It operated as something similar to a RDBMS transaction log, aka the "ZFS Intent Log", or ZIL. This is a Write-Back-Cache. Even if you're only running HDDs the ZIL is still there to ensure consistency. If you have SSDs to spare, you have the option of moving the ZIL to those to increase write performance (up to the point you fill up the SSD anyways, which doesn't really happen in practice, though it's possible).
If you lose an L2ARC device, no worries, it's pure cache. Even if it's your only L2ARC device, the worst that's going to happen is things slow down because there's no SSD caching your data anymore. With that in mind, I usually deploy two SSDs for an L2ARC, in a striped configuration to increase IOPs. If I lose one, I still have another, just half the IOPs. If I lose both, well, back to just the performance of my disks, but all my data is safe.
If you lose your ZIL, you've lost your zpool (the whole logical storage array). This means you must MUST MUST always have at least two drives for your ZIL, and they should be mirrored so if there's a failure your data is still safe. Moving the ZIL off to SSD increases performance, and is absolutely something you should do, but similar to the Fusion Drive (though for entirely different reasons), the SSD isn't simply a performance booster, you're actually moving a critical part of your storage system to it. It needs to be protected.
More Trivias: Since the ZIL is part of the storage, this is why the Sun Storage clusters had the ZIL inside the JBODs and not on the 1U server heads. If you failed over from one head to another, you needed to make sure the ZIL went with the backing disks. The heads did contain the SSDs used for L2ARC OTOH since cache is cache, after failing over the new "array master" would just populate it's SSDs as data was read.
I don't think I've heard of writezillas.
Not sure the origin, but a Readzilla was just a (rebranding I guess?) STEC Mach8 100GB SSD used as a read-cache. In fact, the Readzilla name is rarely used anymore. The technical name if L2ARC, or Level-2-Adapative-Read-Cache (Level-1 being the system memory ZFS consumes for caching). In operation, this will almost always be used close to capacity as long as you have that much data in the disks behind it.
A Logzilla was a STEC Zeus IOPS (18GB). It operated as something similar to a RDBMS transaction log, aka the "ZFS Intent Log", or ZIL. This is a Write-Back-Cache. Even if you're only running HDDs the ZIL is still there to ensure consistency. If you have SSDs to spare, you have the option of moving the ZIL to those to increase write performance (up to the point you fill up the SSD anyways, which doesn't really happen in practice, though it's possible).
If you lose an L2ARC device, no worries, it's pure cache. Even if it's your only L2ARC device, the worst that's going to happen is things slow down because there's no SSD caching your data anymore. With that in mind, I usually deploy two SSDs for an L2ARC, in a striped configuration to increase IOPs. If I lose one, I still have another, just half the IOPs. If I lose both, well, back to just the performance of my disks, but all my data is safe.
If you lose your ZIL, you've lost your zpool (the whole logical storage array). This means you must MUST MUST always have at least two drives for your ZIL, and they should be mirrored so if there's a failure your data is still safe. Moving the ZIL off to SSD increases performance, and is absolutely something you should do, but similar to the Fusion Drive (though for entirely different reasons), the SSD isn't simply a performance booster, you're actually moving a critical part of your storage system to it. It needs to be protected.
More Trivias: Since the ZIL is part of the storage, this is why the Sun Storage clusters had the ZIL inside the JBODs and not on the 1U server heads. If you failed over from one head to another, you needed to make sure the ZIL went with the backing disks. The heads did contain the SSDs used for L2ARC OTOH since cache is cache, after failing over the new "array master" would just populate it's SSDs as data was read.
I use MicroMemory 1GB battery backed PCIe cards for my ZILs. They work quite well.
That seems like you're really living on the edge. :-)
My typical setup is:
2.5" 15K-RPM HDDs making up the storage array. Generally in 4 or 5 drive, single parity sets with a spare for every set up to 3 spares (more just seems silly). I build out the array with 2 to 4 sets generally. The more sets, the more capacity and performance while keeping your parity stripes a reasonable size and ensuring a single drive failure doesn't drastically degrade the performance of the whole array.
So with 300GB drives, that gives me (300GB * (5 - 1 (for parity))) * 2 == ~2.4TB usable. Then throw on a couple Crucial M4s or Samsung 830s (had very bad luck with most Sandforce equipment) as striped L2ARC, and another pair as mirrored ZIL.
Then use a caching RAID controller with a BBU in JBOD mode.
The reason you want 15K-RPM drives is that things like replication and volume creation/deletion bypass the ZIL and caches, so while most of the time you'll be able to push ~30K 8K blocks around in either direction sustained with ease, for the low level administrative things you'll be limited by your disk speed. Which in the 10 drive (including spares) 2.4TB example above means you'll have about 1200 IOPs worth of performance you can tap into. If you'd instead used a three-drive single-parity set with 2TB SATA drives, you'd be storing a lot more data on each drive, meaning failures would take much longer to recover from, not to mention the drives themselves would be about half the speed. On top of that, for the lower level operations you'd be limited to about 1/10th the IOPs. Which is not fun at all. Especially if you've made the mistake of attempting to use deduplication. :-(
This is last-generation stuff though. These HDDs offer less storage, and much less performance for about twice the price of a good 512GB SSD today. Any new arrays I build will forgo the L2ARC and ZIL, and go full SSD.
This way you can cut out the 4 SSDs used in the example, and instead of 10 drives, have 10 SSDs. Instead of around ~30K 8K IOPs, you'll have access to 120K. Instead of about 15K for writes, you'll have about the same 120K. And all your lower level administrative tasks will run at the same speed as everything else.
So you'll end up with about 4X the performance at less than half the price, and with ~40% more storage as well. So even if you need the array to have a 4 year life-span, you could replace all the SSDs every couple of years, and continue to expand the performance envelope with whatever the current generation offers, and still end up paying less. Not to mention drive bays aren't cheap. So the all-SSD option means a Dell R820 with 16-bays is now an option whereas before you'd need the 10 drive bays, 4 bays for SSD, and your mirrored boot devices... you'd be looking at buying a pretty pricey MD1220 in addition to the server and now you've given up another 2U as well.
For high-performance IT HDDs are all but dead. We've passed a price/GB/performance milestone where for 98% of use cases, HDDs should only be considered for archival storage, not operational storage. IMO.
My typical setup is:
2.5" 15K-RPM HDDs making up the storage array. Generally in 4 or 5 drive, single parity sets with a spare for every set up to 3 spares (more just seems silly). I build out the array with 2 to 4 sets generally. The more sets, the more capacity and performance while keeping your parity stripes a reasonable size and ensuring a single drive failure doesn't drastically degrade the performance of the whole array.
So with 300GB drives, that gives me (300GB * (5 - 1 (for parity))) * 2 == ~2.4TB usable. Then throw on a couple Crucial M4s or Samsung 830s (had very bad luck with most Sandforce equipment) as striped L2ARC, and another pair as mirrored ZIL.
Then use a caching RAID controller with a BBU in JBOD mode.
The reason you want 15K-RPM drives is that things like replication and volume creation/deletion bypass the ZIL and caches, so while most of the time you'll be able to push ~30K 8K blocks around in either direction sustained with ease, for the low level administrative things you'll be limited by your disk speed. Which in the 10 drive (including spares) 2.4TB example above means you'll have about 1200 IOPs worth of performance you can tap into. If you'd instead used a three-drive single-parity set with 2TB SATA drives, you'd be storing a lot more data on each drive, meaning failures would take much longer to recover from, not to mention the drives themselves would be about half the speed. On top of that, for the lower level operations you'd be limited to about 1/10th the IOPs. Which is not fun at all. Especially if you've made the mistake of attempting to use deduplication. :-(
This is last-generation stuff though. These HDDs offer less storage, and much less performance for about twice the price of a good 512GB SSD today. Any new arrays I build will forgo the L2ARC and ZIL, and go full SSD.
This way you can cut out the 4 SSDs used in the example, and instead of 10 drives, have 10 SSDs. Instead of around ~30K 8K IOPs, you'll have access to 120K. Instead of about 15K for writes, you'll have about the same 120K. And all your lower level administrative tasks will run at the same speed as everything else.
So you'll end up with about 4X the performance at less than half the price, and with ~40% more storage as well. So even if you need the array to have a 4 year life-span, you could replace all the SSDs every couple of years, and continue to expand the performance envelope with whatever the current generation offers, and still end up paying less. Not to mention drive bays aren't cheap. So the all-SSD option means a Dell R820 with 16-bays is now an option whereas before you'd need the 10 drive bays, 4 bays for SSD, and your mirrored boot devices... you'd be looking at buying a pretty pricey MD1220 in addition to the server and now you've given up another 2U as well.
For high-performance IT HDDs are all but dead. We've passed a price/GB/performance milestone where for 98% of use cases, HDDs should only be considered for archival storage, not operational storage. IMO.
Have a link for this product? Interested.
"Btrfs (B-tree file system, variously pronounced "Butter F S", "Butterfuss", "Better F S",[1] or "B-tree F S"[2]) is a GPL-licensed copy-on-write file system for Linux. Development began at Oracle Corporation in 2007. It is still in heavy development and marked as unstable. Especially when the filesystem becomes full, no-space conditions arise which might make it challenging to delete files" http://en.wikipedia.org/wiki/Btrfs
You are very brave. I don't dare to store my backups on a filesystem still marked unstable.
You are very brave. I don't dare to store my backups on a filesystem still marked unstable.
From https://btrfs.wiki.kernel.org/index.php/Main_Page
"every effort is being made to keep the filesystem stable and fast"
I trust those guys.
"every effort is being made to keep the filesystem stable and fast"
I trust those guys.
Is there a way to run a Mac on ZFS? (With a ZFS boot volume, too.)
http://code.google.com/p/maczfs/
Not boot volume though.
Not boot volume though.
A startup called Ten's complement has a commercial ZFS implementation for Mac(not boot yet) that's rather stable and full featured as well.
http://tenscomplement.com/
http://tenscomplement.com/
No longer available.
Ah, my mistake. Rather a pity too... they actually had a product that was usable. I suppose the biggest challenge for them was "who will buy this" given that it was targeted for people with large storage arrays attached to Macs. It's a bit of a niche; perhaps people in the media world would bite?
It just moved to http://zevo.getgreenbytes.com/ although I haven't tried downloading it from there.
If the author is reading, can he/she specify what model of Mac was used?
Update: He answered me on twitter: MacPro3,1
Update: He answered me on twitter: MacPro3,1
This really makes me want to try out putting DragonFlyBSD on some machine, as its swapcache[1] seems to be quite similar to that (and actually uses a proper FS).
1: http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache
1: http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache
Linux has several similar implementations, as does ZFS with the L2ARC.
Can someone explain how this is different than L2ARC with ZFS?
It's quite like like a combination L2ARC + ZIL. However, the L2ARC isn't persistent across reboots (otherwise block writes would need to be journalled, adding complexity) so you don't get the speed benefits until the machine's uptime gets large. Not the greatest thing for laptops. Also, I believe the L2ARC is populated from in-memory pages, while it appears the Fusion Drive can be populated by a daemon process.
I noticed he used a USB drive for this(!) I wonder what the failure tolerance is like. What happens if I forget to plug in my USB drive on boot?
That's just for demonstration purposes. You'd want to gat an optical bay cradle for a MacBook Pro to do this for real.
I was actually thinking about another usage: adding additional "permanent" storage to my 128 GB MBA via the SD card slot.
There's a Kickstarter project (Nifty Minidrives) that are selling miniSD card caddies that sit flush with the MBA SD card slot, so you can permanently leave an micro SD card mounted for some additional storage. In theory, being able to pool the storage with the (faster) boot drive would be great. In practice it'd probably be flaky and a bad idea (especially at current SD card capacities). But something worth thinking about for the future...
There's a Kickstarter project (Nifty Minidrives) that are selling miniSD card caddies that sit flush with the MBA SD card slot, so you can permanently leave an micro SD card mounted for some additional storage. In theory, being able to pool the storage with the (faster) boot drive would be great. In practice it'd probably be flaky and a bad idea (especially at current SD card capacities). But something worth thinking about for the future...
I gave up on bookmarks-as-bookmarks everywhere except my phone. I can keep the two hundred or so tabs I need open on modern computers, and that plus search engines and history suggestions takes care of me.
With late-loading tabs now standard in Firefox and Chrome, they're really close to bookmarks anyway.
With late-loading tabs now standard in Firefox and Chrome, they're really close to bookmarks anyway.
I have to say I'm rather skeptical - the author doesn't say anything about installing the special "late 2012" version of OSX 10.8.2[1] which supposedly contains the functionality. Moreover, as far as I can tell, he's just combined the two drives into a JBOD logical volume (with a total size of the combined drives). So the first 120GB of the volume sit on the SSD, the remainder ends up on the HDD. There's nothing dynamic about it. None of the "benchmarks" seem to disprove this at least, although it's hard to tell until we know how a "real" Fusion Drive behaves.
Make sure you also read the other blog posts in his blog. He _proves_ that those chained disks transfer popular files to the SSD when they're accessed more often after a while. He is even on it to show that this technology is file system agnostic and runs even with ZFS, he also found that its block based rather than file based: https://twitter.com/jollyjinx/statuses/263638394721161216
[deleted]
At the end of the post he shows that "tail" data was moved to the SSD after being read repeatedly, and he does mention 10.8.2
http://jollyjinx.tumblr.com/post/34694173142/more-on-byo-fus...
http://jollyjinx.tumblr.com/post/34700977027/fusion-drive-lo...