MelodyKH3

Thanks for your response. It was on the array; was a pain to move back (had to disable docker service; somehow the file docker.img was still open; ended up having to reboot the server because fuser couldn't work out what had the file open; then mount hte arrays, move the files; enable docker again) It's now on /mnt/cache as you can see here (i also set system and appdata to be cache only) root@Sol:~# find /mnt -name docker.img /mnt/user/system/docker/docker.img /mnt/cache/system/docker/docker.img This mostly resolved the issues; I can now load emby etc while the mover is running; so no more unexpected down time mostly. While investigating I noticed all IO seems to go through loop2, is this normal and would you be able to show me any documentation or explain what it is for me? I can't seem to find much on it sorry. Thanks!

Hi; I have had a persistent issue with unraid. The mover causes extremely high iowait; here is some logs from swarmprom (grafana + friends) This has persisted me resetting everything and creating a new array. I have a ST8000DM004 (Seagate Barracuda Compute) as parity (though I think it may be SMR...) and ST8000VX0022 (SkyHawk Surveillance) as the only array drive. There is also a 256gb SSD as the cache from which the mover is moving files. When the mover runs; the web ui somewhat works (the docker page doesn't load; or loads very slowly) but none of my containers can be reached due to timeouts. As far as I can tell my appdata folder (where all my containers run out of) should be on the cache drive and unaffected by this. I tried adjusting the priority of the mover with mover tuner setting it to low and this seemed to help a little bit but still causes it to be unusable. Does anyone have any tips for diagnosing this issue or making it less severe? I have attached the diagnostics. sol-diagnostics-20200429-1218.zip