Michael Mansour wrote:
> Hi Ioannis,
> 
> 
>>  ---------------------- pam_unix End -------------------------
>>
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>Jan  4 11:16:41 hdc: dma_intr: status=0x51 { DriveReady SeekComplete 
>>Error }
>>Jan  4 11:16:41 hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> 
> I've been away for the past few days so haven't been able to contribute to
> this discussion, but from what I've read on replies to your issue above, I
> feel there's just too many saying to turf the disk, and I'd personally
> recommend against it until you have verified the disk is actually faulty.
> 
> I have been involved in smartmontools and on their mailing list for years, so
> know that the errors above do not (and should not) direct you to replacing the
> disk without you first trying to correct it.
> 
> Your query may have been better directed to the smartmontools mailing list
> (maybe it's an idea to join it for your current issue or just search their
> archives), where they would have directed you to a good starting resource:
> 
> http://smartmontools.sourceforge.net/BadBlockHowTo.txt
> 
> I have had many disks give me the same issue as you've had, and have corrected
> them using the methods described in the above link, or simply by zeroing them
> (to force re-allocation of sectors) and then re-adding them to my mirrors. At
> that point, they continue to work flawlessly again. I've done this for years,
> and have yet to actually turf a disk because of the errors you're currently
> getting.


Thanks for the link Michael. Actually this type of error *email* message is very rare (I 
must have seen it 2-4 times since July).


There are others more common (and probably meaning nothing), like this I have just received:


  ################### LogWatch 5.2.2 (06/23/04) ####################
        Processing Initiated: Mon Jan  9 01:54:43 2006
        Date Range Processed: yesterday
      Detail Level of Output: 0
           Logfiles for Host: localhost.localdomain
  ################################################################

  --------------------- Cron Begin ------------------------

**Unmatched Entries**
STARTUP (V5.0)

  ---------------------- Cron End -------------------------


  --------------------- pam_unix Begin ------------------------

crond:
    Unknown Entries:
       session closed for user root: 28 Time(s)
       session opened for user root by (uid=0): 28 Time(s)


  ---------------------- pam_unix End -------------------------


  --------------------- Connections (secure-log) Begin ------------------------


**Unmatched Entries**
userhelper[5479]: running '/sbin/poweroff' with root privileges on behalf of 'root'
userhelper[3698]: running '/sbin/poweroff' with root privileges on behalf of 'root'

  ---------------------- Connections (secure-log) End -------------------------



------------------ Disk Space --------------------

/dev/mapper/VolGroup00-LogVol00
                        99G  9.4G   85G  11% /
/dev/hdc1              99M   12M   82M  13% /boot


  ###################### LogWatch End #########################




In any case, I suppose ext3 takes care of bad sectors automatically, if present.