3B1 Hard Disk Woes (Plea for HELP!)

John B. Milton jbm at uncle.UUCP
Mon Aug 7 10:53:45 AEST 1989


In article <1583 at mtunb.ATT.COM> jcm at mtunb.UUCP (was-John McMillan) writes:
>In article <580 at uncle.UUCP> jbm at uncle.UUCP (John B. Milton) writes:
>:
>> ...		 If so, it reads the existing BBT, formats the disk,
>>then re-writes the old BBT when the format is complete. The reason is obvious:
>>once a bad spot, always a bad spot. I, like most people would not like to give
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>a bad spot a second chance. If you want to dump the old BBT, you have to trash
>>the VHB to make the diag disk think it's a new, raw disk. The low level format
>>re-writes the ENTIRE track from index to index, gaps, headers, data, everything.
...
>     +	OK: there are also MEDIA defects.  And THESE are the BAD BLOCKS
>	which John was referring to, the ones we presume to be beyond
>	salvation.

I really did mean what I said. Perhaps I should have been more specific. What
I was referring to was places on the disk that are physically not responding
correctly. Many, many other things can go wrong that do not mesh with the "bad
data read, this must be a bad block" idea. The format routine on the diagnostics
disk was written for the user. It was written to find pre-existing bad spots
that are expected to be there. The diagnostics assume that the hardware is
functioning correctly. Remember, if it acts weird, you're supposed to call AT&T
service, right. My original comment was also made assuming your system is
functioning properly (or is now).

So is it time for a HwNote on what's REALLY on the disk and how disks work?

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!



More information about the Unix-pc.general mailing list