DiscoDuck Posted December 11, 2018 Share Posted December 11, 2018 (edited) Recently upgraded to 6.6.6 and I'm now doing a parity check. Tried to watch an episode while doing it and it constantly buffers and even looses network connection when the transfer crawls to a halt (code snippet below). Tried to copy the same episode to a "normal" Win 10 computer, incredibly slow. unraidd process is at 100%, when it briefly comes down towards 80-90% the speed improves until unraidd is back at 100%. Tried to transfer from my Rclone-Gdrive share to the Win10 machine, also super slow, Transferred some files from the cache drive to Win10, obtain full speed. Been watching tv from my tvheadend docker without any issues, sonarr, nzbget etc works fine. Use samba for all network transfers. Edit: Also tried to copy from a unassigned drive, same issue as above. Have never experienced this prior the upgrade. What can be the cause? Dec 11 14:56:21 Unraid kernel: e1000e 0000:06:00.0 eth0: Reset adapter unexpectedly Dec 11 14:56:22 Unraid kernel: br0: port 1(eth0) entered disabled state Dec 11 14:56:24 Unraid ntpd[1654]: Deleting interface #1 br0, 192.168.10.20#123, interface stats: received=180, sent=181, dropped=0, active_time=106935 secs Dec 11 14:56:24 Unraid ntpd[1654]: 142.147.92.5 local addr 192.168.10.20 -> <null> Dec 11 14:56:24 Unraid ntpd[1654]: Deleting interface #4 br0, fe80::6d88:ff20:fe29:f104%12#123, interface stats: received=0, sent=0, dropped=0, active_time=106930 secs Dec 11 14:56:26 Unraid kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Dec 11 14:56:26 Unraid kernel: br0: port 1(eth0) entered blocking state Dec 11 14:56:26 Unraid kernel: br0: port 1(eth0) entered forwarding state Dec 11 14:56:28 Unraid ntpd[1654]: Listen normally on 5 br0 192.168.10.20:123 Dec 11 14:56:28 Unraid ntpd[1654]: Listen normally on 6 br0 [fe80::6d88:ff20:fe29:f104%12]:123 Dec 11 14:56:28 Unraid ntpd[1654]: new interface(s) found: waking up resolver Edited December 11, 2018 by DiscoDuck Added info Quote Link to comment
trurl Posted December 11, 2018 Share Posted December 11, 2018 It is normal for disk I/O in the array to be slowed by parity check and for parity check to be slowed by disk I/O in the array. How could it be otherwise? Quote Link to comment
DiscoDuck Posted December 11, 2018 Author Share Posted December 11, 2018 Yes, that's understandable. But why does the Unassigned device get affected? And the Rclone mount? And why does the network all of a sudden cut out? Is it possible to increase the nice value of the parity check to let other processes have priority during the check? Quote Link to comment
trurl Posted December 11, 2018 Share Posted December 11, 2018 17 minutes ago, DiscoDuck said: why does the Unassigned device get affected? 1 hour ago, DiscoDuck said: tried to copy from a unassigned drive Where were you copying to? Quote Link to comment
trurl Posted December 11, 2018 Share Posted December 11, 2018 25 minutes ago, DiscoDuck said: And why does the network all of a sudden cut out? Sounds like a hardware problem such as connection or possibly something at the router. Quote Link to comment
DiscoDuck Posted December 11, 2018 Author Share Posted December 11, 2018 Copied from the unassigned drive to another computer. If it's a network issue, shouldn't all transfers been affected? Worked fine when copying from the cache pool. 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.