#SCSI bad sectors
4 messages in this thread
don,
About a year ago you helped me out with a HD problem and posted a formula
for determine what sector went south (which Mark Bowser later built a
utility around). I seem to remember a comment about not knowing if it was
applicable to SCSI disks or not.
Have you determined if it works on them yet? (2090A control quantum 105)
thanx
lGlamb
Larry,
No, it doesn't work on SCSI disks…for a simple reason. When the
program "asks" for sector 123, the controller on the drive can give any
sector on the drive. Part of the SCSI "standard" is that the controller on
the drive can re-map any sector to any other sector on the disk.
(this presumes the drive manufacturer has implemented this option,
some haven't…to the best of my knowledge…Quantum has)
This remapping can occur during a normal write operation or during
the low level format (again…depending on the actual command used to the
controller on the disk). It normally will not occur on a read operation,
since if the drive can't read a sector…it has no way to re-create the
data and remap it to a good sector.
There's a program in LIB 13 called HDTEST.LZH that I wrote, it's a
quick and dirty test program that is intended for ST506 type hard drives,
but will work with any drive (including floppies). In the case of a SCSI
drive, while it will report a cylinder, head and byte offset…these
numbers can NOT be trusted. But it will at least tell you that you in
fact, have a bad sector on the disk. If you get no errors, the disk
controller is able to read all the sectors on the disk.
The test program doesn't care about, or use the FileSystem, so
while it may be able to read the data…the filesystem (DOS) may not be
able to understand it (corrupt data problem). A simple re-format will fix
that problem.
If the test program shows errors, there's another program in LIB 14
called SFMT.ARC (which I also wrote) that will ATTEMPT a low level format
of the drive. It tells the drive to re-format and map out any bad sectors
it finds during the format. After that, an AmigaDOS format should be done.
Be aware, a low level format can take quite a while for a large
drive, 20 to 30 minutes on a 300 Meg drive would not be unusual.
Don
I was vaguely aware that something like this remapping by the drive could
happen but kinda hoped there was an easy way around it.
As it turns out, I got lucky. The problem appears not to have been
hardware but with the utility I was using. See if this makes sense to you.
I'm doing a copy using UtilMaster (v.66) and it bombs out with and address
error on a very long pathname (I'm now able to duplicate this back on the
506 so the SCSI is cleared). ..Now comes the disturbing part.. IF I'm
doing some other disk operation in another task (like an unzip), Sometimes
the disk gets left in a state that won't validate on reboot.
I just ran your HDTest and found 0 errors which is nice since as I
previously indicated the SFMT routine did not work with my
2090A/Quantum105.
This UtilMaster problem is avoidable and generally recoverable so I'm
breathing easier again but I'm left a bit worried that this disk is that
susceptible to software problems.
Oh and one last related question. On hard power up (external switch to
entire bench) the DH2 partition of the SCSI isn't mounting but on a reboot
it comes up fine. Do these SCSI drives take that long to register and
should I somehow/where slow down my startup sequence to give it time to do
so?
Thanks for all the help again. lGlamb
Larry,
Yes, some drives take quite a while to respond on a cold boot. If
you're autobooting…there's really no way to slow things down. If you're
using Binddrivers, you could add a wait of about 10 seconds prior to the
binddrivers command and see if that helps.
The disk isn't susceptible to software problems…the software
itself is written wrong, so that it's causing a lockup. For example, a
software program could change the contents of a disk buffer before it's
written out to disk…thus invalidating the data…and possibly
invalidating the disk drive.
If you directory utility has problems with long pathnames, it
sounds like it has a fixed size buffer for a pathname, and the pathname
you're giving it is long than that fixed buffer. If the computer is told
to write 300 bytes to a buffer (or array if you prefer) that's only 200
bytes long…it'll gladly do it…and overwrite whatever is in that next
100 bytes in memory. If that next 100 bytes is program code…suddenly
your program code is changed into junk…and the computer crashes. If that
next 100 bytes is part of some other program in memory…that program may
crash, or become corrupted.
Don