[SOLVED] Millions of errors on parity check

[anonymous3759]

I am a new user of Unraid, and just set my array up one month ago (4x6 TB drives + 1 10 TB parity drive). My first monthly scheduled parity check kicked off, and it is reporting millions of sync errors corrected (see attached screenshot). I assume this is not normal. I am using the "Parity Check Tuning" plugin in order to only run the parity check at night, and it is only its second night. All drives pass a short SMART check. Is it possible I did something wrong when I set up the array? 

[Squid]

Did you ever build parity in the first place?  Post your diagnostics.

[trurl]

Looks like you had a good parity check on 2020-04-06 according to the screenshot. Did you change anything about your disks assignments since then?

 

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

[anonymous3759]

Yes, the initial parity build appears to have gone fine. No changes have been made to the disk assignments since then AFAIK. Diagnostics attached. Thanks. 

calculon-diagnostics-20200502-1352.zip

[Squid]

Yeah, I saw that too, but decided that 320MB/s average speed for a 10TB array wasn't even close to being realistic.

 

Was the parity check tuning plugin installed during the initial build of parity?

 

If it was and it paused the initial build and you've reset the system, then it never completed and during a subsequent check (with it installed or not), then the errors would be expected

[itimpi]

4 minutes ago, Squid said:

Yeah, I saw that too, but decided that 320MB/s average speed for a 10TB array wasn't even close to being realistic.

Unraid can report unrealistic speeds in the history if you run the check in increments as it does not allow for the pauses but assumes the whole check was run in the last increment.  If the check completes the Parity Check Tuning plugin patches the history file to what was really achieved.

[anonymous3759]

No, actually I learned about that plugin after the initial setup. The process I used BTW was to set up the array without the parity drive, transferred my data (about 8TB or so), then added the parity drive. 

 

Hold on, I might have totally lied when I said I didn't change anything about the assignments after that first parity check. I may have build the system with 2x 6TB, copied my data, added the parity drive, then added the 2x 6TB a day or so after. There was a lot of shuffling of drives between systems.

[Squid]

5 minutes ago, itimpi said:

Unraid can report unrealistic speeds in the history if you run the check in increments as it does not allow for the pauses but assumes the whole check was run in the last increment.  If the check completes the Parity Check Tuning plugin patches the history file to what was really achieved.

Which boils down to the 320MB/s meaning the build never completed due to a restart.

 

@anonymous3759

Run another check.  It should return zero errors (assuming that the one that had the million odd errors was a correcting check.  If it wasn't, then make sure to check off "correcting" when kicking it off)

[anonymous3759]

Will do. Thanks. 

[John_M]

8 hours ago, Squid said:

Run another check.  It should return zero errors (assuming that the one that had the million odd errors was a correcting check.

You're also assuming that it completed, which it didn't ("Error code: aborted"). So it's quite possible that the inner cylinders have still not had their parity calculated. Expect to see more errors reported before it completes, but not immediately.

[anonymous3759]

17 minutes ago, John_M said:

You're also assuming that it completed, which it didn't ("Error code: aborted"). So it's quite possible that the inner cylinders have still not had their parity calculated. Expect to see more errors reported before it completes, but not immediately.

Understood, I was going to let this check finish first then re-run it (it was paused by the Parity Check Tuning plugin). The parity check is destroying performance to the point where copying files to the share fails and Plex is buffering, so that will be the next issue I tackle after I get the parity checks reporting zero errors. 

[itimpi]

2 hours ago, anonymous3759 said:

The parity check is destroying performance

That was the whole motivation for developing the Parity Check Tuning plugin in the first place.    For many people performance during prime time is very important so off-loading parity checking to only run outside prime time is worth it despite the fact that it now takes longer to complete the parity check.   

[anonymous3759]

To close the loop on this, running another parity check does now report 0 errors corrected. Somehow I must have interrupted the first parity build when I added the parity drive. Thanks folks.