Not a complaint - just I'm a bit puzzled / surprised.

 

Had my first parity error ever (actually like 120 or something) on a recent non-correcting parity check.  I had always assumed parity errors would provide a report of potentially affected files, that was a poor assumption on my part.

 

But from my perspective UnRAID is mostly protecting against complete disk failures - unless you go through the hassle of generating file checksums, which unless there was some automated way of doing it and keeping those checksums fresh, well - anyway it seems like a pretty big inconvenience.

 

So the dialog I wish to have here - is why is it that, as I saw in another post somewhere, that the parity disk was always the cause of the defects, never the actual files?

 

I'm willing to accept that as it came from people more experienced than me - but I'd like to understand why exactly...?

 

Why/how is the write error happening on the parity disk almost all the time, and never on the data disk?

 

(I do acknowledge while I wish UnRAID could provide me a report of the potentially affected files - such a report could end up being rather long, just for one error due to the fact you could have > 20 drives in the array and establishing which one has the error....)

 

The "hassle of generating file checksums" at least provides a way to confirm whether or not files are still good.    Not as good as a backup ... but at least it provides a way to let you know you've got some corrupted data.

 

As for why sync errors are assumed to be on the parity disk -- UnRAID will automatically correct any disk that has a read error ... but if no disks report read errors, then any sync error is assumed to be on the parity disk, because that's by far the most likely.  Any improper shutdown;  crashed process;  memory "glitch"; etc. can cause synchronization errors when computing/updating the parity disk ... and these are far more likely than anything else.

 

The easiest way to be SURE whether or not the errors are in the data or on the parity drive is to just run a comparison between your backups and the UnRAID array.    If the data's wrong, the compare will fail;  if the compare is okay, the issue is on the parity disk.

 

In ~ 5 years of using UnRAID, I've only had sync errors during parity checks 3 times.    Since I keep a complete set of backups, I've spent a few days each time to confirm that there weren't actual data losses .. and I've NEVER found a data error in these cases -- the error has always been on the parity drive. 

 

