Apple's Fusion Drive: Faster Performance in a Simple Consumer-Focused Package

[milo]

You're welcome.

[gnasher729]

Originally Posted by Aluminum213

That's 100% against how apple says it works

Well, what Apple said in public was said so that ordinary people think "wow, that's a great idea, I'll buy that". If Apple told the public the exact details of what happens, then 99% of the population would just say "I haven't got the foggiest idea what you are trying to tell me". Which would be bad, because it _is_ actually a great idea and these 99% _should_ buy it.

[gnasher729]

Originally Posted by AidenShaw

I'll post a link in the morning, but either Tom or Anand had a description of Fusion™ which said that the OS level software could pin a file to the SSD or the HDD. That's an inversion of abstraction.

I hope that's not the case. And as more information became available, this is my current understanding how things work:

1. SSD and HD are divided up into blocks of 128 KByte.

2. Core Storage decides whether any 128 KByte block resides on the SSD drive or the hard drive, and where exactly it resides. Core Storage can on its own change the location of a 128 KByte block at any time.

3. The OS doesn't know anything about these blocks. So when a 128 KByte block is moved, the OS isn't told, it doesn't need to update directory entries, and so on.

"Pinning" a file to the SSD drive with this setup would be quite difficult. Actually, it would be complete madness. And "pinning" files is nonsense anyway; it's unlikely that a user can consistently make better choices than Core Storage, and Core Storage working on parts of a large file makes it more effective anyway.

[mentaluproar]

Originally Posted by gnasher729

I hope that's not the case. And as more information became available, this is my current understanding how things work:

1. SSD and HD are divided up into blocks of 128 KByte.

2. Core Storage decides whether any 128 KByte block resides on the SSD drive or the hard drive, and where exactly it resides. Core Storage can on its own change the location of a 128 KByte block at any time.

3. The OS doesn't know anything about these blocks. So when a 128 KByte block is moved, the OS isn't told, it doesn't need to update directory entries, and so on.

"Pinning" a file to the SSD drive with this setup would be quite difficult. Actually, it would be complete madness. And "pinning" files is nonsense anyway; it's unlikely that a user can consistently make better choices than Core Storage, and Core Storage working on parts of a large file makes it more effective anyway.

This

[AidenShaw]

Originally Posted by gnasher729

"Pinning" a file to the SSD drive with this setup would be quite difficult. Actually, it would be complete madness. And "pinning" files is nonsense anyway; it's unlikely that a user can consistently make better choices than Core Storage, and Core Storage working on parts of a large file makes it more effective anyway.

I agree that pinning isn't a great idea - that's why I said "It's really unfortunate if the OS-level filesystem code is talking to the volume manager".

Anand says:

By default the OS and all preloaded applications are physically stored on the 128GB of NAND flash. But what happens when you go to write to the array?
...
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.

http://www.anandtech.com/show/6406/u...s-fusion-drive

[AidenShaw]

Originally Posted by subsonix

Of course it isn't. If you say "sectors" why would it be blatantly obvious that you really mean "clusters of sectors"?

In today's reading comprehension class, we'll look at the original claim, which was:

They track sector-level accesses and automatically move "hot" sectors to fast storage - without any knowledge of "files".

Note that "track sector-level accesses" is inherently independent of any higher level clustering. If, as volume managers should be doing, you're looking at accesses at the sector level. Perhaps you're mapping those sector accesses to clusters of sectors - but you're still "tracking sector-level accesses".

The second part, "move 'hot' sectors to fast storage" similarly is true regardless of any clustering. It's true even if you move a few adjacent "cold" sectors to fast storage.
______________

By the way, the advantages of clustering sectors should also be easy to understand.

First, clustering collapses the size of the data that the volume manager needs to understand - using 512 KiB clusters reduces the number of elements by a factor of 1024.

Second, clustering helps you find hot spots.

Consider if you read a 512 KiB region twice. Without clustering, you have 1024 clusters (clusters of one sector) with a read count of two. If you have 512 KiB clusters, though, you have one cluster with a read count of 2048. With clustering, nearby accesses can be more easily seen.