Slow Parity Check after upgrade

Parity check speeds on my system got notably faster after I installed my first 6.0 beta.  On previous versions of unraid it had taken about 22 to 23 hours to complete, and with the 6 betas, of which I've has several versions installed,  it has usually taken about 18 hours. 

A couple of days ago I upgraded from 6.0b14 to 6.0.1.  Everything seemed to be running great, and I had no noticeable performance issues of any kind.  In fact, user share access seemed peppy.  Yesterday morning I initiated my first parity check since the upgrade.  And the speed was very slow. Before the update a Parity check would start out at around 50 to 60 MB/s and near the end get to over 90 MB/s, once some of smaller drives had finished being involved.  The parity check yesterday went at between 12 and 18 MB/s.

My plan was just to let it go and see how long it actually took to complete before posting anything about this.  My thought was that if it was a bad drive or a bad cable, assuming none of my larger drives were causing the problem, once it got past the problem drive it would return to normal, and I'd have a good starting point in troubleshooting. 

This morning the parity check was only 23% complete after 23 hours.  When I tried to access the server's user or disk shares it was completely unresponsive.  The web page was at tad bit slow, but still usable.  Usually during a parity check share access is significantly slower, but still possible.  This morning it wasn't possible, every attempt to access either a user or a disk share resulted in an eventual timeout.  Although I noted that a user share access attempt that would have involved 2 smaller drives that had spun down already, spun them up. 

At this point the web page was still open on my workstation, from when I had checked the progress before.  I decided to stop the parity check and reboot the server.  Parity check stop worked, and then when I went to take the array offline it couldn't unmount the disks.  It just scrolled messages about that at the bottom of the webpage screen.  I've only seen that happen once before.  When I was migrating my disks to XFS, I accidentally left a MC session open in Screen, and to unmount the array I had to exit out of that first.  But I assure you that to my knowledge nothing like that was going on this time.  But "something" must have still had a disk resource locked.  Since I had no idea what that could be, I hard booted the server.

After the hard boot the server came back up and initiated a parity check as it normally would after an improper shutdown, and it had the same slowness as the previous time.  I stopped the parity check, and used the server.  Everything was accessible, all disk shares and user shares were fine.  No drive had any SMART errors on them, "that I wasn't already aware of". (I have 1 drive that has had 11 pending sectors on it for 6 months). 

After using the server for a while, I tried to stop the array and the same thing happened as before.  It just got stuck unmounting the disks. 

Nothing at all changed about my system besides the OS version between the last time I did a parity check with B14 and the partiy check with 6.0.1.  I've had the same hardware since December of last year.  I use no dockers or plugins.  I have screen starting fro my Go.  I can remove that easily enough, and will probably try that as a next step when I get home this evening.  Otherwise everything should be stock unraid.

Tools->Diagnostics. Attach file.

Hey, Thanks for being willing to look at this.

I removed my email address from the syslog.  Otherwise files are intact. 

I also removed screen and utemper from the Extra folder.  Rebooted and tried the parity check again.  Made no difference. 

Also of note is that on the dashboard page my cpu shows that it's getting pegged at 100% when a parity check is running, but returns to single digit utilization when I stop it. 

unraid-diagnostics-20150724-0739.zip

See here: http://lime-technology.com/forum/index.php?topic=39125.0

Do any of the issues discussed fit?

Thanks for the suggestion.  That was an interesting thread, but I think I may have similar symptoms but a different problem than what the rest of them are having.  My CPU seems to be occupied with some process called kworker, which takes up around 62% of cpu while the parity check is running, but drops down to 0 when I stop it.