January 29, 201115 yr "Parity is Valid:. Last parity check 1 day ago . Parity updated 66 times to address sync errors." Yet during parity check there were no errors according to log: Jan 27 21:38:26 Tower kernel: mdcmd (60): check NOCORRECT Jan 27 21:38:26 Tower kernel: Jan 27 21:38:26 Tower kernel: md: recovery thread woken up ... Jan 27 21:38:26 Tower kernel: md: recovery thread checking parity... Jan 27 21:38:26 Tower kernel: md: using 1152k window, over a total of 976762552 blocks. Jan 28 01:01:15 Tower kernel: mdcmd (1478): spindown 1 Jan 28 01:01:15 Tower kernel: mdcmd (1479): spindown 2 Jan 28 01:36:46 Tower kernel: md: sync done. time=14299sec rate=68309K/sec Jan 28 01:36:46 Tower kernel: md: recovery thread sync completion status: 0 Jan 28 01:51:49 Tower kernel: mdcmd (1833): spindown 0 Am I missing something?
January 29, 201115 yr "Parity is Valid:. Last parity check 1 day ago . Parity updated 66 times to address sync errors." Yet during parity check there were no errors according to log: Jan 27 21:38:26 Tower kernel: mdcmd (60): check NOCORRECT Jan 27 21:38:26 Tower kernel: Jan 27 21:38:26 Tower kernel: md: recovery thread woken up ... Jan 27 21:38:26 Tower kernel: md: recovery thread checking parity... Jan 27 21:38:26 Tower kernel: md: using 1152k window, over a total of 976762552 blocks. Jan 28 01:01:15 Tower kernel: mdcmd (1478): spindown 1 Jan 28 01:01:15 Tower kernel: mdcmd (1479): spindown 2 Jan 28 01:36:46 Tower kernel: md: sync done. time=14299sec rate=68309K/sec Jan 28 01:36:46 Tower kernel: md: recovery thread sync completion status: 0 Jan 28 01:51:49 Tower kernel: mdcmd (1833): spindown 0 Am I missing something? It means there are 66 parity errors. (and despite what the message said, since you ran in NOCORRECT mode, they still exist. Parity was not updated.) The user-interface always assumes it corrected the errors since it has never been coded to recognize a read-only NOCORRECT check. The message should have said something like: Number of parity sync errors detected: 66 It usually means you had a shutdown where you did not stop the array first. It might mean flaky RAM or a flaky disk. In the syslog will be the address of the first 20 parity errors. Run another NOCORRECT parity check. If the same 20 addresses appear, then you are not getting random errors and and probably just run a normal check and correct parity check. (the Check button on the unRAID web-page) If different addresses, well. let's just say it could be your RAM, or one of your disks, or your motherboard chipset. All you need to do is figure out which. Joe L.
January 29, 201115 yr Author Joe, I've attached entire syslog. I can't see any errors. Perhaps I'm not looking at the right places? My wife actually restarted unRaid by just cycling power on server, without stopping array first. I since performed two NOCORRECT parity checks and both times it came back with those 66 errors that I can not find in syslog. Thanks for you help. syslog-2011-01-29.txt
January 29, 201115 yr First, you should install the powerdown addon package to deal with the power cycling wife.
January 29, 201115 yr The logging of the specific addresses did not exist in your older version of unRAID. (Counting the beta versions, 4.5.4 is about 13 releases old. unRAID is now on release 4.7) Just perform a normal parity "Check" by pressing the button on the management console. And consider upgrading. There have been a number of things fixed since 4.5.4, and a number of enhancements too. See the release notes here: http://lime-technology.com/wiki/index.php?title=Release_Notes
Archived
This topic is now archived and is closed to further replies.