Apple Fusion Drive—wait, what? How does this work?

New feature sounds less like hybrid drive caching and more like auto-tiering.

We got a slide this morning, but does anyone understand the Apple Fusion Drive yet?

Apple's new iMac announcement today included an interesting bit of information on an upcoming technology Apple calls "Fusion Drive." According to Phil Schiller this morning, the technology takes a relatively small solid state disk and a relatively large spinning hard disk drive, then "fuses" them together into a single drive.

Speculation in the Ars forums started immediately, with most wondering if "Fusion Drive" works the same as current hybrid disk drives. Those incorporate some amount of NAND flash inside a traditional hard disk drive as an extended cache. Others speculated the Apple technology resembles something like Intel's Smart Response Technology, which uses a dedicated SSD (of up to 64GB in size) as a transparent cache for a larger hard disk drive.

Technical details are scarce, but based on Schiller's descriptions, the answer to both of those questions appears to be "no." Apple's Fusion Drive does not appear to function like an SSD-backed disk cache, but rather seems more like a file-level implementation of a feature that has existed for some time in big enterprise disk arrays: automatic tiering.

Most big disk arrays have different types of storage—some slow spinning disk, some faster spinning disk, and some solid state storage—and some have the ability to monitor what data is being accessed the most and can automatically move that data to a faster tier of disk as needed. These features typically operate at the block level, below the files, and can be done on large or small chunks of data, depending on what's hot and what's not. Auto-tiering also includes the ability to take data that is no longer in demand, or no longer "hot" and demote it down off of fast disk and onto slower stuff. In this way, a file that doesn't get accessed very often might be stored on slow SATA disks, but if a hundred people need to open it repeatedly over a short period of time, it will get pulled up and kept on SSD until it's not needed anymore.

Based on Schiller's explanation, Fusion Drive sounds similar. In a caching solution, like Intel's, files live on the hard disk drive and are temporarily mirrored to the SSD cache as needed. In an enterprise auto-tiering situation, and with Fusion Drive, the data is actually moved from one tier to another, rather than only being temporarily cached there.

Schiller noted that out of the box, a Fusion Drive-equipped Mac will have its core operating system components and preinstalled applications placed on the SSD side of the house, while documents and applications live on the slower spinning disk. As you open files and documents and install applications, the operating system makes note of what you're doing and how often you do it, and the things you use most often are promoted up onto the SSD. This is done transparently, and you see the SSD and hard drives as a single volume.

This 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. I say "files" because it's almost certain that the implementation here is file-level instead of block-level, since a single user doesn't need the granularity that a block-level tiering solution would provide—as users, we tend to care about files and applications. OS X needs only a method of keeping track of how many times and how often a file or application is used and then can automatically have that file slipped onto fast SSD or slow disk when it crosses an upper or lower threshold. The tracking might be implemented through Core Storage attributes or through an external on-disk database like Spotlight and document revisions.

Apple is currently mum, though with the announcement still less than a few hours old, we're sure more information will begin to trickle out shortly. It seems certain, though, that this is not a caching implementation like Intel's but rather actual movement of files between physical disks by the Core Storage volume manager.

Promoted Comments

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.

