Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Sep 2000 16:02:10 -0600
From:      Warner Losh <imp@village.org>
To:        Edward Elhauge <ee@uncanny.net>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG
Subject:   Re: Frustration with SCSI system 
Message-ID:  <200009202202.QAA50356@harmony.village.org>
In-Reply-To: Your message of "Wed, 20 Sep 2000 12:58:27 PDT." <200009201958.MAA45703@ns2.uncanny.net> 
References:  <200009201958.MAA45703@ns2.uncanny.net>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200009201958.MAA45703@ns2.uncanny.net> Edward Elhauge writes:
: to autorecover on bad sectors, but every system that I've had to recover
: seems to be in a state where the bad sectors aren't remapping. I've tried

I've often wanted to write a bad block remapper.  While SCSI is
supposed to do this automatically, I've found that a scan on any
adaptec controller will remap these blocks (forces the remapping).
About 10% of the time that's all a drive with this problem needs to
survive indefinitely.  The other 90% of the time the disk is about to
go tits up in a heap big time way and warrantee replacement is
recommended.  About 75% of the time a rescan + immmediate dump will
save me.

I've had 2 disks that seem to have lost their bad block mappings that
the adaptec verify function has saved me from sending them back (they
were out of warantee anyway).  However, on the other 20ish disks I've
tried this on have died within days of doing this.

Even if we had bad144 support, the drive will need so many bad blocks
remapped in a short period of time that it isn't worth while.

Finally, I've found that climate controlled and dust free environments
help a lot.  RAID hardware/software is definitely the right way to
deal when you go to the next level.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009202202.QAA50356>