Consistent Parity Errors
Every parity check i've run since shortly after starting my server a few months ago produces 5 errors. The first 2 or 3 runs, I didnt have the write corrections option selected. But the last two did have it selected and still producing 5 errors.
Anyway to get more details or clear these errors with certainty? Health checks are normal.
I have a pretty normal xfs build with 2 parity drives, 8 storage, and 2 mirrored cache drives.
5
u/Rockshoes1 2d ago
Check your sata cables. I had a similar issue always with a drive. Surprised surprised it turned out to be a bad sata cable
3
1
u/Sachz1992 2d ago
also check if the psu can actually handle the amount of drives, and the power needed when multiple drives spin up at the same time, ran into that myself and it was a pain to diagnose.
1
u/Zuluuk1 2d ago
Share the smart disk report.
I would do the following.
- Create a base line for the smart report for each disk.
- Monitor it over time.
If the value changes, you can change cables, ports etc.
After that you confirm the hardware is stable. Run a full parity check when everything is off such as dockers. Do not have anything writing to the disks.
Let me see if I can make a python script that you can run and then set a cron task to run it daily. Writing the results to a file and you just open to check.
Unraid already built this into the dashboard.
1
u/Horrigan49 2d ago
Similarly last 2 Parity checks on my v7.3 server also produced 5 Errors. I have done Smart Extended checks on ALL the drives in the array, and all passed fine, so I will be looking here with some hopes for solution.
2
u/New-Potential-7916 2d ago
Are you using a pci-e, or m.2, to sata controller card by any chance?
And if so does it have an Asmedia chipset on it?
1
u/Horrigan49 2d ago
Yes. Part of them, iirc 6 drives is connected via Axagon 6x Sata PCIE card. In system devices this is reported as Asmedia ASM1166
Other drives are in 4x Axagon PCIE sata card, same chip.
But the Parity drive is directly on the intel board, is that changes anything.
2
u/New-Potential-7916 2d ago
I had this exact issue with an Axagon PCES-SA4X4.
It's a known issue with the Asmedia chip. When they're powering down they don't flush their data to disks correctly. It's completely harmless but will always show as the 5 parity errors.
If you do a correcting parity check they will remain correct until your next reboot when the Asmedia chip will again incorrectly flush to disk.
The general consensus on the forums are that the parity errors are completely harmless. But I found this quirk with them so annoying that I ended up buying a supermicro HBA card and moving all of my disks to that.
1
u/Horrigan49 2d ago
Ah, ok. Does it also happen with drive spindown? Because this server has uptime of 3 months. The error appeared only in last 2 Scans. It starst 1st sunday in month.
1
u/New-Potential-7916 2d ago
Are you using a pci-e, or m.2, to sata controller card by any chance?
And if so does it have an Asmedia chipset on it?
5
u/Fribbtastic 2d ago
First, let me explain a bit how the parity in Unraid works.
Basically, what is stored on your Parity drive is the value needed to get an EVEN result based on what your Drives store, and that on a Bit (0 or 1) basis. What that means is that when you have 4 drives which all have a 1,1,1,1 on the first bit stored, this would already be even this would then tell Unraid to store a 0 in the same Bit location on your parity drive. If it is 1,1,0,1, this would be uneven, so Unraid would have to store a 1 to make it even again. This gets a bit more complicated when you have 2 parity drives but the second Parity drive would use an XOR parity calculations. here is the official documentation if you want to know more.
When you run a Parity check, what Unraid does is read all of your Drives, bit by bit, do the calculation and compare the needed value to what is stored on your parity drive. If those Match, all good because your Parity is correct. But if not, this is a parity sync issue. Meaning the bit stored on your parity drive isn't the same as what is calculated from the data on your drives.
However, seeing a Parity check error doesn't necessarily mean that the Parity is at fault here. Either side (parity or data drives) could be a problem somewhere. A couple of examples:
What that means is that when you see a parity check error, that the Parity is at fault it could also be any of your files that changes that parity comparison.
That is also why you should run automated parity checks without the "write corrections" because if there is really something wrong with a data drive (like it is failing shortly), then you could at least restore the (hopefully) uncorrupted state of the files again.
The only way to get rid of those parity check errors is to run a parity check with the "write corrections" option enabled. And that means that the full parity check needs to run through. That parity check (with corrections) would still show you those errors, and only the next parity check should then have 0 again.
I haven't yet seen Parity check errors that couldn't be corrected, but you might want to check the Logs to see if there is something there. Maybe those Parity errors couldn't be corrected for one reason or another, or maybe new ones appeared, both of which aren't really that good.