December 15, 20214 yr I am having trouble with my cache disk jumping from 30% full to 100% instantly (70% warning never triggers). Yet the gui shows size 120GB, used 35GB, free 0B I don't understand how that is possible. The only things on cache are appdata-prefer downloads-yes domains-yes (empty) appdata and downloads have min space set to 2gb It has happened 3 times in 12 hours, each different. 1st time. Disabled docker, invoked mover. All good 2nd. Disabled dockers 1 at a time invoking mover each time, after the deluge docker and mover it returned to normal - I'm thinking I've narrowed it down 3rd. Disabled deluge, invoked mover. Nothing. Disabled docker, invoked mover, Nothing........(Though I am now realizing possibly because it had nothing to move from the downloads as I moved it before and there were no new downloads happening) Changed appdata cache prefer>yes invoked mover. Working Before the mover even finished, almost when it started moving the 30ish GB of appdata the gui started reporting used 30GB free 90GB, instead of the 0B seconds ago I am very confused by this and would really appreciate some help. PS: Drive passes SMART test.
December 16, 20214 yr Author 4 hours ago, trurl said: Attach diagnostics to your NEXT post in this thread 4554551n-diagnostics-20211216-1442.zip Here it is with everything working as expected. This is after changing appdata to cache yes. Invoking mover then back to prefere and invoking mover. It was only 30GB but for some reason took about 2 hours each way to do the move. Is that normal? Seems like it should have been a LOT faster. Do you need me to upload diagnostics again when the issue happens again? Let me know.
December 16, 20214 yr Just now, 4554551n said: It was only 30GB but for some reason took about 2 hours each way to do the move. Is that normal? Seems like it should have been a LOT faster. If that appdata contained Plex or something similar, there are thousands and thousand of small files and those take a while to move.
December 16, 20214 yr Author 4 minutes ago, Hoopster said: If that appdata contained Plex or something similar, there are thousands and thousand of small files and those take a while to move. Yes. So that makes sense then
December 16, 20214 yr 17 hours ago, 4554551n said: only things on cache are appdata-prefer You want appdata, domains, system shares set to cache-prefer with all their contents on cache. These files are always open by dockers/VMs and they will have performance impacted by slower array, and keep array disks spunup if they aren't all on cache. Also, you probably don't need 50G docker.img, 20G is often more than enough and if you have been filling it, making it larger won't fix that, it will only take longer to fill. Your cache may be a little small for much actual caching.
December 16, 20214 yr Author 7 hours ago, trurl said: You want appdata, domains, system shares set to cache-prefer with all their contents on cache. These files are always open by dockers/VMs and they will have performance impacted by slower array, and keep array disks spunup if they aren't all on cache. Also, you probably don't need 50G docker.img, 20G is often more than enough and if you have been filling it, making it larger won't fix that, it will only take longer to fill. Your cache may be a little small for much actual caching. I have appdata as cache-prefer, but system as cache-yes. Is that a problem? Does that mean the docker.img should also live on the cache disk? I had mine keep blowing up to 100GB a year and a half or so ago, so I think I changed it to cache yes. I honestly don't know what it actually does, but my understanding was that it's what holds the containers and it's used when they first load. So it shouldn't matter that it's on the array when it's only accessed when dockers are started or updated? I don't know why it grows like that when I'm not adding more containers. Currently it's 14gb set to 50 when it was recreated a yearish ago. So Is there a big advantage to it being cache prefer over cache yes? How do I stop it blowing out? What should I do if it does? - Last time I just deleted it, and went to the history of my dockers, and re-downloaded all the dockers. That doesn't seem like something that should be a regular task. Do you really think 120GB is not enough for cache?... it's currently under 30gb of appdata, and I've got some torrents going so it's closer to 40 total use. I've had some issues if I'm downloading a 100gb torrent, obviously that doesn't work and I have to get creative. But even if the docker was 20gb that would still give me 70gb of flexible cache, is that not enough??..... Lastly, what the heck could have been causing the actual issue I was having above? Since moving app data to cache yes, invoking mover, setting it to cache prefer, invoking mover, it's been running good for about a day. But the whole size 120gb, used 30gb, free 0b still seems super messed up and I would like to know how it's possible and what caused it.
December 17, 20214 yr 2 hours ago, 4554551n said: Does that mean the docker.img should also live on the cache disk? I had mine keep blowing up to 100GB a year and a half or so ago, so I think I changed it to cache yes. Yes, it should be on cache and set to stay on cache. The executable code for your dockers is in docker.img. This file is always open, and if it is on the array your dockers won't perform as well and your array disks can't spin down. 20G is often more than enough. If your docker.img usage is growing it is usually because you have one of more applications writing to a path that isn't mapped. Each application in its settings must only specify paths that correspond to container paths in the mappings, case-sensitive.
December 17, 20214 yr 2 hours ago, 4554551n said: Do you really think 120GB is not enough for cache? Really depends on how you use it. If your user shares aren't caching much it may be OK. I had 150G cache for years but I didn't do much caching.
December 17, 20214 yr Author 4 hours ago, trurl said: Yes, it should be on cache and set to stay on cache. The executable code for your dockers is in docker.img. This file is always open, and if it is on the array your dockers won't perform as well and your array disks can't spin down. 20G is often more than enough. If your docker.img usage is growing it is usually because you have one of more applications writing to a path that isn't mapped. Each application in its settings must only specify paths that correspond to container paths in the mappings, case-sensitive. Thank you, I will do that. Any advice on the original issue?
December 17, 20214 yr On 12/15/2021 at 11:44 PM, 4554551n said: Do you need me to upload diagnostics again when the issue happens again? yes
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.