On Thu, May 03, 2007 at 11:13:06PM -0400, Louis Guillaume wrote:
> Manuel Bouyer wrote:
> > On Fri, Apr 27, 2007 at 12:42:18PM -0400, Louis Guillaume wrote:
> >> Hi,
> >>
> >> Can anyone help interpret this message?
> >>
> >> sd1(esiop1:0:0:0):  Check Condition on CDB: 0x28 00 02 6f 65 83 00 00 04 00
> >>     SENSE KEY:  Media Error
> >>    INFO FIELD:  40854918
> >>      ASC/ASCQ:  Read Retries Exhausted
> >>          SKSV:  Actual Retry Count: 63
> >>
> >> raid1: IO Error.  Marking /dev/sd1a as failed.
> >>
> >>
> >> I know it means that netbsd had problems writing to this drive, but how
> >> can I research to figure out if there's something wrong with the drive
> >> itself?
> >>
> >> The drive does not show any grown defects. I wonder if there may have
> >> been a raidframe or filesystem or driver issue that could have caused this.
> > 
> > It's definitively a drive issue; it properly reported an internal error
> > condition. It's not a write, but a read wich caused the issue ("Read Retries
> > Exhausted", and 0x28 is a "READ 10" command). If the drive does auto bad
> > block remapping you can just try rebuilding the raid:
> > raidctl -v -R /dev/sd1a raidx
> > rewriting the bad block should remap it.
> > If not, try
> > scsictl sd1 remap 40854918
> > before the raidctl
> > 
> 
> 
> 
> Thanks, this is very useful.
> 
> After reading the drive's manual it appears that it supports automatic
> block reassignment on failed reads. So I've gone ahead and brought the
> component back into the RAID.
> 
> But how can I tell if the block got remapped? The grown defects list is
> still empty.

If the read failed it can't remap it. I guess it remaps when the read succeeded
with ECC correction, of after some numbers of retries.
It probably supports remapping on write too, so the RAID rebuild should
make it happen.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--