February 4, 20224 yr Hey Guys, I woke up to an email that said I have two errors during the parity check but I cant figure or see those error. Can someone take a glance and see if they see any concerning issues on my server? I would rather ask now versus wait when something breaks. Help This is the email I got: Event: Unraid Parity check Subject: Notice [TOWER] - Parity check finished (2 errors) Description: Duration: 21 hours, 29 minutes, 19 seconds. Average speed: 103.4 MB/s Importance: warning tower-diagnostics-20220203-1631.zip
February 4, 20224 yr Community Expert Your syslog is mostly these over and over again every minute Feb 3 16:27:47 Tower avahi-daemon[10567]: Withdrawing address record for fe80::dc03:4cff:fe8d:830a on veth5cc4a99. Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered blocking state Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered disabled state Feb 3 16:28:47 Tower kernel: device vethae9167d entered promiscuous mode Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered blocking state Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered forwarding state Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered disabled state Feb 3 16:28:47 Tower kernel: eth0: renamed from veth8627a76 Feb 3 16:28:47 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethae9167d: link becomes ready Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered blocking state Feb 3 16:28:47 Tower kernel: docker0: port 2(vethae9167d) entered forwarding state Feb 3 16:28:48 Tower avahi-daemon[10567]: Joining mDNS multicast group on interface vethae9167d.IPv6 with address fe80::ac77:f9ff:feeb:3e86. Feb 3 16:28:48 Tower avahi-daemon[10567]: New relevant interface vethae9167d.IPv6 for mDNS. Feb 3 16:28:48 Tower avahi-daemon[10567]: Registering new address record for fe80::ac77:f9ff:feeb:3e86 on vethae9167d.*. Feb 3 16:28:51 Tower kernel: docker0: port 2(vethae9167d) entered disabled state Feb 3 16:28:51 Tower kernel: veth8627a76: renamed from eth0 Feb 3 16:28:51 Tower avahi-daemon[10567]: Interface vethae9167d.IPv6 no longer relevant for mDNS. Feb 3 16:28:51 Tower avahi-daemon[10567]: Leaving mDNS multicast group on interface vethae9167d.IPv6 with address fe80::ac77:f9ff:feeb:3e86. Feb 3 16:28:51 Tower kernel: docker0: port 2(vethae9167d) entered disabled state Feb 3 16:28:51 Tower kernel: device vethae9167d left promiscuous mode Feb 3 16:28:51 Tower kernel: docker0: port 2(vethae9167d) entered disabled state Feb 3 16:28:51 Tower avahi-daemon[10567]: Withdrawing address record for fe80::ac77:f9ff:feeb:3e86 on vethae9167d. Any idea what that is all about?
February 4, 20224 yr Author 1 hour ago, trurl said: When did this parity check finish? So the parity check finished at 9 PM last night Pacific standard Time. Total run time was 21 hours
February 4, 20224 yr Search your syslog file for "recovery thread". It'll list block numbers that failed. Issue is you really don't know which drive the fail came from. I recently run into this issue with one of my drives and currently adding support to the version 3.0 of DiskSpeed to search your drives to find what files occupy that spot on all of the drives for further checking. If you have 3+ errors (I had 100+), look for a pattern such as 1,4,8,12 where it skips 3 or some number each time - that's a sign that one side of a platter is failing. It could be on your data drives, it could be on your parity drive. I'd also recommend getting the "Dynamix File Integrity" plugin.
February 4, 20224 yr Community Expert Feb 2 07:53:36 Tower kernel: md: recovery thread: P corrected, sector=6442451024 Feb 2 07:53:36 Tower kernel: md: recovery thread: P corrected, sector=6442451032 Since this was a correcting check, you should run a non-correcting check to confirm there a no parity errors.
February 4, 20224 yr Author 4 hours ago, trurl said: Feb 2 07:53:36 Tower kernel: md: recovery thread: P corrected, sector=6442451024 Feb 2 07:53:36 Tower kernel: md: recovery thread: P corrected, sector=6442451032 Since this was a correcting check, you should run a non-correcting check to confirm there a no parity errors. Is this how to run a "non-correcting check" ... I unchecked this box and then do I run check to see if any error appears...right? Edited February 4, 20224 yr by BDLR
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.