ctrlbreak Posted September 8, 2020 Share Posted September 8, 2020 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 Quote Link to comment
JorgeB Posted September 8, 2020 Share Posted September 8, 2020 Run a non correcting check now and post the diags if there are more errors. Quote Link to comment
ctrlbreak Posted September 10, 2020 Author Share Posted September 10, 2020 Non-correcting check ran fine, 0 errors. Diagnostics attached in any case. bigboi-diagnostics-20200910-1343.zip Quote Link to comment
trurl Posted September 10, 2020 Share Posted September 10, 2020 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. Quote Link to comment
JorgeB Posted September 10, 2020 Share Posted September 10, 2020 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. Quote Link to comment
ctrlbreak Posted September 27, 2020 Author Share Posted September 27, 2020 (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? Quote Link to comment
trurl Posted September 28, 2020 Share Posted September 28, 2020 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. 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.