millions of sync errors corrected during scheduled parity check

[Frankthetank907]

I have been running unraid for a few years now, never have I ever had any errors detected when doing a parity check until now. As you can see from the screen shots I have attached it appears as if the automatic parity check is also writing corrections to parity, which I am confused by because I have always had the option for it to automatically write corrections to parity during scheduled checks deselected. I am running Unraid version 6.12.6 as of 4 days ago, I have also attached the diagnostics file for troubleshooting, if anyone can help me understand what is going on it would be greatly appreciated. Thanks for any help in advance. 

 

 

 

 

tower-diagnostics-20231205-2317.zip

Edited December 6, 2023 by Frankthetank907
deleted a duplicate diagnostics file

[Frankthetank907]

I forgot to mention, during the parity check (which is still running) I do have all of my docker containers running and doing their normal tasks, I am not sure if this could have somehow caused a sync error between the disks and parity, but I have never hand an issue with it in the past.

[itimpi]

It looks as if the system incorrectly started a correcting check:

Dec  4 03:00:01 Tower kernel: mdcmd (36): check 
Dec  4 03:00:01 Tower kernel: md: recovery thread: check P Q ...

and then later found errors on parity1.    I will try running a test to see if I can replicate the incorrect starting of a correcting check on my system in case it is a new bug in the 6.12.6 release.  However why errors were found I have no idea.   The fact that docker containers were running should be irrelevant.

 

BTW:  With such large parity disks you may find it advantageous to install my Parity Check Tuning plugin?  Even if you do not use all its features the fact that it adds to the Parity check history entries whether a check was correcting or not may be useful information.

[Frankthetank907]

1 hour ago, itimpi said:

It looks as if the system incorrectly started a correcting check:

Dec  4 03:00:01 Tower kernel: mdcmd (36): check 
Dec  4 03:00:01 Tower kernel: md: recovery thread: check P Q ...

and then later found errors on parity1.    I will try running a test to see if I can replicate the incorrect starting of a correcting check on my system in case it is a new bug in the 6.12.6 release.  However why errors were found I have no idea.   The fact that docker containers were running should be irrelevant.

 

BTW:  With such large parity disks you may find it advantageous to install my Parity Check Tuning plugin?  Even if you do not use all its features the fact that it adds to the Parity check history entries whether a check was correcting or not may be useful information.

Interesting, like I said in my original post this is the first time it has ever done something like this, and I did just update to the 6.12.6 release so maybe it is a new bug, or it could be a coincidence too but I am not going to pretend that I know what I am talking about when it comes to how the underlying system actually works lol. Will be interesting to see if you or anyone else is able to replicate this issue.

 

Also thanks for letting me know about your plugin, I will install it after this parity check finishes for sure. Looking forward to see if you are able to come up with anything on your system, and thanks for looking into the logs and helping out, I have no idea what I am looking at when I was sifting through them lol.

[JorgeB]

By any chance did you do a parity swap recently?

[Frankthetank907]

50 minutes ago, JorgeB said:

By any chance did you do a parity swap recently?

I did do one back in October when I swapped an older 8TB parity drive out with another 18TB WD red pro, why?

[JorgeB]

There's a known bug with that, it can cause sync errors for the new parity capacity, after the 8TB mark in this case, if this is the first check after that just correct the errors.

[Frankthetank907]

37 minutes ago, JorgeB said:

There's a known bug with that, it can cause sync errors for the new parity capacity, after the 8TB mark in this case, if this is the first check after that just correct the errors.

interesting, that is good to know, that would explain all the errors it is picking up, thanks for that info! Still would like to figure out why it decided to automatically write corrections to parity even with that option not being selected in the settings though, that could potentially be very problematic if there was some sort of corruption on the array.

[itimpi]

11 hours ago, Frankthetank907 said:

Still would like to figure out why it decided to automatically write corrections to parity even with that option not being selected in the settings though, that could potentially be very problematic if there was some sort of corruption on the array.

I did some testing today on the 6.12.6 release and in all cases the type of check was what had been set under the scheduler settings, so not sure why you seemed to get something different.