Frankthetank907 Posted December 6, 2023 Share Posted December 6, 2023 (edited) 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 Quote Link to comment
Frankthetank907 Posted December 6, 2023 Author Share Posted December 6, 2023 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. Quote Link to comment
itimpi Posted December 6, 2023 Share Posted December 6, 2023 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. Quote Link to comment
Frankthetank907 Posted December 6, 2023 Author Share Posted December 6, 2023 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. Quote Link to comment
JorgeB Posted December 6, 2023 Share Posted December 6, 2023 By any chance did you do a parity swap recently? Quote Link to comment
Frankthetank907 Posted December 6, 2023 Author Share Posted December 6, 2023 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? Quote Link to comment
JorgeB Posted December 6, 2023 Share Posted December 6, 2023 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. Quote Link to comment
Frankthetank907 Posted December 6, 2023 Author Share Posted December 6, 2023 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. Quote Link to comment
itimpi Posted December 6, 2023 Share Posted December 6, 2023 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.