At 12:01 this morning my system started it's monthly parity check. (I'm running 4.7 and have the parity check set to run in NOCORRECT mode). Two seconds after the parity check started it indicated that there were three sync issues. The entire log is attched but the relevant part is as follows:

 

Feb  1 00:00:01 Tower kernel: mdcmd (146): check NOCORRECT

Feb  1 00:00:01 Tower kernel:

Feb  1 00:00:01 Tower kernel: md: recovery thread woken up ...

Feb  1 00:00:01 Tower kernel: md: recovery thread checking parity...

Feb  1 00:00:01 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks.

Feb  1 00:00:02 Tower kernel: md: parity incorrect: 13912

Feb  1 00:00:02 Tower kernel: md: parity incorrect: 13920

Feb  1 00:00:02 Tower kernel: md: parity incorrect: 13928

 

I've read a few posts that indicated that errors this early in the process are often in something called the housekeeping area (this thread in particular - http://lime-technology.com/forum/index.php?topic=16997.msg154772#msg154772 - though I confess to not understanding much of that thread.)

 

What I CAN report is that, since my last monthly parity check, which reported no errors, I had a disk failure (about four days ago in fact.) I rebuilt that failed drive with a hot spare of the same size that I had on hand. All went well in that operation and my system has been functioning smoothly since that time. I use a cache drive, so I'm pretty confident that at the time the disk failed nothing was being written to it as it was only a few hours after the mover script had executed without problem, and many hours before it would execute the mover script again.

 

Assuming the rest of the parity check goes smoothly (it is currently 20% complete with no additional issues) and it completes with just those three errors, can someone suggest what I should do to proceed. From what I gather errors in this housekeeping area (if that is, in fact, where they are) are relatively harmless, but I assume I still need to clear them. Is that best done by running an entire new parity check with the CORRECT option, or is there some other procedure I should follow?

 

Thanks for any advice.

 

syslog-2012-02-01.zip

Sorry to reply to my own post, but I have now completed the partity check discussed above without any additional errors.

 

I am left with three sync errors that occured at the very beginning of the parity check. I could really use some advice on how to proceed at this point as I'd rather not do something I'll come to regret.

 

Thanks for any help.

I assume I still need to clear them. (the errors)

Is that best done by running an entire new parity check with the CORRECT option,

Yes

or is there some other procedure I should follow?

no.  A correcting parity check is how to proceed.

Ok. Thanks. I have just begun and the same three errors are being reported:

 

Feb  1 10:17:33 Tower kernel: mdcmd (158): check CORRECT (unRAID engine)

Feb  1 10:17:33 Tower kernel: md: recovery thread woken up ... (unRAID engine)

Feb  1 10:17:33 Tower kernel: md: recovery thread checking parity... (unRAID engine)

Feb  1 10:17:33 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks. (unRAID engine)

Feb  1 10:17:43 Tower kernel: md: parity incorrect: 13912 (Errors)

Feb  1 10:17:43 Tower kernel: md: parity incorrect: 13920 (Errors)

Feb  1 10:17:43 Tower kernel: md: parity incorrect: 13928 (Errors)

 

 

I presume, since I am using the CORRECT option, these will be corrected at some point during the process and reported in the log. Is that right?

Yes, the error log could be made clearer.  If you want to prove to yourself that the errors have been corrected just do another no correct run after this one completes and it should show no errors.

 

Regards,

 

Stephen

I've just encountered this identical situation on 4.7 (right down to the disk failure about a month ago and the number of sync errors reported on the non-correcting parity check), but my complete var/log/syslog reads only as follows:

 

May 15 04:40:01 Tower syslogd 1.4.1: restart.

May 15 08:06:54 Tower kernel: md: sync done. time=33742sec rate=57895K/sec (unRAID engine)

May 15 08:06:54 Tower kernel: md: recovery thread sync completion status: 0 (unRAID engine)

May 15 08:26:36 Tower kernel: NTFS driver 2.1.29 [Flags: R/O MODULE]. (System)

 

GENERALLY, it sounds like this is nothing to be worried about, but I've seen a couple of similar threads dealing with these "housekeeping" few-error type situations where memory tests and reiser file system checking are recommended. 

 

In light of the tiny syslog, is there any easy way to determine whether I should simply go with the "correct parity" option and write these off as "housekeeping," non-data-related errors OR do some more detailed checking (or is there a way to dig back further into the syslog history - or is that even necessary at this point?).

Did you perform a parity check following the rebuild?

I could swear that I did, but there's definitely a chance that I didn't (just checked drive purchase date, and it seems like my last parity check date was after that).  Are you thinking it could be that rebuild bug related to writes?  I'm pretty positive nothing would have been written to the array during that rebuild (I'm the only one using the system)...  Thanks, dgaschk!

There is a known issue in 4.7 where a few parity errors can occur after a rebuild (typically less than 6 near the beginning of the disk). The solution is to check parity after rebuild and correct the errors.