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, 20187 yr by DiscoDuck
Added info

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?

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?

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?

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.

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.