In fact, I never bother with non-correcting parity checks ... my monthly checks are always "correcting"  (although it's also been a LONG time since they found any errors).

 

While conceptually I understand the desire to do "non-correcting" checks, the simple fact is WHAT are you going to do if you get errors?    Unless you have a means is confirming whether or not the data drives are in fact still good -- either by comparing to backups or verifying checksums, the only real recourse is to assume it's simply a sync error and let UnRAID correct it.    At least in every case I've seen, that's exactly what was needed.

 

I created a script that will create a database of SHA256 hashes of your files if you wish to know if your files are corrupted or not.

 

http://lime-technology.com/forum/index.php?topic=28354.0

Quick scenario to try to make a point.

 

1. Assume a disk subsystem is bad, but not failed by unraid yet. It accepts data, acknowledges the write, but due to a bad drive cache chip, or controller, or whatever, the actual data written to the platters isn't what was sent. Most of the time the drive or controller will catch that condition and report an error, but not always. Unraid has not yet been asked to read and verify, so no failure noted. Joe L.'s preclear script would catch such errors, but if the drive has been added without preclear, there is no mechanism in unraid to catch this kind of failure.

2. Files are written, parity is generated and written at the same time.

3. Parity is accurately representing the intended content of the disk at this time, so pulling the bad disk will not cause any data loss at this point.

4. A correcting parity check is run, the drive reports what is actually on the platter, instead of what was written. Unraid assumes the parity is wrong, and updates the parity drive to show what is actually on the drive now.

5. Parity is now correct, but the content is wrong.

 

Granted, the chances of a drive failing in such a way that it records data incorrectly is pretty small, but scrambled writes may happen further up the chain as well, in the controller, or bad ram, or whatever.

 

My ENTIRE reason for wanting a non-correcting check, is so that I can attempt to diagnose WHY the parity is different, BEFORE committing the changes. I don't want ANY writes, only reads until I've got a handle on what went wrong. First rule of forensic analysis, don't write to the original media.

Interesting reading here.

The problem with your example is that the data you wrote to the drive is incorrect.    A non-correcting parity check won't help with that -- unless you're psychic and know which disk that you've written to that had erroneous writes => if that was the case you could indeed replace the disk and let a disk rebuild "fix" the data.

 

But a FAR better way to test your data is to always validate your writes !!    Either use a utility that will automatically verify writes (e.g. Teracopy); or do a comparison of the data after you write it;  or compute checksums on the files you're writing; and then do a checksum verification after it's written.

 

The problem with your example is that the data you wrote to the drive is incorrect.    A non-correcting parity check won't help with that

No, it won't help. I won't hurt either, like a correcting check would. I just want the opportunity to try to find the cause of the errors before just blindly overwriting things. You don't have to be physic to do some basic detective work, like running back to back md5 checksums on a small set of files on all the drives, looking for inconsistent results. There are plenty of non-destructive ways to investigate errors, so why immediately throw in the towel and assume the parity was wrong and needed to be corrected?

 

Write verification is one very good tool to protect yourself, as is comparing checksums to backup files, etc, etc.

 

That's not the essence of what I'm saying here. I just don't want the system writing data by making an assumption based on what's right 99% of the time. I want to chance to make that decision myself.

As for why sync errors are assumed to be on the parity disk -- UnRAID will automatically correct any disk that has a read error ... but if no disks report read errors, then any sync error is assumed to be on the parity disk, because that's by far the most likely.  Any improper shutdown;  crashed process;  memory "glitch"; etc. can cause synchronization errors when computing/updating the parity disk ... and these are far more likely than anything else.

 

I did a parity check, upgraded to V5, changed the parity disk (to 3TB), and expanded the array with a 3TB and 2TB (old parity drive)

 

I did NOT re-do a parity check after that, and regret it now.

 

But I will say this - I had not one unclean shutdown or crash during this process.

 

Subsequent to me expanding the array, I copied probably 1.5TB of data over to one of the new disks (brand new 3TB which was pre-cleared).  I did a copy with verify, no errors.

 

Then I do a party check...  BAM, 160 parity errors.

 

Unless I am mistaken and I had an unclean shutdown in there, which I believe is very unlikely, something seems amiss that those parity errors crept up.

 

I'm guessing it's all in the parity calc - because the only files I copied since the original parity check and move to V5, were all copied with verify.

 

The easiest way to be SURE whether or not the errors are in the data or on the parity drive is to just run a comparison between your backups and the UnRAID array.    If the data's wrong, the compare will fail;  if the compare is okay, the issue is on the parity disk.

 

I do not mean to sound disrespectful or unfriendly, especially to such a good guy - but I must use a strong word here.

 

This concept above is ridiculous.  (At least to me it is)

 

It is not uncommon for people here to have 20+TB arrays here.  The whole reason we use unraid is to have a decent level fault tolerance.  I would imagine for a good part of the population - most likely the majority...  We don't have readily available backups to go verify 20+TB worth of data.

 

Thanks guys - I still find this a good discussion.  (Even though I haven't yet decided to initiate a correcting parity sync, although I likely will)

 

This concept above is ridiculous.  (At least to me it is)

 

Backup up your data is "ridiculous" ??    An interesting thought 

 

 

I had always assumed parity errors would provide a report of potentially affected files

 

Suppose it DID provide that list.    Without backups, what good would it be ??

(Other than letting you know what files you should delete since they might be bad)

 

 

 

JackBauer >>  I think you mix-up the concept of Disk Parity and Data Parity

while they both have the same  abbreviation "DP"  :-)

they are two different thing all together.

 

and like it or not , UnRaid only provides Disk Parity(as it is clearly indicated by the name).

and is replacement for RAID system to protect your data against hardware failure,

in most cases a hard drive failure.

if the RAID system detects an issue with reading/writing  from/to specific place on the one of the drives with in array it knows that failure exists and how to restore proper balance using Parity information.

but it could not care less what the actual data/file is stored in that location.

it is not in it's job description.

 

now for Data Protection you need something that would check the data itself

and know that this particular block of data is bad.

 

this is a job for files system.

that is why the file systems like  The Z File System (ZFS), B-tree file system(btrfs) for Linux and Resilient file system (Windows)(RFS) for Microsoft were developed

and why they still have support for Software RAID built into them, thus splitting

the functions between the concepts.

the Raid part does what IT was designed for (that is protecting from data loss from  hardware issues)

and file system does what IT was design for (that is  protecting from data loss do to data corruption from other reasons)

 

there are multitude of software available for data integrity check and correction for both windows and Linux but that is totally another topic.

 

unfortunately UnRaid does not have a built in functionality for Data corruption Protection as far as I know (and more knowledgeable people please correct me here.)