2 Disk Parity Check went from 0 to 6 errors in one week.

[RealActorRob]

Dual disk parity.

 

I had correcting selected in the scheduler section for Parity Check.

 

Diagnostics attached but I'll look at them shortly but jump in.

 

NO disks have errors on the Main screen (all zeroes) and Smart data is all thumbs up.

 

So, do I have an issue? Seems like a small one, if so.

 

Running another check now, NON correcting. 

 

blacktower-diagnostics-20210502-1804.zip

[RealActorRob]

Disk 5 has 199 UDMA_CRC_Error_Count    -O--CK   200   200   000    -    30

 

No pending sectors that I saw.

 

Array has not been shut down (19 day uptime) so the error count on the main screen is accurate (0).

 

Sooo....what now?

 

Edited May 2, 2021 by RealActorRob

[RealActorRob]

I turned off 'write corrections to disk' in the scheduled now.

 

Of course, I don't know what to suspect, since I have zero errors in Main, Pending Sectors, or SMART thumbs down...

 

Is there a log or is this just that time when a cosmic particle hit my parity disks and the data on the data drives is fine?

 

[RealActorRob]

I found this in the syslog, but doesn't help me much...matches the '6' count but how do I tell what disk these are on?

 

 

May  2 00:03:34 BlackTower kernel: md: recovery thread: Q corrected, sector=32757816
May  2 00:12:46 BlackTower kernel: md: recovery thread: Q corrected, sector=125990984
May  2 00:20:01 BlackTower sSMTP[20691]: Creating SSL connection to host
May  2 00:20:01 BlackTower sSMTP[20691]: SSL connection using TLS_AES_256_GCM_SHA384
May  2 00:20:04 BlackTower sSMTP[20691]: Sent mail for [email protected] (221 2.0.0 closing connection i130sm2031438oif.49 - gsmtp) uid=0 username=xxx outbytes=1450
May  2 00:24:26 BlackTower kernel: md: recovery thread: Q corrected, sector=245737984
May  2 00:37:02 BlackTower kernel: md: recovery thread: Q corrected, sector=374158856
May  2 00:37:04 BlackTower kernel: md: recovery thread: Q corrected, sector=374658440
May  2 01:41:48 BlackTower kernel: md: recovery thread: Q corrected, sector=977077048

 

 

[RealActorRob]

As I continue to research....hopefully this helps someone else:

 

P is parity in the array and Q is parity 2 I presume?

 

So, if Parity had no errors, and only 6 errors corrected on Parity 2, then I guess just monitor the situation? Absent of anything else? 

 

Theories as to what would cause errors only on Parity 1 and not Parity 2?

 

Assuming I'm reading this correctly?

 

Minor note...KINDA feel like Parity should be named Parity 1 if you have a Parity 2....TBC.

 

 

 

[BRiT]

P and Q are the long standing names from the existing Mathematical Realm Algorithms for parity protection.

[John_M]

A memory test might be a good place to start.

[RealActorRob]

On 5/2/2021 at 9:06 PM, John_M said:

A memory test might be a good place to start.

ECC. Dell T310H....have to see if there's a way to view status of the chips on Unraid...do you know it?

 

Recheck of parity passed 0 errors.

 

[RealActorRob]

Recheck said 0 errors but was not present in the history button.

 

Is this normal if you don't write corrections? Running another one.

 

Edited May 4, 2021 by RealActorRob

[itimpi]

8 hours ago, RealActorRob said:

Is this normal if you don't write corrections? Running another one.

 

No.  All checks that come to a controlled ending should end with entries in the history file.   The only time I can think of where this might not be true if if an unclean shutdown happened in the middle of the check.

 

It might be worth pointing out that if you have the Parity Check Tuning plugin installed then the history entries will contain additional information over those generated as standard by Unraid even if you are not using the plugin to run the check in increments.

[RealActorRob]

I swapped the disk out for another one and no problems noted since.