I've been a user of unraid for several years now, but I've honestly never understood the Cache -> Array, Array -> Cache thing. Think I've just used some random recommendation. My brain does not seem to be compatible with understanding its function no matter what I read or watch about it.
Now that I have some slowness issue with a docker I'm looking at it again.

Both appdata and system is Primary storage: Cache, Secondary storage: Array.
appdata is Cache <- Array

system is Cache -> Array

But it should always be Cache -> Array if primary storage is Cache right? All changes is done on Primary storage I presume, so moving Secondary to Primary overwrites all the changes made on the Primary....? But the function to move from Secondary to Primary is there so it's obviously something I don't understand, and I've never had any issues with configurations made having to be re-made because mover have over-written the Primary with the old configurations on Secondary.

Also read someone saying they should be Cache only - but all that does is remove redundancy if Cache disk fails, no?
Another said they should be Array -> Cache for better performance - then I'm back at zero for the understanding, why would moving backup/secondary to active/primary once a day make for better performance?

In short: (I assume you have an SSD/NVME as the cache-disk and spinners in the array)

• appdata should normaly be on cache ONLY. Don't move this to the array. You could map it to another SSD cache-pool if you want.

• system: same as appdata. Don't move this to the array.

Make backups if you don't have 2 ssd's/nvme's for redundancy. The shares 'appdata', 'system' and 'domains' normaly are set to 'cache only'. No mover action.

English is not my native language so i leave the explanation someone else :)

1 hour ago, Aran said:

In short: (I assume you have an SSD/NVME as the cache-disk and spinners in the array)

• appdata should normaly be on cache ONLY. Don't move this to the array. You could map it to another SSD cache-pool if you want.

• system: same as appdata. Don't move this to the array.

Make backups if you don't have 2 ssd's/nvme's for redundancy. The shares 'appdata', 'system' and 'domains' normaly are set to 'cache only'. No mover action.

English is not my native language so i leave the explanation someone else :)

Okay, I'll try cache only and see if I see some improvements. Thanks.

Still do not understand why, like at all. It's only a form of backup function running once a day (if scheduled for once a day), no?

I'll write out my (miss)understanding of it, in scenario Cache = SSD, Array = HDDs, mover scheduled at 09:00 (am) every day.

1. Cache only: All data stored on SSD only, all read and writes is made on SSD.

2. Array only: All data stored on HDDs only, all read and writes is made on HDD.

3. Cache Primary, Array Secondary, Mover Cache -> Array: All read and writes are made on SSD. At 09:00 every day whatever is on (that share part of) SSD is moved to HDDs.

4. Cache Primary, Array Secondary, Mover Array -> Cache: All read and writes are made on SSD. At 09:00 every day, what's happen then???

5. Array Primary, Cache Secondary: Never a reason to use?

Also, why do alternative 1 vs 3 matter in regards to performance, if all read and writes are made on SSD no matter what (except a short period at 09:00)?

Edited December 13, 2025Dec 13 by tshorts

10 hours ago, tshorts said:

Okay, I'll try cache only and see if I see some improvements. Thanks.

Still do not understand why, like at all. It's only a form of backup function running once a day (if scheduled for once a day), no?

No, one reason is to prevent unnecessary spinup of your hard disks. This video will give you some insights.

• The array disks are protected by parity, spin up and down, are much slower for random I/O

• The cache pool (SSD) is very fast (low latency, high IOPS), is always online and is not slowed down by parity writes.

The three shares i mentioned are high-I/O, latency-sensitive, and constantly accessed, which makes them poor candidates for the parity-protected array.

Lets say you want to copy a large file from your desktop to your server. If your share is set to 'primary cache' and 'secondary array' the the file will be copied to the cahce first -> it is faster (ssd) and your hard drives won't have to spin up. In you case the file will be copied to the array at 9AM. This is ok for your bulk data like media etc. But your 'appdata' conains config files, databases, thumbnails, metadata etc. from your container apps. Those are constantly accessed and need fast read/write speeds. You don't want these on your array.

FYI, i don't use the mover at all. I have appdata, domains and system set to cache only and have weekly backups to a second server. You can backup to your array but the mover is NOT a backup function.

5 minutes ago, Aran said:

In you case the file will be copied to the array at 9AM. This is ok for your bulk data like media etc. But your 'appdata' conains config files, databases, thumbnails, metadata etc. from your container apps. Those are constantly accessed and need fast read/write speeds. You don't want these on your array.

But they are still constantly accessed (read/write) on the SSD only, with array as secondary right? Or do unraid sometimes chose to read/write directly to the secondary outside of the scheduled move? Like if it believes the SSD bus to be full or something.

I'm sorry, i didn't mean 'copied'. I should have said 'moved'. The files are MOVED to the array at 9AM.

So, no. When the mover moves the files at 9AM from your primary storage (cache) to your secondary storage (array) the files wil ONLY be stored on that secondary storage. The files are moved to the secondary storage even when there is plenty of free storage on your primary.(note: i'm not 100% sure that this is correct. The 'prefer' option was removed) If your primary storage is full or above the minimum free space setting, then it will write directly to the secondary storage.

Edited December 14, 2025Dec 14 by Aran