Using The Cache Drive With Docker


Recommended Posts

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?

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment

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

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.