[6.9.2] Correct parity checkbox ignored

You have linked to a thread from a very old (pre V6) version of Unraid.

 

Maybe there isn't really a bug, just some misunderstanding, but you haven't told us much.

 

Were you trying to run a correcting parity check and it didn't seem to correct the errors?

 

Or were you trying to run a non-correcting parity check and it corrected parity errors anyway?

 

As with all "bug reports" you need to provide your diagnostics and other information as explained in the Report Guidlines:

 

 

I was trying to check the parity without correcting erros.

 

Steps to reproduce:
1. Start the array
2. Without navigating to other pages uncheck "Write corrections to parity"
3. Start parity check
Parity check starts with correction enabled.
Log: "unraid kernel: mdcmd (36): check" and also "unraid kernel: md: recovery thread: Q corrected, sector=40408xxxxx"

I'll try to provide more info (diagnostics also) but right now I'm in the middle of moving some data around.

Edited January 8, 2022 by daxxx
Added more info

6 minutes ago, daxxx said:

Log: "unraid kernel: mdcmd (36): check" and also "unraid kernel: md: recovery thread: Q corrected, sector=40408xxxxx"

Cancel the check and re-run it.  Is the same line being logged?  If it is then it's worded slightly wrong, but it is a non-correcting check.

All subsequent runs log: "unraid kernel: mdcmd (50): check nocorrect". But then when I stop the array and start again it's correcting.

Confirmed.  The key is don't navigate away from the page after starting

Just tried once again and even after navigating to Shares and back to Main caused that checkbox to be ignored. Log:
 

Jan  8 22:29:11 unraid kernel: mdcmd (38): check 
Jan  8 22:29:11 unraid kernel: md: recovery thread: check P Q ...
Jan  8 22:29:32 unraid kernel: mdcmd (39): nocheck Cancel
Jan  8 22:29:32 unraid kernel: md: recovery thread: exit status: -4
Jan  8 22:29:39 unraid kernel: mdcmd (40): check nocorrect
Jan  8 22:29:39 unraid kernel: md: recovery thread: check P Q ...

 

Seems like every first check is correcting.

This bug has already been reported:

 

 

That's awersome, but when it will be fixed? It can lead to major data loss if one of the disks is returning random data. And user can't prevent it after reboot/array restart. 

 

It's not minor, it should be urgent.

Changed Status to Open

Changed Priority to Urgent