So I've searched quite a bit and can't find anything that really tells me clearly (between smart data, dual parity, and unraid redballs), but here's what I have so far...

 

If you have Reallocated sector counts, watch for that number to keep rising to know if the drive is going to die sooner

If you have Reported uncorrect , it is worse of a situation than Reallocated sector counts

If you have a redball in unraid, something really bad has occurred such as an entire drive not being available.

 

So the newer question is, if i have Dual parity up and running without any Red balls, the array passes a parity check without additional errors, BUT a drive has a lot of reallocated sector counts and reported uncorrects...I'm NOT loosing data in the background and I should look to replace the going bad drive as soon as possible?

 

Does a redball only occur when unraid is incapable of handling errors (unresponsive drive,bad cable...etc...)?

Will redball's ever occur based on drive smart data?

 

Thanks for your help!

If a drive has a lot of reallocated sector counts and that number is not increasing the drive may be ok, for awhile, it's hard to say how long but NO, you aren't losing data. Watch the drive and see how it continues to perform, its really a personal choice. Some people will replace a drive at the first sign of reallocated sectors. Red balls occur on read or write errors I believe, they can sometimes be due to a loose or bad sata cable though. I don't believe drives red ball based on SMART data, no, but I could be wrong.

Redballs only occur on write errors. Once a write has failed the disk contents are invalid, but the valid data is in the parity array since the failed write is still used to update parity.

 

I think it may be possible for a read error to cause unRAID to try to reconstruct the bad data from parity and then try to write it back to the disk then if that write fails a redball.

1 hour ago, trurl said:

I think it may be possible for a read error to cause unRAID to try to reconstruct the bad data from parity and then try to write it back to the disk then if that write fails a redball.

 

This is what normally happens on a read error,

8 hours ago, johnnie.black said:

9 hours ago, trurl said:

I think it may be possible for a read error to cause unRAID to try to reconstruct the bad data from parity and then try to write it back to the disk then if that write fails a redball.

 

This is what normally happens on a read error,

 

This is interesting information.  So unRAID is actually self-healing for certain types of read failures found during correcting parity checks?  Or does it have to be an attempt to read the data during a 'normal' reading of a file from a disk? 

Edited June 3, 20179 yr by Frank1940

Just now, Frank1940 said:

 

This is interesting information.  So unRAID is actually self-healing for certain types of read failures found during correcting parity checks?  Or does it have to be an attempt to read the data during a normal reading of a file from a disk? 

Tom confirmed for me a long time ago that during a read error on a data drive during a parity check that the system would then rewrite the offending sector by reconstructing its contents from the other drives.

Just now, Frank1940 said:

 

This is interesting information.  So unRAID is actually self-healing for certain types of read failures found during correcting parity checks?  Or does it have to be an attempt to read the data during a normal reading of a file from a disk? 

 

It happens always including during a parity check, it won't happen only if there's not enough redundancy, i.e., you're rebuilding a disk with single parity and there's a read error on a different disk, in that case the rebuild will continue but the file (or files) in that sector(s) will be rebuilt corrupt.

So this is another excellent reason for doing a periodical parity check as it can catch and repair minor problems with disks that could prevent a rebuild of a data disk that has suffered a catastrophic failure.   I would say that 90% of unRAID users are unaware that this action is occurring in the background.

Thanks guys, great info! Never having a redball myself and having dual parity, I feel much more comfy with my data. So just to verify, a redball or drive error during normal read/write or parity check will never be caused by Smart info and just caused by actual read/write on the array (on either parity check or normal read/writes)?

 

Does unraid ever try to use Smart data to infer or extrapolate how to use the drives (write to less risky drives first)?

2 minutes ago, bsim said:

So just to verify, a redball or drive error during normal read/write or parity check will never be caused by Smart info and just caused by actual read/write on the array (on either parity check or normal read/writes)?

 

Correct, and a disk is only disabled if a write fails.

 

2 minutes ago, bsim said:

Does unraid ever try to use Smart data to infer or extrapolate how to use the drives (write to less risky drives first)?

 

No, but if you have notifications enable you'll get a warning if any of the monitored attributes changes.

4 minutes ago, bsim said:

Does unraid ever try to use Smart data to infer or extrapolate how to use the drives (write to less risky drives first)?

This wouldn't really help anything, since any "risky" drives are a risk to the whole array. All drives are needed to reconstruct data of a missing drive. Dual parity just means you can reconstruct 2 missing drives.