My unRaid environment is about a week old and Im working through setting up several Docker containers. The Docker portion is going well, but Im curious about the proper usage of the cache drive for appdata.

 

Im currently specifying /mnt/cache/appdata for container config locations, and everything looks like its correctly writing to the cache drive. Should I instead be using /mnt/user/appdata and setting the share to Use Cache Disk to Only? Is one different from the other? What is the best practice?

 

I want to take advantage of the SSD speed of my cache drive, and don't want the drive's contents being written to the array.  Which method is best?

The two different ways of specifying access to appdata are functionally identical.    The advantage (if any) of using 'Cache Prefer' method is that you can initially start without the cache drive and later when/if you add one the system will automatically and transparently migrate the share contents from the array drives to the cache drive you have just installed.   All your settings remain unaltered for your dockers.

2 minutes ago, itimpi said:

The two different ways of specifying access to appdata are functionally identical.    The advantage (if any) of using 'Cache Prefer' method is that you can initially start without the cache drive and later when/if you add one the system will automatically and transparently migrate the share contents from the array drives to the cache drive you have just installed.   All your settings remain unaltered for your dockers.

 

Thanks itimpi. Im guessing this also means Im ok with directly specifying /mnt/cache to ensure the config data lives, and stays, on the cache.

 

If anyone else has commentary, Id love to hear it.

12 minutes ago, spalmisano said:

 

Thanks itimpi. Im guessing this also means Im ok with directly specifying /mnt/cache to ensure the config data lives, and stays, on the cache.

 

If anyone else has commentary, Id love to hear it.

Just because you specify /mnt/cache doesn't mean it won't get moved. Whether something stays on cache depends on the user share setting.

8 minutes ago, trurl said:

Just because you specify /mnt/cache doesn't mean it won't get moved. Whether something stays on cache depends on the user share setting.

 

That makes sense; thanks. I'll leave it set to Only and keep an eye on the data's growth.

My 2 cents on this...

 

Depending upon what's going on with the server and the downloads / VMs / etc, it is possible for me to actually fill the cache drive (rare, but it has happened to me).  For this reason, I prefer to use /mnt/user/.... for my downloads and appdata, and have the share settings to be prefer.  That way if it does fill up, excess files will get written to the array until I free up space, at which point the mover script will put everything back on the cache drive where it belongs.

 

/mnt/cache/appdata vs /mnt/user/appdata:  The primary reason to use /mnt/cache/... instead of /mnt/user/... is to outright force the system to put the items onto the cache drive regardless of the share's settings.  But, with a setting of prefer or only, then its effectively the same thing.  

 

That being said, a small minority of users have issues with certain apps' appdata being referenced by /mnt/user/appdata/..., and switching it to /mnt/cache/appdata/... fixes the problems for them....(and I am not one of those users, and have thus far been unable to replicate any of their supposed issues)

 

Net result is that if you have a large enough cache drive that you don't need to worry about it ever possibly filling up, for the most trouble free experience, reference your appdata (and download) shares by /mnt/cache/appdata/....  If you think space might be at a premium for whatever reason on your cache drive, then reference the appdata paths (and download paths) as /mnt/user/appdata with a setting of prefer...

1 hour ago, Squid said:

My 2 cents on this...

 

Depending upon what's going on with the server and the downloads / VMs / etc, it is possible for me to actually fill the cache drive (rare, but it has happened to me).  For this reason, I prefer to use /mnt/user/.... for my downloads and appdata, and have the share settings to be prefer.  That way if it does fill up, excess files will get written to the array until I free up space, at which point the mover script will put everything back on the cache drive where it belongs.

 

/mnt/cache/appdata vs /mnt/user/appdata:  The primary reason to use /mnt/cache/... instead of /mnt/user/... is to outright force the system to put the items onto the cache drive regardless of the share's settings.  But, with a setting of prefer or only, then its effectively the same thing.  

 

That being said, a small minority of users have issues with certain apps' appdata being referenced by /mnt/user/appdata/..., and switching it to /mnt/cache/appdata/... fixes the problems for them....(and I am not one of those users, and have thus far been unable to replicate any of their supposed issues)

 

Net result is that if you have a large enough cache drive that you don't need to worry about it ever possibly filling up, for the most trouble free experience, reference your appdata (and download) shares by /mnt/cache/appdata/....  If you think space might be at a premium for whatever reason on your cache drive, then reference the appdata paths (and download paths) as /mnt/user/appdata with a setting of prefer...

 

This was well written. Thanks for the reply.

 

For anyone with the same issues/questions, the above, plus this thread, are both helpful.