So I did an parity check last night and it completed with a ton of errors.

 

(Last checked on 12/11/2006 9:32:53 AM, finding 1333 errors.)

 

There are no errors on any of the individual drives.  The syslog looks like this:

Dec 11 02:10:28 Tower emhttp[1195]: driver cmd: check
Dec 11 02:10:28 Tower kernel: mdcmd (23506): check
Dec 11 02:10:28 Tower kernel: md: recovery thread got woken up ...
Dec 11 02:10:28 Tower kernel: md: recovery thread checking parity...
Dec 11 02:10:28 Tower kernel: md: writing superblock to /boot/config/super.dat
Dec 11 02:10:28 Tower kernel: md: using 256k window, over a total of 390711352 blocks.
Dec 11 04:51:26 Tower kernel: ata4: command 0x25 timeout, stat 0x50 host_stat 0x22
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886144
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886152
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886160
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886168
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886176
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886184
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886192
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886200
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886208
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886216
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886224
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886232
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886240
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886248
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886256
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886264
Dec 11 04:51:26 Tower kernel: md0: parity incorrect: 275886272
Dec 11 04:52:06 Tower kernel: ata4: command 0x25 timeout, stat 0x50 host_stat 0x21

 

The "parity incorrect" errors continue on with different numbers and in between occasionally are the "timeout errors".  They end with either 0x21 or 0x22.  No other errors or messages to speak of.

 

Any idea what is going on here?  Should I be worried?

 

Thanks.

"command 0x25" is SCSI Read Capacity, ie, command to read the size of the hard drive.  This is probably being issued as part of error recovery by the linux SATA driver.  Seems odd that no other errors are getting reported.  If possible, run the parity-check again and send the syslog to [email protected].

Tom,

 

Did you get my mail with the syslog?

 

No.

Yeah, I just got a bounce back.  I re-sent it.

 

I also found out that I could access the gui after some time and that there was a drive with 140 errors on it.  I swapped it and restarted the rebuild but now I am getting the same 2 errors in the syslog during the re-build.  I just checked all my cables and power and they are fine.

 

Got it.  Looks like disk10 is the culprit.  Is this the one you replaced?

Indeed it was.

 

In fact after I replaced it I got the errors on the rebuild with the new drive as well.  That is when I re-seated the cables and since then I restarted the rebuild and it has been going for 40 minutes without an error.  After I get the drive re-built on the array, I will run an exhaustive check on the old one in another system.  I have a feeling that it will actually check out ok and that cabling was the issue all along.

 

If that turns out to be the case I may need to put a small bit of rubber cement on my SATA connectors to keep them in place. 

 

Anyone know of any LOCKING sata cables by any chance?

 

Thanks Tom.

 

Indeed it was.

 

In fact after I replaced it I got the errors on the rebuild with the new drive as well.  That is when I re-seated the cables and since then I restarted the rebuild and it has been going for 40 minutes without an error.  After I get the drive re-built on the array, I will run an exhaustive check on the old one in another system.  I have a feeling that it will actually check out ok and that cabling was the issue all along.

 

If that turns out to be the case I may need to put a small bit of rubber cement on my SATA connectors to keep them in place.

Yes, the SATA connector design is amazingly bad; almost as bad as HDMI connector design 

 

Anyone know of any LOCKING sata cables by any chance?

As a matter of fact here's one.  Note that not all SATA hardware supports the latching mechanism.

 

OK, ordered some locking SATA cables from newegg.  The ones I bought will work in non-locking connectors and it seems that most of my seagates will support them.

 

My (Almost) Data Loss Situation

 

So the sequence of events that happened to me worries me quite a bit.  Here is what happened.  Step By Step.

 

1. Array seems fine, no errors on the main page, and no problems accessing data (as far as I know). 

2. Ran a parity check overnight.  Page came back and said I had thousands of errors.  Posted here and re-ran parity again per Tom.

3. This time I have a drive that has errors after the check, Number 10,  The array was stopped automatically by unraid.

 

Note: At this point, I think the parity data was BAD.  The loose cable had cause read errors which the parity check (incorrectly) corrected so the parity stored on my parity drive was wrong.

 

4. I replaced drive 10 and started a rebuild which immediately produced the same errors in the syslog as before (See the title of this thread).  That let me to think there was another issue and the drive was not at fault.

5.  I re-seated ALL cables and restarted the rebuild on the new drive which completed without errors.

6.  After the rebuild was complete, I checked the files on drive 10 against some CRC's I had stored and many files were corrupt.

Note:  This is because the drive was re-built using BAD parity data.  The bad data was generated when I ran the parity check.

 

7.  After I'd replaced the old Drive 10, above, I put it into another machine and ran an extensive surface check followed by a ResierFS filesystem check.  Both came out OK.

8.  I put the OLD disk 10 in my XP PC and using YaRG copied several of the files that had been corrupted to my windows drive.  I ran the verify against them and they checked out OK.

 

Note:  So my supposition above was correct.  The drive was NEVER really bad, only the cabling.

 

9.  At this point I removed the NEW drive 10 and put in the OLD drive 10 and I am now rebuilding parity from scratch.

 

Sooooo....

 

My concern is that parity check is a BAD thing sometimes.  If a problem is not identified with a drive (or in this case, the cable) BEFORE running parity check then the check will INVALIDATE the parity.  Had the drive been truly bad then I would have lost data because running parity check would have ruined the only chance I would have had to rebuild the drive.

 

This brings up a question:

 

Can there be a READ ONLY parity check?  One that only CHECKS the parity to see if it valid rather than CORRECTS the parity if it is not?

Can there be a READ ONLY parity check?  One that only CHECKS the parity to see if it valid rather than CORRECTS the parity if it is not?

 

This is a great suggestion. You should put this in the Feature Requests section.

Put on the list:

 

- add option to let Parity Check be a true 'check', ie, don't write corrected data, just report occurrences of sync error(s)