The 10 minutes I’ve seen in previous tests, seem to be depending on the need what has to be moved around, not something that is hardcoded. I have not seen it to exceed the 10 minutes mark though.

As FUD is not used in portable hardware that Apple sells, there is no need to worry about battery live from FUDs perspective.

FUD will work with just two HDDs

Just out of curiosity I created a Fusion drive (FUD) with two HDDs (same size, one USB, one FW connected). Guess what - FUD is shovelling the data from the second disk to the first one as soon as one accesses the files on disk2 more often.

Interesting enough it always chose the faster drive (USB in my case) to be the caching drive, independent on the order of the drives I used on the command line or the order they were connected.

Furthermore I created a FUD drive with one SSD and two HDDs. It first stored data to the SSD, then to HDD1, then to HDD2. So HDDs were not striped and even though HDD2 was faster it used the HDD1 I’ve given it on the commandline to store things after the SSD.

It did not move data around devices as well so did just exhibit normal concatenated disk characteristics, nothing FUD like.

Operating System file caches will affect FUD

Another item I found out: Blocks that are in the filesystem cache (main memory) won’t affect the caching strategy on FUD. So when you read a file that’s on the SSD and it gets later swapped out to the HDD by FUD. Accessing the file again and again won’t bring it to SSD as long it’s still in the filesystem memory cache.

Last notes

I toyed around with FUD only cause Apple did not release any technical information on how it works. Playing around with it I got a few kernel panics so be warned that using the diskutil core storage commands might not be safe.

I would not suggest using such a FUD drive in a real world scenario. But that also comes from my bad experience I had with HFS+ and TimeMachine in the past.