Well, it certainly seems in my case that I have isolated it to the PATA side, I am 1/3 of the way through a clean parity check with all my SATA drives enabled.

I'm debating taking the array down now before the check completes, as it's past the 300GB line. I picked up a pair of these cheap PCI cards

(http://www.seagate.com/staticfiles/maxtor/en_us/documentation/installation_guides/sata_150_pci_card_installation_guide.pdf)

to replace one of my Promise cards. I suspect the FastTrack 100 TX4 may be causing the problem, it seems to have a bad reputation.

 

I _think_ I have eliminated the power supply, because all the drives are still installed and spinning.

 

OK, moment of truth (I guess):

 

Checked BIOS version - it's the latest.

 

Brought up the array with only one disk (+parity of course) - everything checks OK. no sync errors

Added a second disk - everything checked OK

 

Replaced SATA cable on the third disk which was a major suspect anyway because it reported some errors on the smartctl test and also it run hotter than the other by 2-4 degrees © for no apparent reason.  Generated the Parity and rechecked - sync errors galore.

 

So I guess it's the garbage bin for this disk.  I'll get a new disk and clone the old one outside of unRaid since I can't trust unRaid to restore it on account of the bad parity.

 

I'll report back in a few days.

 

Thanks again for all the help and good advice I got here - you guys are great.

 

Excellent!  You're doing great. 

 

It definitely sounds like it has something to do with adding that 3rd data disk.  A couple more tests and you should be able to isolate even further.

 

Try going back to a 2 disk configuration again.  This time, use parity and the suspect disk.  PLUG the SUSPECT DISK INTO ONE OF THE MOTHERBOARD PORTS FROM ONE OF THE WORKING DATA DRIVES with a known good SATA cable and power connection.

 

Try to calculate and check parity.  If that fails, you have concluded that the problem is with that physical disk.  Proceed to RMA trhe disk.

 

But if that works, it is looking like a BIOS setting, motherboard problem, or (remotely possible) a PSU problem.  (It could be a PSU problem if there is insufficient power to run all 4 disks simultaneously - not likely).

 

Sometimes there is a BIOS setting concerning the SATA ports.  They can run in IDE mode, ACHI mode, or (on some motherboards) RAID mode.  The default may be IDE mode.  You might want to try ACHI mode.  That may or may not help.  Anything related to RAID should be disabled.

 

You might also look for other BIOS settings.  Disable sound or other motherboard features you're not using.

 

Good luck!

The final verdict is - replace that disk.  The test with the suspected disk on a different SATA port/cable failed as well.

 

So, what have I learned:

 

(a) S--t happens

(b) There are people out there ready to invest their time and knowledge to help you out - many thanks.

© A concern was raised during these past few days:

 

What if the system (I intentionally don't say "a disk" although this seems to have been the case here)  develops a problem that does not manifest itself in a solid physical read/write error and as a result you're not made aware of it.  Then, one morning you wake up and think: "this looks like a great day for a parity check".  You press the little innocent button and in doing so you rob yourself of the possiblity to reconstruct a possibly problematic disk.  Is there a flow in this logic that escaped me? Don't you think that a non destructive parity check is warranted?

 

I'll report the epilog here in a few days.

 

 

This is exactly the concern I have. Luckily, the disk causing my problems was almost empty, and contained only replaceable data. I would have been seriously ticked if I had lost a terabyte or more of data because of this. I set up a raid array precisely because I wanted to avoid this type of scenario.

 

What if the system (I intentionally don't say "a disk" although this seems to have been the case here)  develops a problem that does not manifest itself in a solid physical read/write error and as a result you're not made aware of it.  Then, one morning you wake up and think: "this looks like a great day for a parity check".  You press the little innocent button and in doing so you rob yourself of the possiblity to reconstruct a possibly problematic disk.  Is there a flow in this logic that escaped me? Don't you think that a non destructive parity check is warranted?

The final verdict is - replace that disk.  The test with the suspected disk on a different SATA port/cable failed as well.

 

So, what have I learned:

 

(a) S--t happens

(b) There are people out there ready to invest their time and knowledge to help you out - many thanks.

© A concern was raised during these past few days:

 

What if the system (I intentionally don't say "a disk" although this seems to have been the case here)  develops a problem that does not manifest itself in a solid physical read/write error and as a result you're not made aware of it.  Then, one morning you wake up and think: "this looks like a great day for a parity check".  You press the little innocent button and in doing so you rob yourself of the possiblity to reconstruct a possibly problematic disk.  Is there a flow in this logic that escaped me? Don't you think that a non destructive parity check is warranted?

 

I'll report the epilog here in a few days.

 

Glad that you were successful at determining the cause of the problem.

 

Do not let this problem deter you or anyone else from doing parity checks.  Parity checks protect you from sector errors (and occasionally logic bugs) that many users have experienced.  It is the single most important preventative maintenance activity that users should perform.  Running it made you aware of your problem in the first place.  The earlier you know about a problem the better chance you have of minimizing its impact!  If you hadn't done it you might still be running in blissful ignorance that you had no protection at all.

 

You appear to have had a very unusual problem (never seen or heard of anything similar).  I think it likely that you just had a defective drive from the beginning.  It is a good idea to run some burn-in tests with new drives, because OOTB failures are not that uncommon, and drives do have reduced reliability when they are initially put into service.  I posted a burn in process for 2 new drives - it is linked in the "Best of" wiki page, How To section (see link in my sig).

 

Note that a nondestructive parity check has been suggested.  I believe it is on the "laundry list".  I encourage you to advocate for it in the feature request forum section  I think it is a good idea, but there are many good ideas and the question is priority of the various enhancement suggestions.

 

I have recently been advocating for a "sanity parity check" feature, which would be a short, non-destructive parity check at each boot.  It would likely find problems like yours sooner.  (Link here)

 

Hope your array is up and running relably soon - and that you can start enjoying it rather than running parity rebuilds all day and all night!

All's well that ends well.

 

Using RFSTOOL I managed to salvage the content of the problematic disk.  I then installed a new disk, added it to the adday and copied the old content onto it. 

 

Parity checks out ok.

 

I guess this crisis is now over with no ill side effects other then the too many hours I spent trying to isolate the problem.

 

Thanks again to all those that helped.

 

It is very odd that this drive was causing all these parity errors yet you were able to access the drive and copy the contents using RFSTOOL.

 

I'm just glad you are up and running again!

It is very odd that this drive was causing all these parity errors yet you were able to access the drive and copy the contents using RFSTOOL.

 

I'm just glad you are up and running again!

Remember, it did not cause errors, just when read produced inconsistent data. 

 

Who knows the actual cause... it could be it likes the power supply in the PC better, or the SATA controller, or the way the cable was routed gave less noise... 

 

It really does not matter.  That disk is obviously borderline and deserving of an RMA. 

 

Glad you were able to get to the data.  I hope it is correct or you can verify from the original DVD, etc the correctness.

 

Joe L.