Parity check slowed down after passing the largest drive's capacity

I have an array consisting of 8 disks (using the RB-1200 server sold by Lime Tech a few years back). The largest data drive is 3TB with a 4 TB parity disk that I just replaced.  I recently replaced a failed drive and all went well with that. This parity check is the first check after the failed drive was successfully rebuilt by UNRAID.

What is happening is that the Parity check had a speed of about 60 MB/s up until it reached 75%. After that it slowed down to 10 MB/s. This confuses me, because at 75%, the parity is no longer looking at data drives since the largest data drive is 3TB. Also, the "sync errors corrected" is continuing to rise from the 3 TB - 4 TB position. Is this a normal condition for UNRAID?

I would normally expect the parity check to speed up, and you should not get any errors.  You should post a syslog so we can see if any errors are occurring.

+1 on the syslog, and can you post the steps you took to replace the failed drive and rebuild the data to its replacement drive.

OK, when i get to the computer I will post the syslog. Thanks.

What is happening is that the Parity check had a speed of about 60 MB/s up until it reached 75%. After that it slowed down to 10 MB/s. This confuses me, because at 75%, the parity is no longer looking at data drives since the largest data drive is 3TB. ...  Is this a normal condition for UNRAID?

Absolutely NOT normal (as you know & as already noted above.  Once the 3TB point has passed, the ONLY drive still "contributing" to the parity check is the parity drive itself ... so I'd expect things to actually speed up a bit ... NOT drop by 84% !!!

Also, the "sync errors corrected" is continuing to rise from the 3 TB - 4 TB position. Is this a normal condition for UNRAID?

Sync errors at this point indicate that the parity drive doesn't contain zeroes [since UnRAID uses even parity].    So it's simply writing zeroes to the parity drive.    HOWEVER ... this should have been done when you upgraded from a 3TB to 4TB parity drive ... so it clearly indicates a problem with the drive.

Posting a syslog won't hurt ... it may show some details that help ... but what I'd most like to see at this point is a current SMART report for the parity drive.

syslog attached now and smart report from parity drive.  The problem is that the syslog stops around 5:30 this morning. That is around the time the parity check reached 75% completion.

syslog.txt

paritydrivesmartreport.txt

What is the error count for disk 6 on unRAID Main?

478, that might be a separate problem

This looks more like an issue with a disk that is causing the slowdown and not something specifically with unRAID.

When I left the house this morning the parity check had about an hour left. I will run it again and see if the same issue occurs.

Disk 6 is experiencing read errors. This will make the system very slow. The parity check is not useful because disks 6 cannot be read.

After I ran a parity check a second time the speed was just fine. Was ~60MB/s prior to  prior to reaching 75% (3TB). Once it passed the largest drive and the parity drive was "alone" the speed reached 120MB/s.  Must have had to do with the swap procedure I used when replacing a failed drive with a larger disk (Which ultimately became the parity drive). All is good now.

Nice to see it's working -- but sure begs the question about just WHY it was so slow the first time !!

It was slow the first time because it unraid was writing to the last TB of the parity drive for some reason.  Even though the largest data drive was 3 TB it was still writing to the parity drive in the 3TB to 4TB range. I assume to establish even parity for future upgrades.  It must of had something to do when I did the swap-disable procedure, since my previous parity drive was only 3 TB.  So, my guess is that when the swap-disable procedure is used, unraid does not look at the drive space beyond that of the size of the previous parity drive. This then gets fixed during the next parity check.

I had the same thought initially => HOWEVER, it should be able to write at FAR greater speeds than 10MB/s ... so there's got to be something else involved in why it was so slow.  But at least it's all okay now, so I suspect it will just remain one of life's little unsolved mysteries