March 23, 201610 yr I've been reviewing my configuration and found that my /mnt/user/appdata was not set to cache only. I've just set it to use cache ONLY that but found that my data (plexmedia, owncloud, crashplan) are still spread all over multiple disks (in addition to /mnt/cache/appdata) Is the right approach to use MC and move all the files to /mnt/cache/appdata and then delete the share or?? Just want to make sure I'm doing it correctly--thanks!!
March 23, 201610 yr Community Expert I've been reviewing my configuration and found that my /mnt/user/appdata was not set to cache only. I've just set it to use cache ONLY that but found that my data (plexmedia, owncloud, crashplan) are still spread all over multiple disks (in addition to /mnt/cache/appdata) Is the right approach to use MC and move all the files to /mnt/cache/appdata Yes. and then delete the share or?? Just want to make sure I'm doing it correctly--thanks!! you do not delete the appdata share after doing the move. What you do is delete the appdata folder of each array disk.
March 23, 201610 yr Author Perfect--thank you very much!! For my volume mappings does it matter if it's /mnt/cache/appdata vs /mnt/user/appdata if /appdata is forced to reside on cache only? Or one in the same?
March 23, 201610 yr Perfect--thank you very much!! For my volume mappings does it matter if it's /mnt/cache/appdata vs /mnt/user/appdata if /appdata is forced to reside on cache only? Or one in the same? The files presented are the same, however since /mnt/user is a FUSE filesystem, some apps may not work properly if they need symlinks. Better to use /mnt/cache for program settings and system folders.
March 23, 201610 yr Community Expert And be sure you don't move from /mnt/user/appdata to /mnt/cache/appdata. You must move from each disk to cache, like /mnt/disk1/appdata to /mnt/cache/appdata.
March 24, 201610 yr Author And be sure you don't move from /mnt/user/appdata to /mnt/cache/appdata. You must move from each disk to cache, like /mnt/disk1/appdata to /mnt/cache/appdata. Ouch...too late! :'( I moved from /mnt/users/appdata to /mnt/cache/appdata and then picked overwrite. I deleted from the individual drives. I ended up having to reinstall Crashplan which was no big deal. Owncloud worked perfectly but Plex had me do a "merge"/recognized the "other" library (which was itself). About a couple of dozen or so of my movie covers are missing but a refresh/misidentified action doesn't correct it. The metadata is all there as are the background pictures even but the cover art isn't. iPhone sees two media servers with the same name but refuses to connect to either (could be a NAT issue). From a migration perspective it's done but just a few minor things to clean up that are questions best suited for another forum here. Thanks for the assist all!
March 24, 201610 yr Community Expert The typical symptom of the "User Share Copy Bug" is a lot of zero length files. Search for it for more details of what causes it. Basically Linux doesn't know that user share files and disk files may actually be the same file so it will start off the copy/move by creating a zero length file, then when it tries to copy/move the data to that file, it has already truncated the data. Disk shares are turned off by default to prevent you from doing this over the network, but there is nothing to protect against it from the command line.
May 25, 20206 yr Slightly related question here about cache, appdata, and docker locations. I want to be sure I have the stuff setup right for performance and minimal hassles. I've currently got appdata on it's own user share. Use Cache Drive is set to PREFER. I recently did a cache drive swap out using the Backup Appdata plugin, and now every item in appdata is on the cache drive. That reminded me about dockers. I'm sure they'd perform better if they were on the cache drive. At the moment, Docker settings put the vdisk in a regular share, "system" which says Do Not Use Cache drive, exclude Disk 1 (not sure why that is). Then the default appdata storage location, is also appdata share, which seems to be correct. It's been several years since I've done a clean install here, and many of these settings might be left over from legacy stuff that I just haven't messed with. Upgrading to an M.2 cache drive has made a noticeable improvement that I'm very happy with! Edited May 25, 20206 yr by dkerlee
May 25, 20206 yr Community Expert Posting diagnostics will let us see which disks these docker/VM shares are currently using and we can advise further.
May 25, 20206 yr Thanks a million @trurl I think I got it sorted, I just went and did it. It went swimmingly, but it would still be super valuable if you could take a peek at the settings just to ensure I got this setup in a way that makes sense! Speed, redundancy, logic. Thanks! other thread rubble-diagnostics-20200525-0951.zip
May 25, 20206 yr Community Expert Looks mostly OK. appdata and system shares are all on cache and set to cache prefer. People usually also put domains share on cache and cache prefer for better VM performance, but you don't have VMs enabled currently. Why do you have 40G allocated to docker image? You aren't using even 10G, I usually recommend 20G. I always ask if someone has been filling docker image when I see it set to more than 20G.
May 25, 20206 yr that's probably what was happening. I'm not sure what it was that was bringing docker storage to 70% (when it was 30GB), but I did find entire seasons of tv shows that I had "put in trash" from Krusader: apparently that's inside appdata. Whoops! In that vein I got cAdvisor so I could look at the size of individual dockers to see if anything popped up. I think I'm looking at the right page there?:
May 25, 20206 yr Community Expert Looks like docker image usage is fine now. If you want to reduce it to 20G and recover the other 20G you can delete and recreate it in Settings - Docker then the Previous Apps feature on the Apps page will reinstall your dockers just as they were.
Archived
This topic is now archived and is closed to further replies.