Pre-clearing new disk now...

I'll post an update as soon as I have something to report.

 

And big thanks to Frank1940 and itimpi!

Pre-clear went perfect. 0 issues with the new drive. So I pulled the failing Disk1 and replaced with the new pre-cleared disk. I started the array and Rebuild. There is now an orange ball indicator at disk1 and I see "Rebuild in progress." All seems to be going well.

 

However, just out of curiosity, I went to the shares via the network that are/were contained on Disk1 - I have them setup so that specific shares reside only on a specific disk. And I was AMAZED to see that all of the files seem to be accessible. Already? Rebuild is currently at 1% but everything seems to be available and readable. Did I pull the wrong disk maybe? or is this just the awesomeness of unRaid? I am fearful I've done something wrong. Can anyone tell me whether this is normal or not?

 

Thank you.

This is 'normal' and at the same time 'great' behavior. unRAID emulates the faulty disk for you.

The replaced drive seems to have rebuilt just fine. All green indicators now. I am guessing that if there were a problem I would have received some sort of notification?

 

Also, since I had read errors initially and that's why I replaced the disk, is it possible that somewhere amidst the files on the rebuilt disk, I may have some files that are corrupt as a result? I suppose there is just no way to know until I find them?

 

Thanks again.

The replaced drive seems to have rebuilt just fine. All green indicators now. I am guessing that if there were a problem I would have received some sort of notification?

 

Also, since I had read errors initially and that's why I replaced the disk, is it possible that somewhere amidst the files on the rebuilt disk, I may have some files that are corrupt as a result? I suppose there is just no way to know until I find them?

 

Thanks again.

If everything worked as intended, you shouldn't have any corruption. The way unraid works, if a read error is detected, it spins up all the disks, and computes what the data was supposed to be from all the other drives including parity. It then tries to write the correct value back to the disk that had the read error. If the disk accepts the write without error, unraid increments the error column for that drive and keeps using it. If the write fails, unraid immediately red balls the drive, and all further operations are done by emulating the bad drive contents from all the other drives. So, if everything works as designed, a single drive failure is handled with absolutely no data loss or corruption.

 

Every once in a while data can get corrupted, and there are 3rd party plugins that can be used to create and store checksums so you can scan for corruption. It's not common to get corrupted data, even with a rebuild, so you are probably just fine.

Run a parity check to confirm the rebuild.

Agree you should run a parity check to confirm the rebuild went okay.    This should be a NON-Correcting check, so that if the rebuild did NOT go well you can redo it.    This is the only time I recommend doing non-correcting checks.

 

Thank you. Running non-correcting parity check now.

 

Question: I've read varying opinions on running correcting vs non-correcting parity checks, is there an universally agreed upon use for each, or does each situation differ?

 

Thanks

 

 

Thank you. Running non-correcting parity check now.

 

Question: I've read varying opinions on running correcting vs non-correcting parity checks, is there an universally agreed upon use for each, or does each situation differ?

 

Thanks

I don't think there is universal agreement at all.

 

In summary...

 

Non-correcting only reads all the disks, and does the math to see if parity is correct. If it doesn't add up, it shows an error.

 

Correcting does the same read and verify, but if the answer is wrong, it shows an error, and writes the correct sum to the parity drive.

 

If everything is working as it should, correcting parity checks are proper. IF you have any number of issues that could corrupt data (drive, memory, controller, PSU, cabling), writing any data to the drives could cause issues. If you don't know what caused the parity to be incorrect, you are risking corruption with a correcting check.

 

I personally would rather have a chance to look things over if a parity check comes back with errors before committing any changes.

There are definitely conflicting opinions.

 

I believe there's fairly universal agreement that after a disk rebuild you should run a non-correcting check.    That's the simplest way to confirm the rebuild went well ... and it preserves the original parity so if there are errors you can redo the rebuild.  Note that this ASSUMES that any errors found were on the rebuilt disk ... but if you started out with good parity, and the only thing you've done is the disk rebuild; then that's a fairly safe assumption.

 

For most other cases, the odds are VERY high that any parity sync errors detected are in fact on the parity disk ... that's why the parity check was designed to always correct those errors.  Originally there wasn't a simple GUI choice for a "non correcting" check (in v4 days).  But many folks wanted the option, so it was added in v5.

 

My view is simple:  Consider these factors:

  -- There's no way, with a single parity bit, to determine WHICH disk had the error if a parity error is found. 

  -- There are several circumstances that result in updates to the parity disk to not be committed ... thus generating errors on that disk. 

  -- An actual read error from a data disk will almost always show an error due to a CRC mismatch. 

 

Statistically, it's VERY likely that any parity error is simply a sync error that didn't get committed to the parity disk.    If you run a non-correcting check and find errors, what's the most likely thing you're going to do next?    In virtually every case, the answer is to simply run a correcting check so those errors get fixed.    So I NEVER run non-correcting checks except after a disk rebuild (for the reasons I noted above).

 

If you're having more significant system errors -- i.e. a PSU failure; memory failure; etc. then you're almost certainly going to know that there are problems ... so you should be diagnosing those instead of running a parity check.  You may, of course, in those situations, want to run a non-correcting check after you've resolved the issue to see if it impacted your parity.    And if it did, you may want to run a checksum verification of your files and/or compare them all to your backups to isolate which specific files may have been corrupted.

 

This is one area that will be very nicely improved when dual parity is eventually implemented, as it will then be computationally possible to determine WHICH specific bit is in error when an error is detected.