Hi, i want to run Dockers and VMs on a cache drive. The drive would be used as regular cache drive as well with the appdata folder set to "Yes" for cache which means apps write to SSD first and it is moved to spinning disks at night for redundancy.

 

Now i read somewhere but dont remember where that this "mover" messes up permissions for the appdata folder and i will have problems with my dockers after this runs. Is this still true or was this old info? Don’t understand how this would be a problem since appdata woult be accessed via /mnt/user/appdata which is a FUSE? Is it true that this would be a problem and i need another SSD for a cache pool if i want redundancy?

Edited May 5, 20188 yr by maciekish

Not sure what you were reading but likely you don't remember correctly.

 

The normal way is to set appdata and any other shares related to docker or VMs to cache-prefer or cache-only so it stays on cache. If this is a new install then the 'system' shares should already be cache-prefer.

 

There is help on the user share settings page and here is a more detailed explanation:

 

https://lime-technology.com/forums/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

 

5 minutes ago, trurl said:

Not sure what you were reading but likely you don't remember correctly.

 

The normal way is to set appdata and any other shares related to docker or VMs to cache-prefer or cache-only so it stays on cache. If this is a new install then the 'system' shares should already be cache-prefer.

 

There is help on the user share settings page and here is a more detailed explanation:

 

https://lime-technology.com/forums/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

 

 

Well thats the „problem”. I only have one cache SSD for now so i want cache „yes” not „prefer”. The question is whether the mover will mess up the permissions if i do this. 

 

Reason being all appdata would be unprotected with cache „prefer” otherwise. 

Edited May 5, 20188 yr by maciekish

No you still don't want yes. If you are worried about redundancy for these then you need a cache-pool or take a look at the CA Backup plugin.

 

There is no good reason to move appdata or VMs. Probably they wouldn't move anyway since mover can't move open files. And they might even break if you did move them.

 

Nobody sets these to cache-yes.

 I hope you are just as concerned about your data on the parity array. Parity isn't a substitute for backups. Make sure you have a backup plan for any important irreplaceable data.

33 minutes ago, trurl said:

No you still don't want yes. If you are worried about redundancy for these then you need a cache-pool or take a look at the CA Backup plugin.

 

There is no good reason to move appdata or VMs. Probably they wouldn't move anyway since mover can't move open files. And they might even break if you did move them.

 

Nobody sets these to cache-yes.

 

Thanks for CA Backup, might be all i need. Is there anything similar for VMs? And yes, i know its not a backup substitute, everything important goes to Glacier on my current setup and will on unRAID as well.

 

Would it make sense to set the appdata share to "only" cache in this case then?

Edited May 5, 20188 yr by maciekish

11 minutes ago, maciekish said:

Would it make sense to set the appdata share to "only" cache in this case then?

 

That is the simpler approach and probably what many use. Take a look at that link I gave. 'Prefer' is another possibility but if you did have overflow you would probably have to stop VMs or dockers and manually run mover since as I said it won't move open files.