nekromantik Posted December 2, 2020 Share Posted December 2, 2020 Hi all I got a Share on Unraid using SMBv2 and my Windows 10 transfer speeds used to be good but ever since I added Parity disk they have slowed down by a lot. My share setting for "Use Cache" is set to Yes. Any ideas? Quote Link to comment
trurl Posted December 2, 2020 Share Posted December 2, 2020 Read speed or write speed or both? Quote Link to comment
nekromantik Posted December 2, 2020 Author Share Posted December 2, 2020 (edited) 16 minutes ago, trurl said: Read speed or write speed or both? Mostly write speeds. Edited December 2, 2020 by nekromantik Quote Link to comment
trurl Posted December 2, 2020 Share Posted December 2, 2020 Are you sure it is writing to cache? Quote Link to comment
nekromantik Posted December 2, 2020 Author Share Posted December 2, 2020 4 minutes ago, trurl said: Are you sure it is writing to cache? how do I check? the share settings says Use Cache Yes. Quote Link to comment
UNOPARATOR Posted December 2, 2020 Share Posted December 2, 2020 Do you have any drive set as a "Cache drive"? You can see if you have set any from the top "Main" tab. Quote Link to comment
nekromantik Posted December 2, 2020 Author Share Posted December 2, 2020 9 minutes ago, UNOPARATOR said: Do you have any drive set as a "Cache drive"? You can see if you have set any from the top "Main" tab. yes i can see all my app data docker files are on cache drive Quote Link to comment
trurl Posted December 2, 2020 Share Posted December 2, 2020 Are you replacing files that might already be on the array? Quote Link to comment
nekromantik Posted December 2, 2020 Author Share Posted December 2, 2020 22 minutes ago, trurl said: Are you replacing files that might already be on the array? nope new files Quote Link to comment
trurl Posted December 2, 2020 Share Posted December 2, 2020 If possible before rebooting and preferably with the array started Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. Quote Link to comment
nekromantik Posted December 2, 2020 Author Share Posted December 2, 2020 11 minutes ago, trurl said: If possible before rebooting and preferably with the array started Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. attached not sure if its related but my parity check 2 nights ago that was not correcting scheduled had 5 errors. so I ran another manual check with correction enabled and it showed 5 errors again. could it be bad parity drive? tower-diagnostics-20201202-2326.zip Quote Link to comment
trurl Posted December 3, 2020 Share Posted December 3, 2020 If the first check was non-correcting, then the next check would have found the same errors since they were not corrected. Since that check was correcting, they should be correct now. Run another non-correcting check to verify there are zero errors now. Were you doing these parity checks while testing the transfer speed? Quote Link to comment
trurl Posted December 3, 2020 Share Posted December 3, 2020 Why do you have 100G for docker.img? 20G should be more than enough. Have you had problems filling it? Quote Link to comment
nekromantik Posted December 3, 2020 Author Share Posted December 3, 2020 No was not testing speed during Parity check. Yes It was filling 20G quite easily I found. Quote Link to comment
trurl Posted December 4, 2020 Share Posted December 4, 2020 7 hours ago, nekromantik said: Yes It was filling 20G quite easily I found. How many dockers do you have? The usual reason for filling docker.img is an application writing to a path that isn't mapped. Your diagnostics showed it had already used 47G of the 100 so you almost certainly are writing into docker.img Quote Link to comment
nekromantik Posted December 4, 2020 Author Share Posted December 4, 2020 16 hours ago, trurl said: How many dockers do you have? The usual reason for filling docker.img is an application writing to a path that isn't mapped. Your diagnostics showed it had already used 47G of the 100 so you almost certainly are writing into docker.img About 9 containers. I will check paths for them to see if any not mapped correctly. Logs are one thing which could fill it up like NextCloud or NGINX logs. Those I dont map to a share. However does this impact my speed issues? Quote Link to comment
unraid-user Posted January 1, 2021 Share Posted January 1, 2021 On 12/4/2020 at 12:15 AM, trurl said: How many dockers do you have? The usual reason for filling docker.img is an application writing to a path that isn't mapped. Your diagnostics showed it had already used 47G of the 100 so you almost certainly are writing into docker.img I have a docker img that is filling up rapidly. How would I go about checking which docker is writing to a folder that's not mapped? I have 20 dockers running. Quote Link to comment
trurl Posted January 2, 2021 Share Posted January 2, 2021 The paths that are specified within each application must be mapped to the host, simple as that. For example, Linux is case-sensitive, so if you have specified a path within some application that is different than the mappings in upper/lower case, then it will be inside the docker.img Quote Link to comment
ChatNoir Posted January 2, 2021 Share Posted January 2, 2021 (edited) 11 hours ago, unraid-user said: I have a docker img that is filling up rapidly. How would I go about checking which docker is writing to a folder that's not mapped? I have 20 dockers running. You should have a look at this : The docker.img filling up is covered as well as the basic Docker configuration. It takes some time to understand what is the expected mapping. Maybe SpaceInvaderOne has a video about this, I do not remember. Edited January 2, 2021 by ChatNoir 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.