February 22, 201610 yr There's a potential for significant improvement in this process coming soon. When dual parity is implemented, it will be mathematically possible to identify WHICH BIT is in error if a sync error is detected during a parity check. Whether this will in fact be done I don't know -- but hopefully the parity check implementation will be done so that this is in fact identified ... and the specific bit that's in error will be corrected. This feature is expected in v6.2 => hopefully that will indeed be the case. You'll need a 2nd parity disk to implement it, but the very significant improvement in reliability -- and protection from a 2nd drive failure during a rebuild -- is easily worth the cost of that extra disk. And if they also implement the "error intersection" logic that will allow the specific bit that's in error to be corrected, that will be a VERY nice improvement.
February 22, 201610 yr And if they also implement the "error intersection" logic that will allow the specific bit that's in error to be corrected, that will be a VERY nice improvement. IMO there isn't much value in dual parity if they don't include this logic. I think 6.2 (assuming this is in 6.2) will be a big leap forward for unRAID.
February 22, 201610 yr And if they also implement the "error intersection" logic that will allow the specific bit that's in error to be corrected, that will be a VERY nice improvement. IMO there isn't much value in dual parity if they don't include this logic. I think 6.2 (assuming this is in 6.2) will be a big leap forward for unRAID. While I certainly hope this is included in the implementation, there's still a very significant value of dual parity even without it => a 2nd drive failure during a rebuild would be successful, whereas with single parity that would result in a failed rebuild. And of course your array is still fault tolerant after a drive failure while you're acquiring the replacement drive.
February 22, 201610 yr Community Expert This will be very good for normal sync errors, but if parity still is updated when a disk read error occurs, this just means both paritys will be corrupted, and according to Tom it should not happen. A 'parity check' reads all devices in the array. If no URE's (unrecoverable read errors), then Parity and all Data are xor'ed together. If the result is not equal "all zeros", then parity is re-calculated by xor'ing the Data again, and written to the parity disk (provided "Write corrections to parity disk" checkbox is checked). If any single disk reports URE then of course we don't have valid data for that disk. In this case we reconstruct the missing data by xor'ing parity with all 'other' data disks, result is then written to the disk which got the URE (regardless of whether "Write corrections to parity disk" is checked or not). If any write fails this will disable the device. This will be the same behavior with P+Q parity, only now there is both P and Q to check, and there can be one or two devices written.
February 22, 201610 yr This will be very good for normal sync errors, but if parity still is updated when a disk read error occurs, this just means both paritys will be corrupted, and according to Tom it should not happen. A 'parity check' reads all devices in the array. If no URE's (unrecoverable read errors), then Parity and all Data are xor'ed together. If the result is not equal "all zeros", then parity is re-calculated by xor'ing the Data again, and written to the parity disk (provided "Write corrections to parity disk" checkbox is checked). If any single disk reports URE then of course we don't have valid data for that disk. In this case we reconstruct the missing data by xor'ing parity with all 'other' data disks, result is then written to the disk which got the URE (regardless of whether "Write corrections to parity disk" is checked or not). If any write fails this will disable the device. This will be the same behavior with P+Q parity, only now there is both P and Q to check, and there can be one or two devices written. This tends to reinforce what I said earlier (in another thread) about simply always doing correcting checks. Clearly the process ALREADY writes corrections to a disk that has a URE instead of the parity disk ... and to the parity disk if there are no indicated disk errors. This is almost certainly going to be the correct action -- and is likely exactly what an educated user would choose to do if he did a non-correcting check, and noted whether or not there were disk errors. It sounds like the dual parity implementation is simply going to repeat this logic for both parity computations ... i.e. there isn't going to be an "error intersection" calculation to use the 2nd parity to compute where an error is in the other parity calculation. However, given that any disk with a reported error is already corrected instead of parity, the same thing is true for both parity calculations => it's VERY likely that the correction is being written to the right place.
February 22, 201610 yr Community Expert This tends to reinforce what I said earlier (in another thread) about simply always doing correcting checks. Clearly the process ALREADY writes corrections to a disk that has a URE instead of the parity disk ... I believe I proved above that this not happen, at least not always, an URE updated parity making the subsequent rebuild corrupt.
February 22, 201610 yr This tends to reinforce what I said earlier (in another thread) about simply always doing correcting checks. Clearly the process ALREADY writes corrections to a disk that has a URE instead of the parity disk ... I believe I proved above that this not happen, at least not always, an URE updated parity making the subsequent rebuild corrupt. Just out of curiosity, what process did you use when you said you "... made the disk fail during a correcting parity check ..." to do that test?
February 22, 201610 yr Community Expert Just out of curiosity, what process did you use when you said you "... made the disk fail during a correcting parity check ..." to do that test? It was Seagate, just waited for it to fail First tried overheating it, but it went to 78C and it didn’t fail, then rapidly cooled it down to 30C, again continued to work, so I let it fall a few inches on the table while doing a parity check, it took 5 or 6 times, but it worked, note that it didn't redball. SMART at the end (both reallocated sectors and reported uncorrect where 0 before this) ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 098 098 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 7 5 Reallocated_Sector_Ct 0x0033 098 098 036 Pre-fail Always - 110 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 2183846 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 7 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7 187 Reported_Uncorrect 0x0032 003 003 000 Old_age Always - 97 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 069 022 045 Old_age Always In_the_past 31 (0 230 78 18 0) 194 Temperature_Celsius 0x0022 031 078 000 Old_age Always - 31 (0 15 0 0 0) 195 Hardware_ECC_Recovered 0x001a 064 058 000 Old_age Always - 197191732 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 Data_Address_Mark_Errs 0x0032 100 253 000 Old_age Always - 0
February 29, 201610 yr Author Well, a lot has happened since my last post on this topic. I kept getting parity check errors even after removing the pre-fail disks and starting a new config. Mostly PHP errors that caused the UI to stop working and the parity check to stop. Parity had lots of errors before stopping. I went back to v5 to see if it had the same result. Still got PHP errors, but the check worked (tons of errors) after a new config was done. Read a lot of info on this forum and decided to do a memtest. Didn't take long for tons of errors to pop up. Removed two of my DIMMS and no more errors. Parity check completed on my current v6 config without errors. I'm going to say this issue is resolved. I'm glad I had this issue (sort of) as it was a learning experience and I am now much more comfortable and confident in unRAID. Thanks for all your help everyone.
February 29, 201610 yr Memory errors will indeed cause a LOT of different issues. This is yet-another example of why it's a good idea to user server-class components with ECC memory support.
February 29, 201610 yr Author I solved that problem with my purchase in the e5-2670 thread. Picked up two of those and 64gb of ECC registered memory. Just need a board to put them in. I'm excited.
February 29, 201610 yr I solved that problem with my purchase in the e5-2670 thread. Picked up two of those and 64gb of ECC registered memory. Just need a board to put them in. I'm excited. Yes, that will solve that in spades !! Not only ECC, but also buffered RAM, which is FAR more reliable than unbuffered modules
Archived
This topic is now archived and is closed to further replies.