[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

631.0. "Interesting reading?" by Z::TENNY (Dave Tenny | DTN 225-6089) Tue Aug 04 1987 17:49

                <<< DUA1:[TENNY.USENET]COMP_SYS_AMIGA.NOTE;1 >>>
                      -< Usenet Comp.Sys.Amiga postings >-
================================================================================
Note 735.0                Close Call (Supra hard drive)                5 replies
Z::TENNY "crash!mercurio"                           110 lines   4-AUG-1987 10:09
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!decvax!ucbvax!ucbcad!ames!hao!gatech!mcnc!ece-csc!ncrcae!ncr-sd!crash!mercurio
Subject: Close Call (Supra hard drive)
Posted: 14 Jul 87 19:05:05 GMT
Organization: Crash TS, San Diego, CA
 
[-]
 
 
The following is a description of a close call I had with my 20 MB
Supra hard disk on my Amiga.  Warning:  those of you with queasy
stomachs, who lie awake at night worrying about how thoroughly you've
backed up your hard disk, may find the material below distressing.
I will attempt to alleviate the suspense, however, by revealing now
that there is a happy ending.  I should also mention that this is
a tad long-winded.
 
 
First, I should describe my hardware configuration.  I have an old
Amiga 1000 (acquired in Sept. '85) with a 20 MB Supradrive, an
ASDG Minirack-C containing a 2 MB memory board plugged into the Supra
controller's bus connector, and two external 3.5" drives (I have a
long desk).  All of what I describe occurred under Kickstart/Workbench 
1.2.
 
Last night, a friend and I were attempting to use Carolyn Scheppner's
wonderful Cmd program to generate a printout that we would later 
send to an HP LaserJet.  We were using my PagePrint1.3 program (available
on DevDisk0005), which pretty-prints C source, and both the C file being
printed and the printer image file being generated by Cmd were on my Supra
hard disk (in different directories).  PagePrint accesses the printer by
Open()'ing "prt:" -- nothing magical going on here.  After a few seconds of
disk activity, the system froze (no Guru, just an unresponsive system).
This didn't really bother us, since a screen grabbing program (Snatch, part
of the commercially available WindowPrint) we'd been using earlier had been
crashing repeatedly.
 
We administer the Amiga/Vulcan nerve pinch (CTRL-Ah-Ah) and the system
reboots.  The first command in my Startup-Sequence is Supramount, as
it should be.  Upon the attempt to be mounted, the Supra starts blinking
its busy light madly and continuously (it normally mounts in a second
or so).  This went on for several seconds, maybe a minute, before my
friend and I realized something was not right.  We rebooted again, and
again the system seemed to get stuck attempting to mount the drive,
blinking that little busy light until the cows come home (there aren't
many cows here in San Diego -- I'm from Chicago, where cows have been
known to cause trouble in the past).
 
We attempted to boot off of a standard 1.2 Workbench disk (which does
not attempt to mount the drive), and it came up fine.  We edited the
Startup-Sequence on my Workbench to remove just the Supramount command
and booted from that disk -- no problems.  Attempting to mount the
drive again caused it to busy loop, again.
 
We rebooted again, this time shutting the power to the entire system off
before it knew what hit it.  We waited about 10 seconds, then turned the
power back on (I have everything plugged into one power strip so I can turn
everything on at once -- this has been working fine for months).  The
system kickstarted properly, but again busy looped at the attempt to
mount the drive.
 
This was starting to look serious.  Although I was reasonably well backed
up, I had no desire to reformat and reconstruct an 85% full 20 MB disk.
We had begun to suspect that the Supra was taking the initiative and
attempting the reformatting for me.
 
It was clearly time for action.  We had one observation upon which we
could base a decision:  the pattern of blinking of the busy light
demonstrated a small amount of variability -- signs of life!  I
consulted with my friend, Phil Cohen, whose wisdom I have sought out
and deferred to since we worked together at UCSD 9 years ago.  He'd
been witness to this entire melodrama.  We decided that the drive
probably either knew what it was doing, or else all was lost anyway.
We decided to attempt to mount the drive again, and this time, to
wait until the busy light stopped blinking.
 
So we waited, and we waited, and then we waited some more.  If this 
were a 1940's black-and-white movie, the hands of an analog clock would 
be seen advancing at many times their normal rate, then the pages
of a calendar would begin to tear off and flutter away.  Seasons
would change, the frost would melt, springtime birds would begin to
chirp ... sorry, I get carried away.  Seriously, I was too distraught
to think to time anything, but I would estimate that the light blinked
for over 5 minutes.  Occasionally, it would pause for a second or
two, then continue.
 
And then, it stopped.  
 
I gingerly approached the keyboard to cd to dh0: -- it was there!
I checked out a few important directories -- all there.  I did an
info -- the hard disk was as full as I had expected it to be.  We
toasted our good fortune and began backing up everything in sight.
 
And I've had no problems since then.  It ran flawlessly for several
hours more that night, and is still humming along this morning.  The
damn thing actually healed itself.
 
I have no idea why this occurred in the first place, and I have no
desire to attempt to replicate it.  I don't think the fault lies
with either Scheppner's Cmd or with my PagePrint, but rather with
the Supra itself.  But then, it did fix itself, so it's hard to
complain.  All in all, I'm pleased with the Supra's performance,
and would chalk this up to either good design on Supra's part or
just plain dumb luck.
 
