Just took a look at my server and they parity had a red ball and had about 630 errors. So I shut down the server and checked the connections. I haven't been in the case since my last parity sync a couple days ago. Started the server back up and now its showing the parity as a blue ball and thinking its new.

 

Whats going on here? Did my parity drive die? Its not more then 6months old, went through a long pre-clear script before it went into the server. If the drive is dieing then I have terrible luck with WD 2TB EARS. Two have been DOA. So the two are from the RMA of the DOA drives. If this one is dieing then I'm 3 for 3.   

 

System log attached.

syslog-2010-09-23.txt

Please post a smart report. There is no way to tell it's dying without information contained in that report.

 

Did you save the syslog before rebooting the server? If yes, post it as well. It might tell us why you got 630 errors.

 

As you were fiddling in your case recently, double check if all cables are seated correctly. Are you using cables that were previously used or new ones?

Didn't save the system log before reboot. It was only one line. Something about restart that's it.

 

Checked the cables, they were new less then six months ago. They are the locking type and I didn't have trouble with the parity sync a couple days ago. I guess I could try a new cable but I don't think thats it, but I'll give it a shot. EDIT: Try another cable, no different.

 

Smart report attached. Should I run a smart test?

 

EDIT: Can I assume that the parity drive isn't going to magically come back online (green ball). Now that unraid thinks its new. I assume I'm going to have to "Start will bring the array on-line and start Parity-Sync."

parity_smart_report.txt

Your drive looks fine. It's good to have the cabling out of the way. The drive will probalby come back online, but it's important to know if the parity is correct or the data disks. If you will rebuild parity at this point using bad data disks, you'll have corruption.

 

I'd suggest performing a parity verify, not correct, but I will leave it to the more experienced folks around here to suggest whichs steps to follow next.

Thanks orbi.

 

I ended up doing a parity sync before I saw your post. Everything seem to be back to normal. I have no idea what happened. Would like to know but I may never know.

 

Next time around I'll do a parity verity, now that I know.

The parity verify feature is useful when there are doubts about the integrity of the data disks.

 

The difference between parity verify/check is that parity verify does not correct the parity drive it differences are found. A parity check will ensure that your parity and your data disk are in synch since any difference found will be corrected.

 

Take for example a data disk which had some write errors due to timeouts. The file you were trying to write on it is not present on the data disk but will be present on the parity disk. UnRaid will be able to reconstruct that file because of parity algorithms and the other data disks. Because UnRaid by default always assumes your data disks are correct, if you were to perform a parity check or rebuild, it will not see that missing file on the data disk and correct your parity accordingly. At this point you lost that file though you would have been able to recuperate it.

 

So in the case of disk errors, it is safer to perform a parity verify. It will highlight differences but no data loss. If your array is healthy, perform a parity check.

The parity verify feature is useful when there are doubts about the integrity of the data disks.

 

The difference between parity verify/check is that parity verify does not correct the parity drive it differences are found. A parity check will ensure that your parity and your data disk are in synch since any difference found will be corrected.

 

Take for example a data disk which had some write errors due to timeouts. The file you were trying to write on it is not present on the data disk but will be present on the parity disk. UnRaid will be able to reconstruct that file because of parity algorithms and the other data disks. Because UnRaid by default always assumes your data disks are correct, if you were to perform a parity check or rebuild, it will not see that missing file on the data disk and correct your parity accordingly. At this point you lost that file though you would have been able to recuperate it.

 

So in the case of disk errors, it is safer to perform a parity verify. It will highlight differences but no data loss. If your array is healthy, perform a parity check.

 

I was the person pushing for the read-only parity check functionality.  I believe that you should always perform read-only parity checks unless there is a conscious decision to run a "correcting" parity check.  Here is a scenario - you start a monthly parity check and one of the drives fails half way through.  In its last fleeting moments, the disk returns junk data.  Your parity check will instantly accept that as good drive data and update parity.  Later, when you rebuild the failed disk, there will be some part of the disk that will rebuild based on the junk.  And you will have corruption in a place that will be impossible to determine.  Had you run a read-only parity check, parity would have remained accurate.  Of course the scenario I laid out could happen during normal array activity as well - so runing read-only parity checks does not 100% eliminate the risks.

 

People are clammering for a second "parity" disk, which would be great.  But it would not fix this type of scenario.  The only way I know of to protect yourself is some means of data level protection.  I have created PAR2 sets for my full disks that would allow me to scan a disk that I suspect of having some type of corruption, and be able to correct such a corruption.  But PAR2 is finicky in that it won't work into subdirectories.  Would like to find something similar in concept that recurses to make it more convenient to run this on an entire disk.

If the parity drive was coming up blue, could he have done a parity verify?  Would it let you run a verify against a potentially new drive?

If the parity drive was coming up blue, could he have done a parity verify?  Would it let you run a verify against a potentially new drive?

It would not let him.