Monthly parity check fixed 333 sync issues - how to investigate?

[ctrlbreak]

Hi all,

 

Long time user and mostly lurker in the forums, have self-served most issues I've had including dirty shutdowns, weird upgrades, HDD replacements and data loss issues in the past.

 

But... this seems quite a vanilla question, but I'm not sure how to investigate what/if this issue is something I should be concerned about?

 

My monthly parity check just completed and found/fixed 333 errors. Server has been up for 55 days and the previous check was 0 errors.

 

Where do I start to investigate if this is a significant issue worth more investigation?

 

Diagnostics attached, and thanks in advance!

 

Patrick

bigboi-diagnostics-20200908-1307.zip

[JorgeB]

Run a non correcting check now and post the diags if there are more errors.

[ctrlbreak]

Non-correcting check ran fine, 0 errors. Diagnostics attached in any case.

bigboi-diagnostics-20200910-1343.zip

[trurl]

I thought perhaps looking back in syslog to boot would reveal if you had unclean shutdown, but unfortunately boot time is not in the syslogs in diagnostics because your syslog is being spammed with these:

Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [0E59246677B6\064Attic\032SB\032Touch._raop._tcp.local#011IN#011SRV 0 0 40781 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping.
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2.local#011IN#011A 192.168.0.3 ; ttl=120] not fitting in legacy unicast packet, dropping.
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [ABA7EBC51E26\064Kitchen\032SB\032Touch._raop._tcp.local#011IN#011TXT "42351" "tp=UDP" "sm=false" "sv=false" "ek=1" "et=0,1" "md=0,1,2" "cn=0,1" "ch=2" "ss=16" "sr=44100" "pw=false" "vn=3" "txtvers=1" "am=shairtunes2" ; ttl=4500] not fitting in legacy un
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [ABA7EBC51E26\064Kitchen\032SB\032Touch._raop._tcp.local#011IN#011SRV 0 0 42351 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping.
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [_afpovertcp._tcp.local#011IN#011PTR bigboi-2-AFP._afpovertcp._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping.
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2-AFP._afpovertcp._tcp.local#011IN#011TXT  ; ttl=4500] not fitting in legacy unicast packet, dropping.
Sep  9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2-AFP._afpovertcp._tcp.local#011IN#011SRV 0 0 548 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Any idea what that's about? It would make it difficult to figure out any other problems you might have.

[JorgeB]

38 minutes ago, ctrlbreak said:

Non-correcting check ran fine, 0 errors.

Then most likely previous sync errors were the result of an unclean shutdown.

[ctrlbreak]

(delayed reply here, thanks for bearing with me!).

 

The thing is, had been up for 57 days, completed a previous parity check with 0 errors since shutdown. Definitely no unclean shutdown since last good check. Could it be dodgy cabling/SATA crc-type errors causing this?

 

My main question was how/if I could investigate in more detail as I don't seem to have logs that go back far enough in any case.

 

The more principled issue is - in this case is correcting or non-correcting the right thing to do? That is, is it the data on parity disks that's wrong or the data disk(s). I guess having dual parity makes it less likely to be the parity disks?

[trurl]

Unless you have some reason to suspect some specific data disk you have no choice but to correct parity. For example, sync errors after a data disk rebuild in which there were errors on one or more disks would be a reason to suspect the rebuilt disk was out-of-sync instead of parity.