I am hoping to find out a way to check to see which drive correlates to the 4 parity errors that showed up during my last parity check.  My parity check was set to NOT "Write corrections to parity disk" so the errors are still there for me to examine.  I can run another parity check to write corrections to the parity drive, but I want to be sure that the errors are in fact on the parity disc and not on the data drive first.

 

Is there a way to do this?

 

Thanks and best regards,

craigr

I am hoping to find out a way to check to see which drive correlates to the 4 parity errors that showed up during my last parity check.  My parity check was set to NOT "Write corrections to parity disk" so the errors are still there for me to examine.  I can run another parity check to write corrections to the parity drive, but I want to be sure that the errors are in fact on the parity disc and not on the data drive first.

 

Is there a way to do this?

 

Thanks and best regards,

craigr

Unfortunately not.    The current method of handling priority only allows one to determine that is a problem with the parity - not which disk caused the issue,

 

The 6.2 release is apparently going to support dual parity.  If you have dual parity in place then I believe that it should allow for determination of which disk caused the issue.

Easy, it's the parity drive that's wrong!

 

The chances of it being any other drive are so small, I never run a non-correcting parity check.  It's not impossible, so I do use a checksumming tool to watch for bitrot, haven't found any and don't expect to.  The chances of bitrot are very small, more like winning a small lottery.  And getting 4 parity errors rules out bitrot, unless you expect it's possible to suddenly win 4 lotteries at once!  Most parity errors are caused by write interruptions, the data was written but parity was not, by a power outage, bad shutdown, crash, etc.  Almost always, the data is correct, the parity is not.  And if you did win the lottery and have a wrong data bit, there's no way to find it without file verification methods -checksumming, par2 files, or backup files to compare with.  So if you cannot know which drive, you have to correct the parity drive, update it to match what the data is now.

I am hoping to find out a way to check to see which drive correlates to the 4 parity errors that showed up during my last parity check.  My parity check was set to NOT "Write corrections to parity disk" so the errors are still there for me to examine.  I can run another parity check to write corrections to the parity drive, but I want to be sure that the errors are in fact on the parity disc and not on the data drive first.

 

Is there a way to do this?

 

Thanks and best regards,

craigr

Unfortunately not.    The current method of handling priority only allows one to determine that is a problem with the parity - not which disk caused the issue,

 

The 6.2 release is apparently going to support dual parity.  If you have dual parity in place then I believe that it should allow for determination of which disk caused the issue.

That would be a nice feature to have.  Hopefully we'll get it later.

 

Thanks,

craigr

Easy, it's the parity drive that's wrong!

 

The chances of it being any other drive are so small, I never run a non-correcting parity check.  It's not impossible, so I do use a checksumming tool to watch for bitrot, haven't found any and don't expect to.  The chances of bitrot are very small, more like winning a small lottery.  And getting 4 parity errors rules out bitrot, unless you expect it's possible to suddenly win 4 lotteries at once!  Most parity errors are caused by write interruptions, the data was written but parity was not, by a power outage, bad shutdown, crash, etc.  Almost always, the data is correct, the parity is not.  And if you did win the lottery and have a wrong data bit, there's no way to find it without file verification methods -checksumming, par2 files, or backup files to compare with.  So if you cannot know which drive, you have to correct the parity drive, update it to match what the data is now.

I hear you and ordinarily I would agree... except I ran FreeBSD on this server using ZFS before.  I would do a zpool scrub every month or so and occasionally there would be errors.  I don't know how I would get such frequent errors, but they would happen.  The nice thing with ZFS was that it could heal.  I've been running unRAID for two and a half hears now and this is the first time I have found parity errors.

 

Another issue is that if a hard drive is failing and there is a small area of corrupt data, I don't want to overwrite the parity because the correct data will then be destroyed.  I'll probably do a second parity check without overwriting and see if I get the same number of errors at least.

 

But I do agree that the errors are most likely on the parity drive.  That said, I haven't had any improper shutdowns since the last parity check.

 

Thanks and best regards,

craigr

In the absence of unclean shutdowns or random resets, how can array parity get corrupted?

 

In a typical PC style h/w platform there is "protection" in the entire data path between memory and storage media except for one place.  What do I mean by protection?  It means there is either packet-style communication where the h/w can check CRC's or there are parity protected data lines (meaning for every 8 signals in parallel there might be a 9th parity signal).  cf: http://ps-2.kev009.com/eprmhtml/eprmx/12462.htm

 

Where is the one place where there is no data protection?  Your memory,  unless you are using ECC memory, which is the whole point of using ECC memory.

 

When data is fetched from memory, if one of the bits gets flipped on it's way out of the memory cell and before it hits the memory controller, nowhere is this detected.  This is why ECC memory is recommended for ZFS.  Personally, I think ECC memory should be used in all computer systems: desktops, servers, etc.  But support and use of ECC memory is more expensive.

 

In the context of unRAID such flipped bits would mostly occur via DMA accesses initiated by the disk controller.  If it makes it out to media it can be on any disk, though since parity disk is involved in all writes, it's more likely it would be the one with incorrect data (but not guaranteed).

 

Lastly, you will be able to find a lot of mainly anecdotal information on something called "bit rot".  The claim is that bits on media can degrade and flip without being detected.  Assuming there are no bugs in firmware, sure it's possible for bits on media to flip, but it's impossible for the them to not be detected as being flipped (talking about a typical HDD here).  This is because each sector stored on an HDD includes ECC check data.  This is designed to not only detect all errors, but it's able to correct single and multi-bit errors depending on how many bits are flipped.  This is all done in the h/w as the serial bits stream is read right off the r/w head.  The only way you can have true "bit rot" (where bit flips are passed undetected) is if there is a firmware bug, such as reading the wrong sector, or possibly a physical h/w defect somewhere.  Agreed, though from the point of view of someone using the HDD, such errors look like "bit rot".

Thanks for the detailed explaination.

 

Best,

craigr

So I ran the parity check again and it finished this time with zero sync errors.  This tells me one of two things:

 

1) Either unRAID has a bug and when "Write corrections to parity disk" is unchecked, the parity drive is still being written to.

2) Or the first parity check detected sync errors that did not exist.

 

Best regards,

craigr

So I ran the parity check again and it finished this time with zero sync errors.  This tells me one of two things:

 

1) Either unRAID has a bug and when "Write corrections to parity disk" is unchecked, the parity drive is still being written to.

2) Or the first parity check detected sync errors that did not exist.

 

Best regards,

craigr

 

Or

 

3) The stripe containing the parity mismatch got written, thus restoring correct parity.

So I ran the parity check again and it finished this time with zero sync errors.  This tells me one of two things:

 

1) Either unRAID has a bug and when "Write corrections to parity disk" is unchecked, the parity drive is still being written to.

2) Or the first parity check detected sync errors that did not exist.

 

Best regards,

craigr

Interesting.  Could you please explain?

 

Best,

craigr

 

Or

 

3) The stripe containing the parity mismatch got written, thus restoring correct parity.

So I ran the parity check again and it finished this time with zero sync errors.  This tells me one of two things:

 

1) Either unRAID has a bug and when "Write corrections to parity disk" is unchecked, the parity drive is still being written to.

2) Or the first parity check detected sync errors that did not exist.

 

Best regards,

craigr

 

Or

 

3) The stripe containing the parity mismatch got written, thus restoring correct parity.

Interesting.  Could you please explain?

 

Best,

craigr

Fixed your quoting.

 

If the array was written to, then parity would have been updated with the write, so possibly the parity that was incorrect before got written.