SCO and hard disk errors

[William Mattil]

root at libove.UUCP (The Super User) writes:
>
>I have SCO Xenix 2.2.1 running on an IBM PC/AT clone (made by PCs Limited)
>and it has a Seagate Technologies ST4096 (80 megabyte) hard drive as the
>root device, with a ST4026 (20 megabyte) mounted secondary filesystem.
>
>The 20 meg drive has no flaws, but the 80 meg drive has a few bad tracks.
>The Xenix bad track (badtrk) utility does not mark them all; it, like all
>Xenix programs that use disk devices lets the kernel absorb a great deal
>of bad returns before accepting something as bad - something that causes
>a great deal of trouble with floppies - the Xenix utilities will often
>write to a bad spot on a floppy (assuming that it *will* hold out, instead
>of the more likely case that it will *not*) ... but anyway...
>
>So, often I am running something disk intensive and the system starts
>thrashing; that is, I hear the hard drive making its characteristic "seek
>to root, attempt to seek to target sector again" noise.
>
>My solution is to back up everything and reformat the drive with a utility
>that really checks out for bad blocks, and marks them as unusable. Who
>cares about the extra megabyte I lose if it keeps potential explosions from
>happenning (and keeps that awful wait during recalibration from occurring).
>
>The point of this post, anyhow, is to ask if anyone else has experienced
>this type of behaviour, or has any opinions on SCO's disk drive device
>drivers. Perhaps we could convince SCO to go a little more conservative
>on the drivers' retry attempts...
>


This can always be a problem. I strongly suggest that once bad tracks have
been determined, you enter them manually. Always include the bad tracks that
are marked on the drive itself. When I low-level format the drive(s) I include
the bad track data there too. When installing Xenix, it asks if you would like
to enter bad tracks. Thats the time to do so. If you doubt the reliability of
the drive you can have it check by any competent disk repair house. When they
return the drive they will include a hard/soft error map. I enter all of these
tracks as bad. This seems to work for me.


UUCP: {ihnp4!scgvaxd!cadovax rutgers!marque}!gryphon!pnet02!wrm
UUCP: {hplabs!felix, crash}!telcomm!wrm
INET: wrm at pnet02.cts.com