[SOLVED] Parity found 81 errors

[gyrene2083]

Good evening all,

 

I been using UNRaid for some time now, and this is the first time, I have gotten 81 errors. I ran the parity with write corrections checked, and I have no idea what exactly I'm supposed to be looking at in the log files. So, I am uploading my diagnostics in hopes that someone with more experience can eyeball it and tell me what can I do to square that away.

 

I appreciate all your help in advance.

jiraiya-diagnostics-20200510-2110.zip

[trurl]

A lot of this in syslog but it was a couple of weeks ago:

Apr 25 19:46:52 Jiraiya root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token
Apr 25 19:46:52 Jiraiya root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token
Apr 25 19:46:53 Jiraiya root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token
Apr 25 19:46:54 Jiraiya root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token

Just FYI here is the FAQ on that:

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=545988

 

 

Was this a scheduled check or did you start it yourself? If you did start it yourself, why did you want to run a parity check? Do you normally run a correcting parity check?

 

Always recommend another parity check to confirm no parity errors still detected. Sometimes problems like bad RAM can give inconsistent results.

 

 

[gyrene2083]

Thank you @trurl for eyeball the logs. I did start the check myself, as there were 44 days I think that it wasn't checked. I thought I scheduled a monthly check but apparently, I didn't.

 

I can't say for certain if I normally run a correcting parity or not normally. I am going to do what you said, and run another parity, should I run it with the corrections checked? A few days ago the power went out a few times in the middle of the night, but I didn't think anything of it when I woke up because the server is on it's own UPS.

 

I suppose I need to configure the UPS and Server to do a clean shutdown when the UPS is activated, on power outages. What are your thoughts?

[trurl]

You don't want to run very long on UPS before shutting down since you don't want to start back up with a low UPS battery.

 

But your syslog goes back a couple of weeks so your UPS must have kept your server up. I didn't notice any UPS messages in syslog, does it have a data connection?

 

A non-correcting parity check after a correcting parity check is the way to go since if there are still parity errors they may have some other cause than the actual parity data so correcting them doesn't really help anything.

 

That is also a good reason to run non-correcting parity checks normally, since you expect to have zero errors, and if you don't you might like to investigate some other cause before you actually correct them.

[gyrene2083]

Thank you so much @trurl. I started the non-correcting parity check, and scheduled an monthly non-correcting parity check.

 

I do have a data connection on the UPS, I just didn't get around to setting it up. It's a rack-mount APC SMT1500RM2U. I need to work on setting that up this week.

 

Lastly, if you don't mind me asking, what exactly did you look for in the logs. I ask only because, I want to learn for one, but secondly ensure I have exhausted all means on my end before I post something. <I learned I need to run parity twice, to rule out any anomalies for one>

[Frank1940]

8 hours ago, gyrene2083 said:

<I learned I need to run parity twice, to rule out any anomalies for one>

You only need to run a second parity check if you are having problems.  Many folks run a non-correcting monthly parity check.  If you have an 'unclean' shutdown (power failure, system crash), a correcting parity check will result on restart.  (Apparently, there is a bit of housecleaning housekeeping that occurs on a 'clean' shutdown.)  An unclean shutdown can (apparently) cause Parity to get out of sync.  (I say Parity because I have never heard of anyone finding a data error after such an event where there are only few parity errors.)

 

After such an event where only a few parity errors are found, many folks run a non-correcting check just as a double check (that check should find no errors) to make sure that was the cause of the errors and to provide confirmation that there isn't some other problem.

Edited May 11, 2020 by Frank1940

[trurl]

11 hours ago, gyrene2083 said:

what exactly did you look for in the logs

syslog is in the logs folder of those diagnostics you posted. The csrf errors I posted earlier are an excerpt, and your parity error corrections can be seen near the end of that syslog. Other than that I was just going on your description and making the usual recommendation for when parity needs correction.