Parity Check button

[outsider]

As a new user, I am a little unclear of the "Check" button (parity check button)

 

Do I use this button to purely "check" that the parity drive data matches the parity data of the array drives?  (and the parity is updated live as  files are modified/deleted/created?

 

Or is the button used to build a new parity for the drives in the array?

[SSD]

As a new user, I am a little unclear of the "Check" button (parity check button)

 

Do I use this button to purely "check" that the parity drive data matches the parity data of the array drives?  (and the parity is updated live as  files are modified/deleted/created?

 

Or is the button used to build a new parity for the drives in the array?

 

The former.  Parity check causes every sector on every array disk to be read, parity recomputed, and compared to the value on the parity disk.  If it finds mismatches, it reports sync errors.  A byproduct of a parity check is that every sector on every disk is exercised.  it is therefore used by many here as a monthly check and verification that not only is parity good, but the drives are healthy too.

 

The "restore" button is the scarey one that throws away parity and prepares to buld new parity based on the drives in the array.  Don't touch that button if you have any sort of drive failure.  It can easily take you from a recoverable scenario to an unrecoverable scenario.

[Guest smnas]

Agreed, a monthly Parity Check is the way to go to verify the integrity of no only your data, but also the parity and data drives that your unRAID server has. A worthy piece of maintenance to do. Cheers!

 

[Joe L.]

Or is the button used to build a new parity for the drives in the array?

Parity is updated live, as you write to the array. In a perfect world you will never need to press the "Check" button.

 

The button actually Checks AND corrects parity based on what is read from the data disks.  It will trust the data is correct. It always assumes the data disks are being read properly and will correct parity.

 

There is a way on the Linux command line to perform a read-only parity check, that does not update parity, but leaves it in an inconsistent state.  The feature does not yet report where the inconsistency occurred, so it is not as useful as it could be if it did.

 

The suggested monthly parity check is intended to detect hardware problems before an actual failure occurs.  I would use the read-only parity check.  That way, you still exercise the disks to detect problems, but don't change parity at all.  If the monthly scheduled check finds a problem you can make additional tests before pressing the "Check" button to Check-and-correct parity.

[Rajahal]

The button actually Checks AND corrects parity based on what is read from the data disks.  It will trust the data is correct. It always assumes the data disks are being read properly and will correct parity.

 

So if some data on one of your disks becomes corrupted somehow, running a parity check could potentially throw away any chance you have of rebuilding that corrupted data using parity?

[Joe L.]

The button actually Checks AND corrects parity based on what is read from the data disks.  It will trust the data is correct. It always assumes the data disks are being read properly and will correct parity.

 

So if some data on one of your disks becomes corrupted somehow, running a parity check could potentially throw away any chance you have of rebuilding that corrupted data using parity?

Correct.

 

There is a read-only parity verify available, but the stock unRAID web-page does not have a way to get to it.

 

You need to initiate it from the linux command line:

/root/mdcmd check NOCORRECT

 

It will look exactly the same on the management console.  It will not currently tell you where the errors occurred, only a count. It does not change parity, so if you find an error you can run it again and again and the error will remain until you run the normal parity check command.

 

The unMENU array management page does have a button for the "verify only check" of parity.  It basically submits the command as I described above.

 

Joe L.

[Rajahal]

Hmm, so do you recommend this read-only parity check for monthly maintenance instead of the normal check-and-correct parity check?

[barrettj]

There is a way on the Linux command line to perform a read-only parity check, that does not update parity, but leaves it in an inconsistent state.   The feature does not yet report where the inconsistency occurred, so it is not as useful as it could be if it did.

 

Would it even be possible to tell where the error occurred (with any degree of reliability without tons of testing)?  Wouldn't the most it could do be to tell you that there was a block mismatch between the disks and parity, so if you have say 10 disks then the error could be in any of the 10 files that those disks contain OR that the parity block is wrong.  So each time it occurred you would have {number of disks} files to check per error.  If each of those files was 1 gb move you'd have to watch each one all the way through, or have a MD5 hash of the file in order to check, wouldn't you?

[BRiT]

It should be able to tell you the exact sectors/inodes the parity error occurs at. With that information you should be able to piece together exactly which files are possibly corrupted and exactly what part of the file.