Hacker News Reader

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.

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.

Most video files could probably be cached in ram at this point anyway.

Also, by not duplicating, you presumably increase probability of data loss considerably. Now you lose data if either of the devices (SSD, HDD) fails. That certainly seems a bad trade-off for a few percent more space.

But in a cache, if the main storage fails you can't just get the data off the cache anyway. On it's own it's not a filesystem the OS can read, as it's managed by the device driver. In theory the data is there, but there'd be no practical way to get at it. In a fusion drive, if one drive fails it looks like you'll still be able to recover the data on the other drive.

OK, but the probability of data loss is still worse than with a cache, because failure of (HDD or SSD) is likelier than failure of HDD alone.

But a HDD with a flash cache is still a hdd component and a flash component. Putting them in the same enclosure and using one of them as a cache for the other doesn't magically merge their combined MTBFs into a lower number.

That is correct. While gmac is technically correct that you have a higher expected amount of data lost with the non-caching system than you would with the caching system, but that's just the trivial fact that more space = higher loss expectation.

To be fair, if either of those fails on an HHD, you're almost certainly going to lose some data anyway (whatever hasn't been written back to the HHD yet). And I would expect the HDD to fail long before the SSD anyway, which is going to cause you to lose almost everything.

> 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.

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.