OK, so last nights parity check yielded the 1st ever parity check error in 5 ish years of unRAID.

 

The past 2 weeks have seen a lot of change in my system.   

- 1st I reformatted all but one of my drives with XFS instead of Reiserfs.  This took a full week but seemed to go without incident.  I used Teracopy with verification to copy the contents off and back on each drive.  The only checksum issues I had were a few files that didn't surprise me to have seen an odd issue.  I think they were data files in my music collection that are updated by WMP in the background.  My wfie's laptop was open while that copy over took place so thats what I assumed caused that issue. 

2nd I've been re-ripping movies, changing the format, probably about 4-500 GB worth at this point.  Some before the format change, and some after.

3rd I updated my system, new MB / CPU / RAM.

 

The anomaly during the copy over is the only thing that makes me think "possible cause" for a parity issue.  But if her laptop made changes during the copy, unRAID still should have read it as a file change and updated parity, correct?

 

Here is what i found in the syslog:

Sep 11 06:06:17 TODD-Svr kernel: md: parity incorrect, sector=1565565768

Sep 11 06:06:17 TODD-Svr kernel: md: parity incorrect, sector=1565565776

Sep 11 06:06:17 TODD-Svr kernel: md: parity incorrect, sector=1565565784

Sep 11 06:06:17 TODD-Svr kernel: md: parity incorrect, sector=1565565792

Sep 11 06:06:17 TODD-Svr kernel: md: parity incorrect, sector=1565565800

 

So any ideas?  would you worry?

 

Hardware list in my signature is current.  Diagnostics attached.

 

Thanks in advance.

svr-diagnostics-20160911-2234.zip

Assuming you do correcting checks, just run it again and confirm there are no errors.  [Or, if you didn't do a correcting check, do it now and let it correct the errors => THEN run it again to confirm all is well.]

 

Assuming all is then fine, I wouldn't be concerned.

 

No matter what copy operations you did, unless there was a power failure or crash parity should always be in sync, I don't remember in my almost 10 years of unRAID use to get an unexpected sync error on any of my servers.

 

SMART looks fine for all disks, just make sure your Samsung HD204UI are using the latest firmware, if not they can have data loss/corruption in certain situations.

 

Beyond that you need now to run a correcting parity check, if the same sync errors are detected and corrected then run a new non correcting check, if different errors are detected you may have a hardware issue.

This was a non correcting parity check.  So let me make sure I'm following this:

 

1. I shoud run a CORRECTING parity check.  (I can start this at lunch today).

2. I should expect to see the same errors but no more.

3. Re-run a NON CORRECTING parity check and see if it comes back clear.

 

If nothing new surfaces, then I probably don't have anything to worry about?

That's correct.

 

OK correcting Parity check done:

 

Sep 12 15:01:44 TODD-Svr kernel: md: correcting parity, sector=1565565768

Sep 12 15:01:44 TODD-Svr kernel: md: correcting parity, sector=1565565776

Sep 12 15:01:44 TODD-Svr kernel: md: correcting parity, sector=1565565784

Sep 12 15:01:44 TODD-Svr kernel: md: correcting parity, sector=1565565792

Sep 12 15:01:44 TODD-Svr kernel: md: correcting parity, sector=1565565800

 

Is it of note that they all are exactly 8 sectors apart from each other and then ends in 00?  probably not coincidental but not sure what it means.

 

OK the 2nd non correcting will be run over night.

zero errors detected.  Would you worry about figuring out why, or just move on?

Unless you get some more on the next scheduled check, move on.

 

If you have checksums you can check all files, it's impossible to know if the sectors corrected were from an out of sync parity or some issue with one of the disks.

Agree ... just move on.

 

Unless you have complete backups to compare the files to; or checksums to verify; there's no way to know for certain if the error was indeed on the parity disk or one of the data disks ... but in the vast majority of the cases these are on the parity disk.  Personally I always do correcting checks, so if there are any errors they're simply fixed.