#Hard drive "oscillates"!
33 messages in this thread
I seem to be having a strange problem with my hard drive. For months it
will work perfectly. However, every so often, the read/write head will
begin to sound like it's oscillating. It sounds like the head is vibrating
back and forth between adjacent cylinders. The oscillations start out
minor. They only happen occasionally, and stop after a minute or so.
However, after a few days, they become more and more common. It eventually
reaches the point where almost every hard drive access causes it. When
this point is reached, the oscillations can only be stopped by accessing
the hard drive a second time (or a third time or a fourth time…). After
two weeks or so of this, the oscillations will suddenly stop, and the hard
drive will work perfectly for another six motths.
Sometimes the oscillations occur right after a disk access, and other
times they begin DURING the access. When the oscillations occur during an
access, hard drive access is slowed considerably. The speed is comparable
to when two different programs are accessing the same drive at the same
time.
I'm using a 100 meg Quantum hard drive installed on a Supra WordSync
interface, inside an Amiga 2000. I have no other expansion boards in the
machine, and a single floppy drive. Curiously, this problem never occurred
until I installed Kickstart 2.04. I'm not sure whether I'm using the
ROM-based or the disk-based Fast File System, but since I never used
HDToolbox to change my Rigid Disk Block, I suspect that I'm using the
disk-based FFS. (I'm not sure if this is related, but whenever I run
HDToolbox it tells me that "Some drives have been added or removed from the
system " and that I should select "Save Changes to Drive." It then shows
the status of my hard drive as "Changed". I haven't selected "Save" yet
because I don't know what the result will be.) I'm using version 1.10 of
the Series II Supra software.
— Matthew Rimer
73500, 1167
Matt,
You might want to contact Supra about this, what it sounds like, is
read errors on the drive requiring retries. Does it by any chance occur
when running any particular software…so that the drive is accessing a
specific portion of the drive?
Don
Don,
I don't think it occurs when running any particular program.
Sometimes, it seems like running a certain program causes it to start, but
once it has started oscillitating, the problem continues for several weeks,
no matter what software I run. Indeed, it happens on both of my partitions
simultaneously. I've noticed that it tends to happen alot when I open
drawers on the Workbench, or (less frequently) when listing directories in
a shell or in a file requester. However, it also happens when I load
software.
If it is a read error, will doing a low-level format help?
— Matt Rimer
73500,1167
Matt,
Yes…doing a low level (and then AmigaDOS level) format will help
if it's having problems reading. Of course, make a backup first!
Don
Don,
I'll try a low-level format. But before I go to that much trouble (I
have a 100 meg hard drive and no tape backup drive 🙁 ), I noticed that I
have Blind Reads enabled. Is there a chance that disabling them will help?
— Matt Rimer
Matthew,
No idea…never heard of "blind reads" before…that must be
something specific to the Supra.
Don
blind reads probably are not the problem. blind just means rapid
'pipelining' of drive commands without error checking each one. blind reads
are kosher, blind writes are a no-no! Some older controllers implemented
'this 'non-handshaked' read or write capability (my old Trumpcard did
before the TrumpCardPro replaced it). What makes you think that a new low
level format is in any way related to solving Matt's problem?
Dan,
Head thrashing generally means the drive is doing lots of retries
(or the system is requesting lots of retries). One thing that can cause
that is the drive mechanically becoming slightly out of alignment (due to
age) and a low leve format can cure that. I've seen similar problems on
drives at work, and a low level format fixed it. The drives at work were
SCSI drives attached to minis.
It's certainly not the only thing though that can cause it.
As I said in my message…I wasn't aware of what blind reads were.
Now one place you say they're non-error correcting and in another you say
there is no handshakeing. Those are two different concepts…which did you
really mean?
Don
I meant non-handshaking, at least in the case of IVS trumpcard (as
described to me by their tech folks way back when I was worried about it –
it is automatically handshaked now on all newer trumpcard pros). the
non-handshaking type of 'blind read' is semantically equivalent to my
simple understanding of things to saying 'non error checking'.
Blaq,
What price did you tend to see on the low end recorders, used. Where do
you find such a beast as a used TQ2022FC?
–Paul
i find them from time to time – just where is proprietary. if you
want me to I'll keep an eye open for one for you. Prices range in
the under $5000 vicinity. They're out there. Every now and then
someone upgrades from an older model and it becomes available, or a
dealer demo unit, or distributor overstock or …
Don,
Another thing that can cause hard drive "oscillations" is
recalibration. My Quantum did this when I first got it. Really freaked me
out the first couple of times it happened! The really spooky thing was, it
would start this all by itself. I would check the drive light, and it was
solidly off. If I accessed the drive somehow, say, by listing a directory,
the seeks would often stop, though not always. Oftentimes the drive would
start a recalibration when I accessed it, and it would take a couple of
tries to get it to stop. After I figured out what was probably going on, I
let it go, and finish what it was doing without interrupting it. It's been
almost three years now since I bought that drive (it's a Quantum Q40S), and
it hasn't done this for a couple of years now. The drive sounded like it
was doing a seek test of some sort (which is what a recalibration is, after
a fashion). The reason for recalibration happening is that the drive is
adapting itself to the ambient temperature, and thus the different
tolerances in platter sizes, head spacing, and so on.
Getting back to the question that started this thread, I'd suggest
that if the drive's access light is off when the drive is oscillating, then
it's probably a normal occurence. Like I said, mine used to do it, and
I've used that drive for a long time now, with *zero* trouble with it that
couldn't be traced to errant software (and precious little of that,
either). OTOH, if the light is ON, then there's probably a read problem
somewhere, and the drive should be backed up, and a bad block scan run over
it. I forget which software the original poster said he had, but most of
the software I've seen will automatically scan for bad blocks and mark
them. (I know Supra's and Nexus' software will, that's what I've got; I
think GVP's will, too.)
–dds Whappeta-whappeta-Whap!
Matthew,
Well, regarding your "blind reads" thing, I looked into my Supra Manual
and here is what it says:
"Blind Reads:
This gadget turns blind reads on and off. When blind reads are on, reading
from the drive is faster, but if the controller can not keep up with the
driver that initiates the the blind reads, the system will freeze or
generate read/write errors. By default, the blind reads option is on."
So, all I can say is go ahead and turn blind reads off. I don't see any
reason why it could hurt — just might slow the drive down some, tho. If
no success there, go ahead and maybe do a low level format (after a back up
of course!).
Also, I have found that "Blind Writes" when on causes more problems… so I
have left mine off.
Whap!ing it up –Mike Huttinger–
the usual word is to NEVER reformat a SCSI drive. Quantums and most others
are formatted at the factory and you MAY damage or decrease the drive's
performance (variable sectoring is common nowadays). If AmigaDos FORMAT
won't fix a problem, then maybe do a 'bad block scan' with the appropriate
controller/installation software. A low level format is probably very
unlikely to solve such a problem and it MIGHT make things worse. Perhaps
the Quantum is running out of block replacement space or is making frequent
references to its 'bad block' replacement area. I have no idea how any
normal use of a drive could cause need for a new low level format
operation.
If you're formatting a drive, you're losing any data that was there. I'd
think that low-level formatting is a good thing, no? If the drive was
developing troubles, wouldn't you want to know? Why would the ROM's own
formatting routines make things worse? Does the factory do anything more
than call the ROM formatting routines?
many newer scsi drives are formatted with special hardware (at least for
the 'low level' format) which provides for things like zone bit recording,
variable number of sectors per track, etc. I am not positive that simply
issuing the SCSI 'FORMAT' command to a drive can duplicate these aspects of
what makes many newer tech drives so FAST! There are also certain aspects
of bad block recognition which can conceivably be erased by a low-level
format. If the drive is used under almost any conceivable circumstances in
an AmigaDos environment there is absolutely NO possibility that the
low-level format can be affected by any AmigaDos reads/writes, BITmap
screwups, etc. If a AmigaDos format DOESN'T fix a screwed up drive, then
and only then, would I even consider doing a low-level format. I simply
don't believe the devices/drivers in today's controllers' rigid disk block
sections have the smarts to truly do a proper job of low-level formatting a
variable sectors per track drive. Anyone out there please correct me if
I'm wrong and I can learn a thing or two. Selling a lot of drives has
gotten me deep into studying how the good ones really work.
Hard drives are a complex gizmo, so I'm very open to learning, too. But to
get back to the original point, I don't think any drive manufacturer would
make a drive that could be damaged when a low-level format is requested.
not that it would be damaged, simply that the REAL low level format is
really only done on specialized equipment. as Brian said, the drive might
simply ignore any such request and report it as 'successful'. I'm still not
sure, but I don't know even if the latest drives are truly capable of
really doing a correct low-level format with zoned recording, etc.
Some early IDE's could….
Brian
– via Whap!
Dan,
You're wrong. While there are parameters you can change via the
MODE SELECT command, if you don't change them…then issuing a FORMAT UNIT
does nothing more than follow the manufacturer's instructions (build into
the on-board ROM) on how to do the low level format. The options to the
FORMAT UNIT allow you to feed it bad blocks, use the manufacturer's list or
use the "growing" list of defects found during use or a combination of the
above. The only other option is the interleave.
While yes, you can screw things up via the MODE SELECT parameters
or by changing the interleave via the FORMAT UNIT…these are parameters
you usually don't mess with.
And "you" in this case refers to the writer of the driver and
utility software. They're not commands a user can issue directly.
Don
thanks for the update. perhaps even these newer drives do have complete
formatting instructions in their roms, but most SCSI mfrs don't recommend
reformatting (low level) on new drives and there must be a reason why. I'm
curious.
Perhaps because you're dealing with the wrong manufacturers?
There are routines in the ROMs for doing zoned formats, etc.
The drives we use at work, from Conner, HP, CDC, Micropolis
and SeaGate all reccomend low level formatting before putting in use
to insure error free surfaces. The low level before use insures any
problems that may have occured during shipping are caught. Yes…they
all auto-park the heads, so in theory rough handling shouldn't damage
the read/write areas on the media…but the reccomendation still
exists.
Don
In point of fact, the drive usually won't LET you completely low-level it.
Some of them go as far as to IMMEDIATELY return an "operation complete"
status — without doing anything to the drive….
– via Whap!
point WELL taken – and that fact probably confirms my suspicions that truly
proper low level formatting of newer drives is purely a factory only
operation.
Dan,
I think you're thinking of an IDE drive, not a SCSI drive. Part of
the SCSI spec requires the drive at least acknowledge the FORMAT UNIT
command, and the vast majority of SCSI drives not only acknowledge it..but
do it.
The only way you can mark bad blocks on a SCSI drive is to add them
to the defect list via the FORMAT UNIT command. The on-unit ROM handles
the details of how to format the drive and the remapping of the sectors,
the only option to the user is the interleave value.
Don
Don,
I've got a Quantum and a Connor in my 3000. Using HDToolBox's low-level
format command, the Quantum returns immediately (as did the Wren I used to
have and you now have) and the the Connor really does the low-level
format. Not sure why, but as Dan said, some do, some don't. To mark bad
blocks I use QuarterBack Tools.
-sja
Steve,
Interesting….I ran the Wren thru the low level format program I
wrote a long time ago…and it took about 15 to 20 minutes to come back.
I wonder which options HDToolBox uses on the FORMAT UNIT that I
did/didn't use?
Don
Steve,
Oh…as to QBTools marking defective blocks…They're probably
marking them out via AmigaDOS rather than the low level method. There is
no 'mark bad block' command in the SCSI spec…it's part of the FORMAT UNIT
command.
Don
Don, there is a "Reassign Blocks" command (07h). This can be used to "map
out" bad sectors without reformating. Actually, it replaces sectors from
reserves.
Craig
Craig,
Humm … you're absolutely right….I wonder how I missed seeing it
before.
Opcode 07…REASSIGN BLOCKS and it's a required command…so if it's a SCSI
direct access unit…it's got to support it.
Sorry for the error.
Don
as Brian Cowan mentioned in one of his replies to me on this thread,
recognizing the SCSI FORMAT UNIT command doesn't mean the drive will even
actually do it – Brian mentions that some drives simply return a 'operation
successful' reply to such a command – and I think there are probably good
reasons why this is so especially on newer variable sectors per track
drives. I'm not even sure the heads are fully capable of resolving the
magnetic flux densities and detail required to properly format such drives.
You are right about IDE, these are all factory formatted, too, but I did
indeed mean to refer to SCSI as almost all (anyone correct me if they know
of a counterexample) stuff coming out now is indeed factory 'low level'
formatted. I believe most newer scsi drives AUTOMATICALLY recognize bad
sectors whenever encountered and remap them completely transparently to the
user and completely independently of the low level format process. This is
certainly the implication of much of the manufacturer info I've been
getting on newer drives. I think the on-board smarts are much smarter
these days than the SCSI standard requires. The drives are much much more
sophisticated and faster than even two years ago. The new technology I'm
encountering as I try to keep up to stay competent at selling drives
intelligently is extraordinary! There is more there than meets the eye.
Dan,
While, yes, it's true that some units immediately return a
successful completion op code…it's also true that the vast majority of
them will actually do the low level format. As an example (I thought I
gave it before…didn't you read it?)…I've got two different versions of
the Conner CP-340 (admittedly an older drive). One specifically designed
for (and sold only to) Apple for use on the Mac, and one OEM'ed to AT&T for
use in a mini. The Mac style won't low level format, the AT&T style will.
At work, we've got CDC, SeaGate, HP, Micropolis and other SCSI
drives, they all will do a low level format when properly commanded to do
so.
As to automatic re-mapping…generally it depends on the driver
software rather than the on-drive ROM firmware. For obvious reasons…you
may not want a read error automatically remapped; whereas, on a write
error, you may want that automatically remapped. But then again, you may
not want write errors automatically covered.
Don
Matt:
Why not back up your entire drive, reformat and then do a restore. If your
drive has been in use for some time, the data has probably become very
fragmented, and that not only decreases access times, but makes the drive
WORK much harder to find data. By defragmenting the drive, it won't have
to work as hard.
If you do this, after you've made your backup, be sure to check for bad
blocks before you do your normal AmiagDos format.
Michael
…..on AutoPilot