Second off, until I actually get one of these things in my hands I cannot tell you exactly what the behavior of it is, but it could be any number of the things people have supposed in this thread. If you disassemble the existing CoreStorage driver you will see a complete COW B+Tree implementation (based on the same paper <http://static.usenix.org/event/lsf07/tech/rodeh.pdf> as BtrFS). They use that in order to implement their LVM and do things like reshuffling around data on the disk between different representations. Additionally, it supports transactions and rollbacks. There are enough tools there to build all sorts of things from simple read caching to write through caching that is transactionally aware and would survive an SSD failure (only losing the data on the SSD that had not yet made it back to the HD at the time of the failure, but leaving the HD in a coherent state). Additionally it could extend the existing hotfile support to hint things to CoreStorage.

If I had to guess I would assume the current implementation is not super ambitious. While CoreStorage itself is quite complex and is clearly designed to support some impressive storage needs Apple has been quite deliberate and cautious about rolling out features based around it.

Anand says frequently-used files are moved to the SSD, and that there's a 4 GB write cache on the SSD as well.

Quote:

That 4GB write buffer is the only cache-like component to Apple's Fusion Drive. Everything else works as an OS directed pinning algorithm instead of an SSD cache. In other words, Mountain Lion will physically move frequently used files, data and entire applications to the 128GB of NAND Flash storage and move less frequently used items to the hard disk. The moves aren't committed until the copy is complete (meaning if you pull the plug on your machine while Fusion Drive is moving files around you shouldn't lose any data). After the copy is complete, the original is deleted and free space recovered.

233 Reader Comments

I imagine (hope?) that Apple spent a fair amount of time testing all this, but the optimization algorithm must be pretty hairy to accommodate all the edge-cases.

This is why, for my money, they're probably taking the simplest possible approach, which is to use what they already have: hotfiles and journaling.

The hotfiles system has long been used to move commonly-accessed files to the faster areas of a spinning disk. Therefore, the OS has the proven capability to identify files that need common access and move them around quietly and reliably. So, start with everything on the spinning disk. Mount the SSD as a hidden raw device. Patch hotfiles to treat the SSD as "the fastest part of the spinning disk." Boom. Done.

So what about Peter's concern than one disk failure kills both disks? With journaling, it's easy. Just keep a copy of the SSD's data on the spinning disk as well. Keeping things in sync is just a matter of committing journal intents to both disks — first to the SSD, then to the spinning platter. The journal is robust and synchronous, so you need not worry about things getting out of sync.

And what about Phil's claims that the OS and key apps are already Fused up? Again, super easy. Just ship .hotfiles-btree with those files listed already.

Apple may well prove me wrong, but like I say, my money's on hotfiles and journaling.

Whatever the case may me, let's hope that it doesn't turn into an excuse for Apple to create a situation where users can't swap out/upgrade drives with off the shelf SSD and/or SATA drives. Even if Apple is still using standard drives to implement this fusion technology I can't say I'd be surprised to find out that only drives with Apple's "special" firmware can be used. Please, please let's not go back to vendor-specific hardware components. I remember back when Compaq servers could only take Compaq-branded memory and drives, and of course they cost about 10x what equivalent commodity components did...

BREAKING NEWS: Apple does something that everyone else has been doing for years!

Not sure why the down votes. I'm sure this is just Apple finally implementing Intel's RST drivers into OSX. So what if they managed to talk Intel in letting them bump the cache size from the 64 GB max to 128 GB. Apple is already using Sandy / Ivy Bridge CPUs and corresponding chipsets. It's a trivial amount of work. Certainly nothing for which they should be commended or for which there should be an article write-up. Belongs near the footer of a summary of today's keynote at best.

Also, I can't help but wonder if they are using the word "Fusion" to try to ride on some of Wozniak's reputation at FusionIO.

Here's a thread from 18 months ago regarding OSX and IRST + SRT. Again, typifies Apple's commitment to embrace better hardware technologies fully only once it can be used for marketing.

I'm pretty much willing to call BS on the idea being passed around that this caching is filesystem based and not using Intel's block level technology. Filesystem level is actually slower and less efficient than frequently used block level mirroring. SANs can do tiering with little performance issue because a SAN box has a dedicated controller CPU and components. Why even do caching at the software level, wasting CPU and RAM resources, when the chipset will natively do the heavy lifting.

So a question for Lee or anyone else who knows how this works: What impact does tiered storage have upon write amplification, and does a 'consumer' implementation (a single SSD and a single HDD) differ much from an 'enterprise' solution (multiple drives of each configured in arrays)?

Tiered storage in the enterprise in something like an EMC SAN has a substantial speed benefit. Especially for VMs.

As for "does it differ" between consumer and enterprise, yes, the difference is redundancy. It's basically the same difference as between a SAN and a single disk in a PC. Big, big difference.

As others have said, it seems to be speculation anyway, because there's no solid word that this is actually a tiered system and not some kind of cache. Even if it was, I'd be curious if it improved performance over the more "normal" PC setup of having the OS on SSD and data on hard disk. I would guess not much, if any.

So what about Peter's concern than one disk failure kills both disks? With journaling, it's easy. Just keep a copy of the SSD's data on the spinning disk as well. Keeping things in sync is just a matter of committing journal intents to both disks — first to the SSD, then to the spinning platter.

In the scheme of things, setting aside 128GB out of the 1- or 3TB HDD seems like a good tradeoff for such transparent redundancy. (Some capacity is lost to swap and other overhead anyway, so it's not as if anyone can fill their boot disk to 99% anyway.) Also, if some of the files copied to the SSD aren't changed (ie. read-only) but later cool off, there's no need to write them back to the HDD - they're already there.

I wonder if anyone in the hands-on session today had the foresight to look at the total capacity of the Fusion Drive, to see whether it reports SSD+HDD, or just HDD.

Read again and chew on it for a bit before you jump the gun. I'm not talking about recovering data on a dead disk, but on the other disk left alive. On a RAID-0 setup if one of both disks die, the data on the other disk is not recoverable. In this setup that's not necesarily true. Sure, if the data you need is on the dead disk then you're screwed, but that's besides the point.

It isn't beside the point. It's the entire point, given that data will essentially reside on a random disk (and things like apps, which are actually multi-file packages, could be split across both).

But you originally said the whole volume is hosed. That's different than "you won't know which files are retrievable". But in the case of disk failure, you always don't know which files will be retrievable. So how much reliability have you really lost in this setup?

But you originally said the whole volume is hosed. That's different than "you won't know which files are retrievable". But in the case of disk failure, you always don't know which files will be retrievable. So how much reliability have you really lost in this setup?

I can answer that, it's actually very easy: Just compare to your most recent backup. What backup? Oh…

Will it work with older hardware?In my 13" MacBook Pro I currently have a fast SSD in my optical bay and an upgraded 1TB hard drive in the hard drive bay. I've sort of tried to roll my own Fusion Drive by moving things around as necessary.Any leads on whether the Fusion Drive technology can be applied to configurations without Apple's blessing? Phil Schiller mentioned that the logic was already built into OS X.

So what happens if one of the drives (SSD or HDD) fail - do I lose eveything or just the stuff on the failed drive? If it was block level I would expect to lose everything but now that Fusion Drive is (?) file level it might behave differently when one drive fails?

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.

Second off, until I actually get one of these things in my hands I cannot tell you exactly what the behavior of it is, but it could be any number of the things people have supposed in this thread. If you disassemble the existing CoreStorage driver you will see a complete COW B+Tree implementation (based on the same paper <http://static.usenix.org/event/lsf07/tech/rodeh.pdf> as BtrFS). They use that in order to implement their LVM and do things like reshuffling around data on the disk between different representations. Additionally, it supports transactions and rollbacks. There are enough tools there to build all sorts of things from simple read caching to write through caching that is transactionally aware and would survive an SSD failure (only losing the data on the SSD that had not yet made it back to the HD at the time of the failure, but leaving the HD in a coherent state). Additionally it could extend the existing hotfile support to hint things to CoreStorage.

If I had to guess I would assume the current implementation is not super ambitious. While CoreStorage itself is quite complex and is clearly designed to support some impressive storage needs Apple has been quite deliberate and cautious about rolling out features based around it.

Sure, for more casual users (who probably won't notice that much anyway), an automatic system might be better, but I would much rather have a choice of what goes on my SSD and what goes on my mechanical drive, rather than the OS doing what it thinks will benefit me most.

I used to agree with this, but often even power users don't actually know what should be placed on the SSD, or even if they do it's a large amount of hassle to do so.

Take gaming for example - I might want Dragon Age located on my SSD to minimise load times. However, not every file in the directory needs to be placed on the SSD, there are bound to be quite large sections which are used rarely and would simply be wasting precious SSD space.

Even if I knew what particular files would be best placed on the SSD, I'd have to make a symlink for each and every one I moved. This is a pain in the ass.

Currently us power users tend to just move entire folders and use symlinks, which minimises the workload but is extremely wasteful of SSD space. The OS is in a much better position to know which files are being used the most often.

BREAKING NEWS: Apple does something that everyone else has been doing for years!

Did you even read the article? Yes, enterprise disk arrays have been doing it for years; but Apple is implementing it on a desktop PC. Nobody in the Windows world is doing this.

Evil_Merlin wrote:

Um, Seagate has had these for years. Momentus XT's anyone?

That's a block level caching solution. Very different implementation wise from what Apple is doing here. Apple can be much more intelligent about it because its implementation has access to file system metadata.

At a conceptual level though it has parallels and while it is different, it's not like it's "night versus day" different either. And also the price point is really the kernel of info I'd be more interested in. You can say Windows PC's don't use it but, outside ultrabooks, you don't see stock models of PC's typically with SSD's and still retain their sub $800 price either. But, given it's an Apple, I really am bracing for well over $1k and wouldn't be too surprised if I was several hundred shy.

That's a block level caching solution. Very different implementation wise from what Apple is doing here. Apple can be much more intelligent about it because its implementation has access to file system metadata.

Uh, doing it block-level is more intelligent, not less, because it means you don't have to burn cache space on portions of files that are never normally read.

More intelligent means it requires additional CPU power and therefore slows down disk performance.

Unlike a typical modern server, an iMac doesn't have 24 CPU cores and a spare hundred gig of RAM to play with.

And, also unlike a typical server, the vast majority of consumer disk access will read or write an entire file at once. In fact, I wouldn't be surprised if Apple starts rejecting apps from the store unless they always read/write the entire file at once, because partial writes cause all kinds of headaches.

In some situations, block level control is better, in others file level is better.nFor modern OS X software what Apple has done is the most intelligent, because it achieves similar performance to block level tracking without having to track every block separately.

And they have 128GB of cache. That is enough to fit all of your "hot" data ten times over. No need to waste CPU time being efficient.

Anand says frequently-used files are moved to the SSD, and that there's a 4 GB write cache on the SSD as well.

Quote:

That 4GB write buffer is the only cache-like component to Apple's Fusion Drive. Everything else works as an OS directed pinning algorithm instead of an SSD cache. In other words, Mountain Lion will physically move frequently used files, data and entire applications to the 128GB of NAND Flash storage and move less frequently used items to the hard disk. The moves aren't committed until the copy is complete (meaning if you pull the plug on your machine while Fusion Drive is moving files around you shouldn't lose any data). After the copy is complete, the original is deleted and free space recovered.

Did *anyone* watch Phil Schiller explaining the basics of Fusion Drive? It only took a minute or two but left me reasonably enlightened as to how it works:

* Hard drive (1-3TB) + SSD (128GB at the moment) concatenated into one "disk", as seen by the user.* Comes with OSX and some pre-installed apps on the SSD part, other stuff on the HD.* Usage patterns then determine which files get promoted/demoted to/from the SSD.

Advantages that I can see:

* SSD-like access speeds for your favourite apps & data, without forking out for 256/512GB+ SSDs.* No user action required to implement this.* It appears that you get the combined HD + SSD capacity (1.128 to 3.128TB).

You now have two storage units to go wrong but in the event of a single failure, you should be left with *some* files rather than none. Anyone who has the slightest love for their data will be backed up with Time Machine and/or in the cloud, anyway. It wouldn't surprise me if the SSD was silently mirrored on the HD but flagged for overwriting should all the capacity be required, much in the way TM can overwrite your oldest backups when the volume is full.

It seems to me that Fusion Drive is there to boost performance, not reliability, as there are separate (and already implemented) solutions to that problem.

Wow - the Anandtech article says they really have taken the somewhat crazier route and have the OS literally move files from the HDD to SSD. It really doesn't seem the best option to me - block level decisions are much better as you can work on hotspots within files and the directory metadata itself, and a good write-back block cache mechanism will have a much higher SSD-hit rate than a file-level moving strategy.

Yes, this is something we haven't seen before, but like an amphibious Torana, it may not be for lack of innovation elsewhere...

Great! So now when either the SSD or the Hard Disk goes bad the system is hosed. I guess they are making sure you need an Apple backup solution for your new hardware.

Actually, it sounds pretty interesting. I look forward to Anandtech doing a detailed review of the technology Apple is using. If it is just repackaging of commercial technology there is no reason why others couldn't do the same thing. Hybrid drives are NOT the same, they are only similar and have much less flash memory.

Based on what I can find so far, Fusion Drive and SRT sound functionally equivalent in general. There are some technical fillips between the two, but for your average user both come down to "faster drives".

Fusion Drive gives you more storage (SSD+platters), SRT gives you only the platters for storage.

On the other hand when the SSD in Fusion fails you lose data, whereas with SRT you only lose performance.

I'd be curious to see how Fusion Drive deals with the SSD crapping out suddenly.

Personally, I think I'd rather stick with SRT. Or ReadyDrive, maybe, although I've never used it. I like SSDs, mine's been really nice for load times and such, but it's still a fragile technology; given that I don't have any redundancy for the SSD, I rather like the fact that the data is not solely on it.

Another thing to consider, when SRT decides to demote some file from cache it just deletes it on fast SSD, and that's it. If Fusion works as described in article, then to demote file from SSD, it must first copy it to slow HDD, and then delete if from SSD. And only advantage is irrelevant amount of disk space.

Also, should both SSD and HDD be almost full, then moving back and forth between them would seriously degrade.

Great! So now when either the SSD or the Hard Disk goes bad the system is hosed. I guess they are making sure you need an Apple backup solution for your new hardware.

Fortunately they provide one.

If you plug in a big USB hard drive it asks if you want to use it for backup, and if you say yes it will do that. Then whenever you plug it in, a few seconds later it starts backing up, and you can unplug any time (even mid-backup) and it will pause. If you haven't plugged it in for a while it will start harassing you, and if left plugged in it backs up every 60 minutes.

If your boot drive fails, the firmware on modern macs can connect to wifi/ethernet, download the install/recovery iso from apple, perform a clean install on your new hard drive (assuming your mac has a user replacable hard drive) and will prompt to restore from the backup.

bolomkxxviii wrote:

Actually, it sounds pretty interesting. I look forward to Anandtech doing a detailed review of the technology Apple is using. If it is just repackaging of commercial technology there is no reason why others couldn't do the same thing. Hybrid drives are NOT the same, they are only similar and have much less flash memory.

Apple mever repackages other people's technology. They always roll their own stuff or build on top of others. It looks like this is just two drives, a sata hdd and an ssd (probably soldered to the motherboard, since that is faster and smaller and good ssd's don't fail often). The rest is likely done in software.

Another thing to consider, when SRT decides to demote some file from cache it just deletes it on fast SSD, and that's it. If Fusion works as described in article, then to demote file from SSD, it must first copy it to slow HDD, and then delete if from SSD. And only advantage is irrelevant amount of disk space.

Copying from the SSD to the HDD takes, what, 30 milliseconds? Doesn't sound like a big deal to me.

I bet large files are never stored on the SSD, since SSD's performance/price trade off only really wins when you have lots of small/fragmented files.

Great! So now when either the SSD or the Hard Disk goes bad the system is hosed. I guess they are making sure you need an Apple backup solution for your new hardware.

Actually, it sounds pretty interesting. I look forward to Anandtech doing a detailed review of the technology Apple is using. If it is just repackaging of commercial technology there is no reason why others couldn't do the same thing. Hybrid drives are NOT the same, they are only similar and have much less flash memory.

Basically Fusiondrive is very close to the idea proposed in this thread somewhere around the second page (and not at all like my suggestion - too bad that my first Reader Fav post was 100% incorrect): An SSD partition is joined with an HDD partition with information abut which partition is faster sent to the OS. The OS will then keep track of frequently used files (it does already for the auto-defrag) and move them around on SSD and HDD as required. The only wrinkle is that there is also a 4GB ZIL-like write cache where everything that should go to the HDD is sent first.

I quite like the sound of this:"all write operations are first saved to the SSD. Then, of course, if the OS decides they belong better on the mechanical disk, that data will be moved at another time. But the benefit is that writes happen really fast because they're all going to the SSD."

Arguing over whether "block" level is better than "file" level is getting into a semantic minefield. No operating system today can do this stuff at the block level; the most granular thing an operating system can handle would be the file system cluster level, which may or may not equate to actual disk blocks. This differs from tiering technology in big fancy enterprise arrays, which often do operate below the file system instead of on top of it like Fusion Disk does (along with ReadyBoost et al).

Apple likely chose to do this with files because finer granularity would bring additional complexity without commensurate performance increases. Yes, it's certainly more efficient to only tier up the clusters that need it, but tracking your hot data in 4k chunks means a lot more tracking than doing it in variable per-file (or per-bundle, for applications) increments.

For big-ass file system objects, like an iPhoto or Aperture library, I'd like to know whether Fusion pitches the entire bundle up to SSD when it heats up, or if it's smart enough to move only the actual files inside the bundle.

Lots of questions to be answered, but the edges are coming into focus, and it's looking so far like my suppositions are right. We're trying like crazy to get a tech expert at Apple to speak on record to us, so stay tuned.

I don't believe this is tiering, and if it is tiering, it's monumentally stupid. Tiering is essentially forcing people to use RAID 0.

Tiering is much more fragile than caching. With tiering, if either disk dies, your entire volume is hosed. With caching, you only lose the volume when the spinning disk dies; the SSD can fail (and SSDs love to fail, often without warning) without any loss of functionality, only a reduction in performance.

That's not entirely true. This is much closer to JBOD than RAID-0. Furthermore, because it is file-based, I'd wager that a not too complex tool will exist to recover the files from the remaining drive since it is essentially there.

What?

If it moves files from spinning disk to SSD and then the SSD dies, there will be no recovering, and the file will not be "essentially there". It'll be gone.

If it copies files from spinning disk to SSD (and ensures that writes are propagated back to spinning disk from SSD) then it's not tiering, it's caching. But you will be able to recover your data, because it won't have been destroyed in the first place.

I was thinking it was caching, but I could be wrong. If it is caching, I still think it will be better than just a hybrid SSD since, like they said, the OS can manage it more intelligently picking and choosing what to put on the SSD. The hybrid drives don't know the filesystem so I think it's plain block caching. An article comparing a Fusion Drive against a hybrid drive would be great to set this all to rest!

If it is tiering then your data isn't anymore likely to be lost like some have suggested in this thread. With Raid0 you lose all your data if *either* drive fails. With tiering, like many have pointed, out, you only lose whatever data was on the drive that failed.

This situation, however, is no different than buying any computer currently with an SSD or HDD - if the drive fails you lose your data. Maybe I'm missing the point but I don't see the Fusion Drive adding any additional risk.

Arguing over whether "block" level is better than "file" level is getting into a semantic minefield. No operating system today can do this stuff at the block level; the most granular thing an operating system can handle would be the file system cluster level, which may or may not equate to actual disk blocks. This differs from tiering technology in big fancy enterprise arrays, which often do operate below the file system instead of on top of it like Fusion Disk does (along with ReadyBoost et al).

Assuming "block" means a specific size is really flawed. We know that block caching is better than file caching from all the research done in disk caching technologies - nothing use a file-based cache any more (and the ones that did were only very brief).

Apple likely chose to do this with files because finer granularity would bring additional complexity without commensurate performance increases. Yes, it's certainly more efficient to only tier up the clusters that need it, but tracking your hot data in 4k chunks means a lot more tracking than doing it in variable per-file (or per-bundle, for applications) increments.

I disagree. Working on a uniform size chunk tracking is at least as easy as a file-based system. You don't have to worry about anything but direct disk reads/writes and only have to effectively enhance your RAID-0 driver to either optimally fragment files, or work on an indirection list of where things are "really" stored.

Quote:

For big-ass file system objects, like an iPhoto or Aperture library, I'd like to know whether Fusion pitches the entire bundle up to SSD when it heats up, or if it's smart enough to move only the actual files inside the bundle.

I doubt the file-system driver knows anything about bundles. Isn't that a higher-level thing?

What's more interesting is the behaviour when the drives start to fill up and how it handles the replacement policy. I can imagine, if the "always writes to SSD" bit is true when combined with "performs transaction to transfer data" bit then you could get a good amount of pathological on a busy system that fills whatever spare SSD areas the OS keeps on hand and results in a constant stream of background moving of data. Seems like something that would actually end up quite bad at something like large video recordings?

You are usually *not* adding an additional disk to a consumer desktop to improve reliability. You add it to improve the storage size.

So, yes, if you got two disks instead of one, the chance of failure - for the whole system - doubles.

But I never heard someone mention that as a downside of adding a disk to a system; it's just an unavoidable consequence.

You prepare against that risk by maintaining a backup. Which, as you know, Apple made rather easy with the introduction of Time Machine.

So, Fusion Drive speeds up your system. The likelihood of failure doesn't change at all when you look at the whole system (i.e. it's a system failure when any one component dies). And to prevent data loss in case of a failure, you do what you'd do anyway and maintain a backup using Time Machine.

You are usually *not* adding an additional disk to a consumer desktop to improve reliability. You add it to improve the storage size.

So, yes, if you got two disks instead of one, the chance of failure - for the whole system - doubles.

But I never heard someone mention that as a downside of adding a disk to a system; it's just an unavoidable consequence. […]

I think what Peter is getting as is that adding a second drive, and then having one of the two drives fail generally does not mean that your entire system storage has failed.

For the sake of a simplified argument, assume that I buy two similar disks and store about half of my files on each one of them. When one of them fails I lose what was on that disk (assuming I was stupid enough to not back up). With a setup like the one in the new iMacs there is the distinct possibility that if one of the disks fail all my files will be lost, and like you say the risk of A or B failing is greater than the risk of only A failing.

Both situations will be remedied the same way, with a solid backup. Time Machine was introduced on October 26, 2007, almost exactly five years ago, Mac users have few to no excuses not to back up using that or some other tool like Carbon Copy Cloner.

I would not be surprised if there was some synergy there that hasn't been announced yet between Apple and Fusion-io. I hope they wouldn't try to ride on Wozniak, rather, a roll in of Fusion-io technology to help consumer SSD/Hybrid last longer. Fusion-io stock popped up in August... any one for a bet?

aaronb1138 wrote:

...Also, I can't help but wonder if they are using the word "Fusion" to try to ride on some of Wozniak's reputation at FusionIO....

I don't believe this is tiering, and if it is tiering, it's monumentally stupid. Tiering is essentially forcing people to use RAID 0.

Tiering is much more fragile than caching. With tiering, if either disk dies, your entire volume is hosed. With caching, you only lose the volume when the spinning disk dies; the SSD can fail (and SSDs love to fail, often without warning) without any loss of functionality, only a reduction in performance.

That's not entirely true. This is much closer to JBOD than RAID-0. Furthermore, because it is file-based, I'd wager that a not too complex tool will exist to recover the files from the remaining drive since it is essentially there.

What?

If it moves files from spinning disk to SSD and then the SSD dies, there will be no recovering, and the file will not be "essentially there". It'll be gone.

If it copies files from spinning disk to SSD (and ensures that writes are propagated back to spinning disk from SSD) then it's not tiering, it's caching. But you will be able to recover your data, because it won't have been destroyed in the first place.

I was thinking it was caching, but I could be wrong. If it is caching, I still think it will be better than just a hybrid SSD since, like they said, the OS can manage it more intelligently picking and choosing what to put on the SSD. The hybrid drives don't know the filesystem so I think it's plain block caching. An article comparing a Fusion Drive against a hybrid drive would be great to set this all to rest!

If it is tiering then your data isn't anymore likely to be lost like some have suggested in this thread. With Raid0 you lose all your data if *either* drive fails. With tiering, like many have pointed, out, you only lose whatever data was on the drive that failed.

This situation, however, is no different than buying any computer currently with an SSD or HDD - if the drive fails you lose your data. Maybe I'm missing the point but I don't see the Fusion Drive adding any additional risk.

The risk with tiering when the OS is faffing about with random files to the SSD and back is that an SSD failure would leave lots of things essentially broken due to parts of them being gone. I mean, you don't just "lose whatever was on the SSD", you also break everything that needed those files. The OS felt fit to move some random libs on there? Tough luck son. The fact that all this is controlled by the OS means that you have literally no control over it.

(And if it's not moving the files but copying them, it is caching. But since all the Apple fanboys want to claim that it's not caching (and therefore superior), let's stick with the tiering theory.)

You can call it tiering if you want but it's still caching. I doubt this is significantly (>25%)better than an SRT enabled system with a similar amount of cache which I know is not possible because of intel's limitation on SRT. Can't wait for benchmarks. Of course I've switched to all SSD anyway so none of this matters directly.

Quote:

"There are only two hard problems in Computer Science: cache invalidation and naming things."

Assuming "block" means a specific size is really flawed. We know that block caching is better than file caching from all the research done in disk caching technologies - nothing use a file-based cache any more (and the ones that did were only very brief).

Blocks *always* equal a specific size. For "advanced format" disks, that size is 4096 bytes. Prior to that, it was almost universally 512 bytes (though some enterprise disks, like EMC's, used 520-byte blocks and stored checksum information in the extra space). The problem is that you're saying "block" when you're not actually meaning "block."

I don't have Windows Internals in front of me, but I'm going to guess that ReadyBoost deals with file system clusters, or at the very most with the LBAs which correspond to clusters. That's the lowest thing the operating system can deal with. LBAs are not on-disk structures--they are not blocks. In an SSD, they don't even remotely correspond with the internal structure of the storage device.

Quote:

I disagree. Working on a uniform size chunk tracking is at least as easy as a file-based system. You don't have to worry about anything but direct disk reads/writes and only have to effectively enhance your RAID-0 driver to either optimally fragment files, or work on an indirection list of where things are "really" stored.

It depends entirely on the framework employed. In this example, if Apple is using hotfile tracking (which it's already got in place to handle its file system defragging), then it's already set up to move files around.

Also, the promotion/demotion isn't occurring in a vacuum. This isn't a big array with tens or hundreds of gigabytes of DRAM cache and spare IOPS lying around; tiering consumes IOPS that can't be used for servicing user requests. There's a balance to be struck between potentially doing lots and lots and lots of random tier up/tier down IO in 4k chunks is ultimately more difficult than doing fewer, larger promotions and demotions of whole files. Plus, moving entire files between storage devices helps locality of reference on reads and writes later--is it easier to read a file from a single device, or to read clusters from two separate devices with different read characteristics?

Look at how the solution would have to work in the environment it's going to be used in, not as an isolated theoretical implementation.

Quote:

For big-ass file system objects, like an iPhoto or Aperture library, I'd like to know whether Fusion pitches the entire bundle up to SSD when it heats up, or if it's smart enough to move only the actual files inside the bundle.

I doubt the file-system driver knows anything about bundles. Isn't that a higher-level thing?[/quote]Bundles == directories with a the bundle attribute set. It's an HFS+ thing.

Quote:

What's more interesting is the behaviour when the drives start to fill up and how it handles the replacement policy. I can imagine, if the "always writes to SSD" bit is true when combined with "performs transaction to transfer data" bit then you could get a good amount of pathological on a busy system that fills whatever spare SSD areas the OS keeps on hand and results in a constant stream of background moving of data. Seems like something that would actually end up quite bad at something like large video recordings?

Maybe, yeah--the edge case behavior would definitely be interesting to see. I'd guess the 4GB SSD landing area is inviolable and will always be used for that, but the solution they're implementing would have to have high "watermarks" built into it, such that if the SSD hits, say, 90% full--I'm making that number up, but let's say that's the high watermark--the demotion criteria are loosened and a bunch of stuff gets demoted.

Looking forward very much to getting my hands on an actual device with this in it so I can poke at it.

I take it you didn't read the 'subtitle', where it clearly states, "New feature sounds less like hybrid drive caching and more like auto-tiering."

The article doesn't confirm which, and it's possible that it may combine components of both. Though it does sound more like auto-tiering. Though, until someone actually gets to analyze the technology, no one will know.

I take it you didn't read the 'subtitle', where it clearly states, "New feature sounds less like hybrid drive caching and more like auto-tiering."

The article doesn't confirm which, and it's possible that it may combine components of both. Though it does sound more like auto-tiering. Though, until someone actually gets to analyze the technology, no one will know.

DUDE! Reading comprehension, please!

If you actually read the part I quoted I was talking about the wikipedia article, Fusion is more or less a tiered storage, the Windows technology that has existed for a while is a cache.

Lee Hutchinson / Lee is the Senior Reviews Editor at Ars and is responsible for the product news and reviews section. He also knows stuff about enterprise storage, security, and manned space flight. Lee is based in Houston, TX.