Phil Mercurio
DevWare, Inc.
 
mercurio@pnet01.CTS.COM     Usenet
mercurio                    PeopleLink or GEnie
================================================================================
Note 735.1                Close Call (Supra hard drive)                   1 of 5
Z::TENNY "COGSCI.BERKELEY.EDU!bryce"                 24 lines   4-AUG-1987 10:10
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!decvax!ucbvax!COGSCI.BERKELEY.EDU!bryce
Subject: Re: Close Call (Supra hard drive)
Posted: 15 Jul 87 06:06:58 GMT
Organization: 
 
Sounds sort of like the AmigaDOS disk "validator".  You described a
system crash and when things came up again the drive spent 5 minuites
blinking it's light.
If it's the validator then what happened was this:  The crash prevented
AmigaDOS from from perfroming a final update on the hard disk.  Next
time things where booted AmigaDOS noticed somehting "strange" and decided
to validate the ENTIRE disk.
 
AmigaDOS keeps a lot of links that can be used to reconstruct most of
even a badly mangled disk.  THIS IS A FEATURE!  If you happend to zap
the dual copies of the FAT on an IBM disk you be "up data creek without
any file links".  (Your data would be quite scrambled)
 
-----------------------------
|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."
================================================================================
Note 735.2                Close Call (Supra hard drive)                   2 of 5
Z::TENNY "pepper!cmcmanis"                           21 lines   4-AUG-1987 10:34
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!pyramid!oliveb!sun!pepper!cmcmanis
Subject: Re: Close Call (Supra hard drive)
Posted: 15 Jul 87 17:08:34 GMT
Organization: Sun Microsystems, Mountain View
 
Phil, and others who will inevitably have this happen to them. I believe 
you have witnessed the disk-validator in the flesh. You see when the
disk is being written to and hasn't finished the file yet, and the machine
crashes the disk has to be revalidated before AmigaDOS will trust it.
If this has happened to you on a full floppy you know that it took
nearly a minute to validate your 880K floppy, if it happened on your
20 meg hard disk, it doesn't take 20 minutes but it takes a good long
time. So yes, you will need to wait a while, and cross your fingers
and hope it doesn't say 'Disk structure Corrupt, Use DiskDoctor to 
correct it.' 
 
 
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
================================================================================
Note 735.3                Close Call (Supra hard drive)                   3 of 5
Z::TENNY "rocky!rokicki"                             21 lines   4-AUG-1987 10:49
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!labrea!rocky!rokicki
Subject: Re: Close Call (Supra hard drive)
Posted: 15 Jul 87 23:33:23 GMT
Organization: Stanford University Computer Science Department
 
SCSI drives fix themselves.  If your box crashes while doing
a write to the drive, the SCSI drive will play with itself
for a while until it repairs itself.  The time this takes is
dependent on the size of your disk partition; this is an
excellent reason to partition a hard disk.  Perhaps a 4MByte
development partition where you develop your most crash-prone
programs, so the box comes back up quickly.
 
Sometimes, as happened to my CLtd drive a long time ago, the
light never stops flashing.  (We are talking days here.)  Then
it's time to worry.  I turned the system off for a week, turned
it back on, and everything was back.  I sent the drive back to
CLtd anyway . . .
 
-tom
================================================================================
Note 735.4                Close Call (Supra hard drive)                   4 of 5
Z::TENNY "cbmvax!higgin"                             35 lines   4-AUG-1987 10:50
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!decvax!ucbvax!ucbcad!ames!husc6!uwvax!rutgers!cbmvax!higgin
Subject: Re: Close Call (Supra hard drive)
Posted: 15 Jul 87 18:23:23 GMT
Organization: Commodore Technology, West Chester, PA
 
In article <1385@crash.CTS.COM> mercurio@crash.CTS.COM (Phil Mercurio) writes:
$The following is a description of a close call I had with my 20 MB
$Supra hard disk on my Amiga.
$[...SNIP...]
$We decided to attempt to mount the drive again, and this time, to
$wait until the busy light stopped blinking. ...I would estimate that
$the light blinked for over 5 minutes.  And then, it stopped.
$I gingerly approached the keyboard to cd to dh0: -- it was there!
$I checked out a few important directories -- all there.  I did an
$info -- the hard disk was as full as I had expected it to be.
$Phil Mercurio
$DevWare, Inc.
 
What you had witnessed was simply the hard drive being VALIDATED by
AmigaDOS.  Since it was SOOOOO full, it took forever (well.. 5 minutes).
 
This was caused by the fact that the disk bitmap probably didn't
checksum correctly, and caused AmigaDOS to rebuild it.  And the bitmap
didn't checksum because a command had been writing to the disk when
the machine crashed so badly that DOS didn't have chance to finish
writing the critical information back to the drive.  But, thanks to
the redundancy in AmigaDOS, it is able to heal itself.
 
Ya know, some people complain about the poor performance of AmigaDOS,
but ask yourself something - have you ever lost a disk because of
the DOS?  In my experience it has ALWAYS been media failure, or
copy protection failure.
 
	Paul Higginbottom.
T.RTitleUserPersonal
Name
DateLines