September 23, 201213 yr hi i have recently just introduced a parity drive after copying all my data to data drives, i decided to run a parity check with "Correct any Parity-Check errors by writing the Parity disk with corrected parity." option ticked, i now think this was a bad move, more on this in a moment. basically at the start of the parity check i noticed 65 disk errors showing on disk2 and a "sync errors corrected" count of 1. i had a look at the syslog and it looks like disk2 maybe the culprite, so i may possibly have a dodgy disk, my worry is that because parity is now calculated from the disk i will of lost any data that was in the 65 errors logged (block??). its now finished parity check with no more sync errors or disk errors. attached is my syslog, oh btw im running 5.0 rc8a, if you need any more info then please let me know. many thanks. syslog.txt
September 23, 201213 yr This is the reason that delaying the addition of the parity drive is a bad idea. The additional speed is not worth the reduction in reliability. I suggest that disk2 be removed from the array. Recompute parity without disk2. Meanwhile preclear disk2 and then add it back to the array. Finally, restore the contents of disk2 from originals.
September 23, 201213 yr Author This is the reason that delaying the addition of the parity drive is a bad idea. The additional speed is not worth the reduction in reliability. I suggest that disk2 be removed from the array. Recompute parity without disk2. Meanwhile preclear disk2 and then add it back to the array. Finally, restore the contents of disk2 from originals. hi thanks for your swift response, one question why would i run a preclear on disk 2 again?, would a replacement drive not be a better solution?, unless running a preclear marks the bad sectors and thus the drive can then be reused, is this the idea?. thanks again.
September 23, 201213 yr This is the reason that delaying the addition of the parity drive is a bad idea. The additional speed is not worth the reduction in reliability. I suggest that disk2 be removed from the array. Recompute parity without disk2. Meanwhile preclear disk2 and then add it back to the array. Finally, restore the contents of disk2 from originals. hi thanks for your swift response, one question why would i run a preclear on disk 2 again?, would a replacement drive not be a better solution?, unless running a preclear marks the bad sectors and thus the drive can then be reused, is this the idea?. thanks again. It should resolve any pending sectors that caused the read errors. Post a SMART report.
September 23, 201213 yr Author smart report attached, another question for you, sorry if im bugging you, is there any way i can identify which file(s) were unreadable based on the information in the syslog, i.e. the number after the "handle_stripe read error:" which im assuming is the block number perhaps?, if can you detail the command, im just trying to identify what i may of lost. thanks once more. smart_report.txt
September 23, 201213 yr The SMART report shows no indication of problems. A pre-clear cycle is a good test of reliability. Check and reseat the cabling to the drive. I don't think there are any unRAID native utilities to determine on which sectors a file is located. There are some 3rd party Windows and possibly Linux utilities. If the original data is not available then run reiserfsck on the current disk after a reboot. See my sig. The safest course is to restore from the source or other backup.
Archived
This topic is now archived and is closed to further replies.