Digging Into Apple’s Fusion Drive Details
macobserver.com
macobserver.com
On a typical HHD, under typical circumstances, all writes go to the SSD, and are copied to the HDD later on. So far so good; Apple's solution will do the same thing. And stuff being read gets copied to the SSD in both cases. Also great.
Now, suppose a file is loaded to the SSD and we never write to it. Now the SSD gets full, and the file has to be moved off of the SSD to make room. On a typical HHD, all that happens is the file gets deleted from the SSD. It's still on the HDD, so no further action is necessary. But on Apple's Fusion Drive, this file will have to be copied back to the HDD.
Considering that some of the largest kinds of files (e.g. videos) are exactly the sort of thing you will want to put on the SSD and not modify, this seems like a pretty terrible idea.
That's an assumption we've yet to see confirmed, and I suspect is incorrect. I doubt every single file that's read will migrate to the SDD. Rather, I expect only files frequently read will migrate to the SDD. Effectively, the SDD will largely be a write cache (but likely only for files written atomically) and a read cache for frequently accessed files.
That behavior would largely sidestep your concerns.
(And, actually, files that are readily streamed, like videos, aren't necessarily files you'd want to store on the SDD. Those can often – though, yes, not always – be read quite quickly from the HDD. Unless you're dealing with truly huge files, or actively editing a video, you don't need SDD throughput.)
Hmm, I hadn't noticed that they're only doing this on desktops, so I was thinking there in terms of energy efficiency. On a laptop, you definitely want that video to get copied over to the SSD so that the HDD can spin down and stop draining your battery. On a desktop, I guess you wouldn't care as much.
I guess that in this marginal case, the Fusion Drive does behave rather like a cache and allow the blocks simply to be overwritten if the data on the HDD was not overwritten - as you say, it would be inefficient not to, if simpler. But if the Fusion Drive allows the data on the HDD to be overwritten before that, then the FS has spare capacity that a proper cache cannot use, since a cache cannot free up the space on the HDD.
The result is that the space available for data is close to the sum of the space available on both drives, something not true of cache.
Seriously? Aside from hybrid drives, Windows has had a very similar technology since Vista (SSD's weren't as inexpensive back then, so it wasn't terribly well received), and of course there is ZFS with it's L2ARC.
The whole "it's not a cache" thing is a canard. Doing it right means doing it much like swap: you may have dupes in certain cases. Going beyond that actually hurts performance.
It's fundamentally not a cache. If it were a cache, Fusion Drive would not increase the total storage space. Anandtech[1] seems to confirm this, noting that Fusion Drive creates a 4GB write buffer on the SSD and all read operations will influence a pinning algorithm which will move, not cache, frequently accessed files from the HDD onto the SSD.
ReadyBoost is exactly a cache, as is ZFS's ARC and L2ARC.
Now then, regarding the statement you question… yes, it is incorrect. ReadyBoost and L2ARC are pre-existing examples of "hybrid models of blending SSD and mechanical disks" that "integrate with the OS" and do so quite intelligently. You are correct to call out that statement. But it really does appear that Fusion Drive is not a cache, but a true unioning of SSDs and HDDs managed by the OS to ensure hot files are on the SSD whenever possible.
[1] http://www.anandtech.com/show/6406/understanding-apples-fusi...
http://en.wikipedia.org/wiki/ReadyDrive#ReadyDrive
http://msdn.microsoft.com/en-us/library/windows/hardware/gg4...
If you have a SSD log device configured, writes greater than 128k (IIRC) are sent directly to disk for performance reasons. This behavior is configurable and probably should be higher for modern SSDs... but anyway it's a neat idea that has been used in practice.
And instead of fixing that stuff, Apple is pushing SSDs to everyone. Way of the future.
There may be bugs and bugs in the past. But there is no systemic "this FS will lose data under heavy use" design fault. If there was then millions of people would have been affected.
And of course Apple is pushing SSD to fix a FS bug not because it is 10x faster and 1/4 the size of a mobile HDD.
Apple computers with HDDs do get unusably slow once they start swapping. So much so that it is usually impossible to terminate the memory-hungry application. With SSDs the computer becomes usable again. Just ask some plastic MacBook users.
So, what exactly is untrue about what I said? Just claiming that it is not is not very productive.
Of course SSD's have a benefit. But I think your particular MacBook may have had a failing drive.
Potentially nothing, but it is all anecdotal. Where's the widespread or researched evidence of HFS (especially in its HFS+ or HFSX variants) being a slow and easily corruptible file system?
It's not like HFS is a rare and infrequently used file system – it's the primary filesystem for all Macs since System 3, for many iPods, and for all iOS devices.
The scaling limits present in HFS+ will rarely be hit by most users and, while not as resilient as more modern FSs, there are no inherent fatal design flaws with HFS that I'm aware of. Perhaps you've pushed HFS+ beyond its limits, or have usage patterns that trigger a rare fatal bug, but just claiming that something is true is not very productive either.
This happened particularly frequently with virtual machines and/or Matlab, both of which can very easily exhaust any amount of memory. But maybe no one else is doing stuff like that.
I used to do a lot of heavy VM work on OSX - and back in the early days of VMWare Fusion v1 and later. I have never had the OS become unstable due to a storage bottleneck/thrashing.
Not that OSX is unbreakable, but it's been a whole lot better/more stable than my experience with Windows. At least on the Mac, a large chunk of the drivers are supported by the folks who wrote the OS.
I agree with the former but not the latter - avoiding swapping made a much bigger performance difference in OS X to Windows, but a swapping app never completely locked up. I have found, though, that an app using 100% CPU can lock up the system to the point where it's impossible to terminate.
HP 3PAR, StorSimple etc all have done it long time back but at a bigger scale. Apple is just scaling it down, and bringing it in front of the regular Joe (as regular as Apple customers tend to be) in a non-complex manner.
StorSimple can dominate the appliance it is made out of to provide its services. Fusion Drive cannot dominate the owner's machine.
How difficult is it to implement some thing like that in a pre known 2 tier configuration context? And what would be the effectiveness of such a solution?
In Windows filter drivers have been used effectively to implement file tombstoning for archive purposes and utilizing reparse points/extended attributes to store the remote URI (for recalling file contents from remote archive upon intercepting a read request). It's not too hard to write a mini filter driver in Windows and use it in conjunction with reparse points to implement tombstoning in filesystem.
It certainly seems unnatural.
Most of those appliance solutions (and probably Fusion Drive for that matter) implement their mojo at the block level and provide block device interfaces. This is to aid their seamlessness, it makes them a lot more straightforward to implement and it makes them a lot more flexible. I would have trouble believing it would be simpler to implement it at a mini-filter/VFS level.
http://www.anandtech.com/show/3734/seagates-momentus-xt-revi...
I'm guessing the SSD portion will be MLC?
Are there any other hybrid drives like this in the wild?
This is more akin to "tiered storage" which has existed before, just not in the consumer space which prevents more/different challenges.
Do you know how difficult it would be to set up something comparable using two drives (HDD+SSD) under, say, Ubuntu?
"Fusion Drive" provides the union of space.
They are in the same vein of "hide the slowness of rotational media" but that is a pretty huge vein.
That's just a 4% increase in space that the Fusion Drive gives you over what a cache would give you. You can call it whatever you want, but I'm going to call them similar.
Anyway the Apple approach should be better because of the bigger SSD and more intelligent caching available at the OS level.
Oh, it's probably not, because that page says the maximum size is 64GB.
(I work @ Intel and have no inside knowledge about this feature at all.)