I have recently replaced my 6TB parity drive with two 8TB drives. The 8TB drives pre-cleared at roughly 185MB/second. 

When I started the parity sync, they started at about 16MB/second and the speed has not changed. I tried canceling and rebooting to see if it would have any effect, it did not.One thing I have considered is that I don't know which cards things are on right now. Could a BUS be overburdened? I am down to three  6TB drives and the two 8TB parity drives now and the speed has not changed. I can't believe that would be too much bandwidth, so I am under the impression something else had gone wrong somewhere.

Is there anything in the logs that provide any insight into why things are going so slowly?

 

Thanks for any help.

zion-diagnostics-20171220-0858.zip

You have a stale browser windows open flooding the log with wrong csrf_token errors, close it, reboot, restart the sync and post new diags.

OK, so I noticed those after I uploaded them and was trying to get new ones when you posted. 

I restarted, closed/reopened the browser I was using and everything looked fine. Then, when I started the array, the messages came back. So, I restarted and used a completely different browser. Again, everything looked fine, until I started the array and the CSRF token errors started again. Is there something wrong with one of the plugins that is causing that?

Here are the new diags with a few CSRF token errors towards the end.

Thanks for the help with this.

zion-diagnostics-20171220-0955.zip

Oh, actually, I see there are some CSRF errors before the array starts. It's just there is less going on after it starts and the CSRF token errors keep on going. 

(I think.)

Edited December 20, 20178 yr by teedge77

You have an old browser window open, maybe on another computer, tablet, etc, or some remote control plugin.

OK, I checked netstat and saw my hackintosh was logged in. It's off now.

 

OK, so I see a few of the following errors and I am trying to find the corresponding drives. Being that they are ata9/11/13/14, could it be a controller problem or a loose cable?

Dec 20 10:21:20 ZION kernel: sas: ata14: end_device-1:5: cmd error handler

 

Edited December 20, 20178 yr by teedge77

2 minutes ago, teedge77 said:

OK, so I see a few of the following errors and I am trying to find the corresponding drives. Being that they are ata9/11/13/14, could it be a controller problem or a loose cable?

Dec 20 10:21:20 ZION kernel: sas: ata14: end_device-1:5: cmd error handler

 

 

Those are not errors.

Oh, OK. I am trying to be proactive, but not doing a very good job, I see. Ha.  I saw them highlighted in red and only a few of the disks, so I thought they were errors.

Well, let me know if you spot the problem. 

I though you're going to post clean diags, but the 2nd ones are clean enough, is the speed always constant at 17MB/s, or does it go up and down?

It stays between 16 and 19 the entire time. 

Here are some diags without any CSRF errors too. 

zion-diagnostics-20171220-1053.zip

Nothing jumps out, there were reports of low write performance with those new Seagate SMR drives, but it was during random writes, they should be fast with sequential writes, but only testing with different disks could confirm that, there were also some reports of specific disks having slow performance only during a parity sync, after that they performed normally, IIRC some HGST drives, when the sync finishes see if writes to the array are at normal speed, with and without turbo write.