Date: Tue, 23 Mar 1999 19:32:42 -0600 From: David Kelly <dkelly@hiwaay.net> To: Greg Lehey <grog@lemis.com> Cc: Chris Piazza <cpiazza@home.net>, questions@FreeBSD.ORG Subject: Re: harddrive woes (!) Message-ID: <199903240132.TAA31044@nospam.hiwaay.net> In-Reply-To: Message from Greg Lehey <grog@lemis.com> of "Wed, 24 Mar 1999 08:53:27 %2B1030." <19990324085327.F425@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey writes: > > It has the 'low level format', of course ;). And this error has survived > > through that. > > It's not much of a low level format if it doesn't detect unrecoverable > defects. There's a program called bad144 which we used to use for MFM > drives; you might like to investigate whether it can help you. We're talking PC hardware here. Just because there is a "feature" in the BIOS doesn't mean it works. Or even does anything. To deal with bad blocks on IDE drives one must aquire tools from the drive maker. Supposedly the drive will map out bad blocks when they are going bad, before they really do. But once again, we're talking about PC hardware, where "cheap" wins over "quality" every time. Rather than bad144(8), badsect(8) has worked quite well for me in the past when a no-name IDE drive contained a bad block and wouldn't fix itself. Sneaky badsect creates a file which contains your bad sector. As long as this file exists nobody else will try to use your bad block. Don't think its implemented, but it would be nice if dump(1) knew about badsect(8) and would skip these "files" automatically. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903240132.TAA31044>