December 6, 20169 yr After 1st parity check, i hit 2 errors. Alert in itself doesn't tell me much about what is bad. Parity or Data and no clue on how to fix it. Can someone advice on what to do next? Event: unRAID Parity check Subject: Notice [MYLAB] - Parity check finished (2 errors) Description: Duration: 9 hours, 54 minutes, 45 seconds. Average speed: 168.2 MB/s Importance: warning
December 6, 20169 yr Post diagnostics. Did you have an unclean shutdown? That can often cause a few parity errors. In general the only thing you can do is correct parity because that is where the error is most likely to be and there is no way to determine which other disk might be in error anyway.
December 6, 20169 yr Author Interesting additional information. My array check shows healthy state for all 8 drives. 3(Data)+1(Parity)= Data_Pool 4 SSD = Cache_pool Does that mean data is good and only parity is bad? I am newbie to unraid and still on day_10 of my trial period. If you could help me understand next step, I would appreciate.
December 6, 20169 yr Post diagnostics. Go to Tools - Diagnostics and attach the complete diagnostics zip to your next post.
December 6, 20169 yr Author Please find diagnostic file attached. mylab-diagnostics-20161206-1426.zip
December 6, 20169 yr SMART for all array drives looks OK, and the current syslog doesn't say anything about an unclean shutdown. Perhaps there was one in the past. Syslog also says it was a correcting parity check so the parity errors should have been corrected. I would do another parity check just to make sure everything is OK. There is actually no way to say for sure whether data or parity was at fault. All it can tell us is that the parity calculation from the data did not match parity.
December 6, 20169 yr I see you have a Marvell SATA controller 0a:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller [1b4b:9230] (rev 11) and you also have IOMMU enabled. Could it be some form of the Marvell bug? I'd try the workaround or turning off IOMMU, at least as a test.
December 7, 20169 yr Author John_M: When I had setup parity disk, I had IOMMU disabled. After that when I wanted to go about creating VMs, I had turn IOMMU thinking I would be able to use vt-d some time later. However, given unRaid needs direct access to disk, and I do not have any to give away to VM, it makes perfect sense to have it disabled. So, I just turned it off. trurl : After mover is done executing itself, tonight I would start parity check once again and will post you result tomorrow late afternoon. Once again, thank you for quick response. I feel welcome and at home in unRaid community.
December 7, 20169 yr Your problem isn't exactly the one that RobJ wrote about in the thread I linked to but one or two people, while not seeing disks go missing, have noticed unaccountable and rather subtle parity errors, myself included, when using Marvell-based controllers with IOMMU enabled. So it looks as though it might possibly be another manifestation of the same problem. See how you get on and please report back with any news, good or bad
December 7, 20169 yr Author I think you were right, it could have been result of IMMOU with Marvel controller. "Last check completed on Wed 07 Dec 2016 12:50:45 PM EST (today), finding 0 errors. Duration: 9 hours, 54 minutes, 33 seconds. Average speed: 168.2 MB/sec" I disabled it and re-ran parity check and this time around it came back healthy.
December 7, 20169 yr Well, that's encouraging. I suggest you use your server as you normally would and run another parity check in a few days time. If you wouldn't mind reporting back then, it's all useful information.
Archived
This topic is now archived and is closed to further replies.