TexasDave Posted January 31, 2023 Share Posted January 31, 2023 I am in the process of tidying things up on my server and this is one of the last things I am considering harmonizing. My array is pretty old (some disks 7 years) and some of these settings were done when I first started. I have 3 data disks (2 old, one fairly new), 2 parity (1 old, 1 new) and two cache drives (both old). See attached. I run 19 dockers (screenshot attached): 12 are using /mnt/cache/appdate 4 are using /mnt/user/appdata 3 do not have a config file My docker setup defaults to /mnt/user/appdata (see atatched) My shares are attached. Appdata is set to "Prefer : Cache". All shares are on DIsk 4 except for TV+TV_Share (Disk 3) and Movies (Disk 1). (see attached) Now my question: I feel like I should be consitant on where I keep my appdata. And I am leaning to moving it all to /mnt/user/appdata. Thoughts? If I did this - does this process make sense? Taken from another post here. stop Docker; change the default appdata storage location in Docker settings to the default /mnt/user/appdata/ (DONE) check the share properties of the appdata share to ensure it is either cache only or cache preffeed (as is the unRAID default) (DONE) move all your folders from /mnt/cache/appdate share to /user/cache/appdate (not sure about this) turn off autostart on any containers you have start docker - check that each config path is set to the /user/cache/appdate path and not the /mnt/cache/appdate path - start my containers - set them back to start automatically if required - delete your empty /user/cache/appdate share if required (But this may "fill up" as things are cached so do not mess with it?) I would like to be consitant but worried I may mess something up and all works fine now. Any thoughts or other ideas/optimizations/suggestions welcome...THANKS! zack-unraid-diagnostics-20230131-1123.zip Quote Link to comment
TexasDave Posted January 31, 2023 Author Share Posted January 31, 2023 I would be willing to consider buying a 3rd SSD for a cache pool if this would buy me anything...Or splitting my current cache pool. Quote Link to comment
TexasDave Posted February 14, 2023 Author Share Posted February 14, 2023 Just wondering if anyone has any advice on this please? Quote Link to comment
Solution JorgeB Posted February 14, 2023 Solution Share Posted February 14, 2023 Go to shares and click compute for appdata, if all of it is on cache you can change everything to /mnt/cache, there won't be any disadvantages and with some containers can perform better. 1 Quote Link to comment
TexasDave Posted February 14, 2023 Author Share Posted February 14, 2023 (edited) Thank you! There is a tiny bit on Disk 4... Can I do the following: 1) Stop the three dockers 2) Move the appdata from disk4 to cache 3) Edit three dockers, change them to use cache. 4) Start dockers? Or is there a better way? It is weird as the three dockers (mylar3, plex and QDirSTat) should be using cache? Maybe that is old stuff? Thanks!! Edited February 14, 2023 by TexasDave Quote Link to comment
trurl Posted February 14, 2023 Share Posted February 14, 2023 4 minutes ago, TexasDave said: Can I do the following: That should work 1 Quote Link to comment
JorgeB Posted February 14, 2023 Share Posted February 14, 2023 Another option, and since appdata is already set to cache=prefer, you just need to stop those containers and run the mover. 1 Quote Link to comment
TexasDave Posted February 14, 2023 Author Share Posted February 14, 2023 All the stuff on disk 4 was old. I just backed it up (actually renamed it OLD) just in case. Turned off dockers, updated config info, and all seems to be working. Many thanks both!! Quote Link to comment
robobub Posted February 14, 2023 Share Posted February 14, 2023 1 hour ago, JorgeB said: Go to shares and click compute for appdata, if all of it is on cache you can change everything to /mnt/cache, there won't be any disadvantages and with some containers can perform better. To expand on this, pointing directly to /mnt/cache instead of /mnt/user, it will skip the unraid shfs layer which incurs some CPU cost. It depends on the access pattern, but my theory is it is a fixed cost per request, e.g. many small requests, perhaps certain database queries, incur greater cost. One advanced way you can try to get a handle on this is checking for a lot of cpu usage of the shfs from the dockers accessing cache. You can check the cpu usage using `htop` or the glances docker app and look for shfs. All normal array access is through here though, so lots of access to the array (instead of cache) can result in high shfs usage. To see what is being requested through the shfs layer, you can run `lsof -c shfs` and see if the usage is more cache or array. 1 Quote Link to comment
Recommended Posts
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.