Question about cancelling a parity check prematurely


fitbrit

Recommended Posts

You should let it complete at least once to ensure the parity disk is indeed all good in the last 2TB (should all be zeroes).      But after that, there's no real harm in stopping it after the 4TB point.    You simply wouldn't know about it if one of the bits on the parity disk happened to "flip" in the last 2TB.

 

Link to comment

Thanks! That's what I plan to do.

 

In theory though:

Even if the parity in the last 2 TB is not all zeroes, would that not get corrected when I have disks larger than 4 TB in my array and write to them? Or is there no real-time checking of parity as it's being written (ie it just "adds" to what is already there)?

Link to comment

It depends on how you add the new disk.

 

If you ADD a pre-cleared disk, it's assumed that there are no changes to parity, since the disk is "known" to be all zeroes.    So the first time you did a parity check after adding it, parity would THEN be corrected.

 

If you UPGRADE an existing disk to 6TB, the "extra space" at the end of the previous disk's size is actually computed from other disks => the result SHOULD always be a zero, but in the case of an erroneous parity bit, the corresponding bit on the expanded disk wouldn't be a zero.    In this case there wouldn't be an error on the next parity check, since the bit on the expanded disk was set to match what was there.

 

But in either case, it wouldn't really matter => in the first case, parity would simply be corrected;  in the second case, parity would suddenly be "correct" because the bit on the expanded disk was set to make it that way.

 

 

Link to comment

Thanks! That's what I plan to do.

 

In theory though:

Even if the parity in the last 2 TB is not all zeroes, would that not get corrected when I have disks larger than 4 TB in my array and write to them? Or is there no real-time checking of parity as it's being written (ie it just "adds" to what is already there)?

 

There is no real time checking of parity. UnRaid assumes parity is correct and seeks to maintain it with each write. Unlike traditional RAID, corrupted parity is completely silent. Even if it is completely FUBAR, a person's array would work with absolutely no sign of corruption. But if a disk were to fail, the lack of accurate parity would be drastically visible. Similarly, if a disk were replaced or upsized, the corruption would also be obvious. But in adding a new disk the corruption would not be evident. If parity is only minimally inaccurate, recognizing corruption becomes very difficult, unless something like md5s are maintained on each file.

 

So run a monthly parity check to ensure and give confidence that parity is accurate. I have run them for years and unRaid had proven itself quite accurate and capable in maintaining parity. The only exception is an extremely infrequent hard shutdown which sometimes generates a handful of sync errors (parity mismatches) which the parity check corrected by relying on the data disks.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.