My new unraid server did it's first monthly parity check using the month_parity_check package. I used the NOCORRECT option when installing the package. The parity check said that it found 6 errors but the funny thing is that the unmenu console is reporting:

 

STARTED, 6 disks in array.    Parity is Valid:.  Last parity check < 1 day ago .  Parity updated 6 times to address sync errors. 

 

Did it actually update the parity 6 times even though I used the NOCORRECT option? Or is the unmenu console unable to determine that the parity wasn't updated?

 

If it didn't update the parity, is there anyway to update the parity without running a complete check again? Or do I have to use the "Check" button on the main unraid menu? The relevant lines from syslog are:

 

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930275568

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930276080

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930276592

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907027568

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907028080

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907028592

 

Thanks for any help,

ron

 

 

Did it actually update the parity 6 times even though I used the NOCORRECT option? Or is the unmenu console unable to determine that the parity wasn't updated?

 

If it didn't update the parity, is there anyway to update the parity without running a complete check again? Or do I have to use the "Check" button on the main unraid menu?

 

 

1) The parity check didn't updated your parity data, and the check was made by the MD driver itself, unmenu only display the information parsed by the driver.

 

It's important to know why these errors appeared, because it can be an early indicator of a failing disk. You should look at the SMART status report of the disk for reallocated sectors. If the SMART status is clean, these errors are probably resultant of unclean array stoppage or a power outage. In this case, is save to run the parity check again with CORRECT option.

 

2) To synchronize the parity data, the easiest way is launching it from the unRAID WebUI.

 

Did it actually update the parity 6 times even though I used the NOCORRECT option? Or is the unmenu console unable to determine that the parity wasn't updated?

The unRAID "md" driver does not differentiate the output when actually correcting the parity vs. when in NOCORRECT mode.  the display looks identical in unRAID, or in unMENU, as there is no way to tell them apart. 

 

If you used the "Verify Parity" button in unMENU or scheduled a monthly NOCORRECT check, then no changes were made.

 

The unRAID console was never uppdated by lime-tech to change the output display when in NOCORRECT mode.  It is misleading you.

My new unraid server did it's first monthly parity check using the month_parity_check package. I used the NOCORRECT option when installing the package. The parity check said that it found 6 errors but the funny thing is that the unmenu console is reporting:

 

STARTED, 6 disks in array.    Parity is Valid:.   Last parity check < 1 day ago .   Parity updated 6 times to address sync errors.   

 

Did it actually update the parity 6 times even though I used the NOCORRECT option? Or is the unmenu console unable to determine that the parity wasn't updated?

 

If it didn't update the parity, is there anyway to update the parity without running a complete check again? Or do I have to use the "Check" button on the main unraid menu? The relevant lines from syslog are:

 

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930275568

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930276080

Nov 1 15:05:45 Unraid kernel: md: parity incorrect: 2930276592

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907027568

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907028080

Nov 1 17:19:35 Unraid kernel: md: parity incorrect: 3907028592

 

Thanks for any help,

ron

 

 

When run with the NOCORRECT option these errors are only detected and not corrected - its just the output that is misleading.

 

At this point you should run a second parity check again with the NOCORRECT option to see if these errors still show up and have the same block numbers.  If they do reappear then running a regular parity check with correct pass should fix them (and the output will show this).

 

There is a chance that when you run a second check with NOCORRECT that some or all of these errors will actually disappear.  This has been happening to me for some time and I've been gradually changing components to try to find out what the cause is.

 

Regards,

 

Stephen