🚀 go-pugleaf

I just installed a Seagate ST-251 (40 MB) drive in my PAL Jr. expansion box
(Remember it?  I bought it just before Byte-by-Byte stopped making them, also
just before I found out my Ami 1000 was obsolete.)  Well, the PAL Jr. has
performed very well with the original MicroScience 20 MB drive, but I found
myself spending too much time rolling things on/off floppy disks.  Thus the
ST-251 ($335 from The Computer Terminal + $33.50 lifetime warranty). 

The "problem" I'm about to describe is essentially a perceived substantial
increase in seek activity.  I say "perceived" since I have no measurements
to back up my claim.  However, last night I did observe a phenomenon much
like David Childs (right name?) observed with his system.  While restoring
files to the hard disk, large files seemed to create a very intense period
of seek activity.  During the copy of one file (mg2a, to be exact - about
97K bytes), my system appeared to lock up.  Workbench windows were held in
suspension (no icons appeared).  Once the copy completed, everything went
back to normal.  

Each time I invoke a disk-resident command, there is a long (.25 - .5 seconds)
period of seek activity with a very distinct "audio" pattern to it (I think
you know what I mean - the mechanical noises emanating from the disk have a
recognizable/repeating pattern).  Here's an attempt (somewhat silly, I agree)
to recreate it in text:

---burst1---|---burst2-----------|----bumpetybumpetybumpetybumpety---|

The above representation is not drawn to scale :-).  Burst 1 is quite short
and has a sort of "low frequency" characteristic.  Burst 2 is about twice
as long as burst 1 and has a higher frequency characteristic.  Each of these
sounds like the head is jumping back and forth between the same two tracks,
a little like machine gun fire.  The "bumpeties" at the end of the sequence
sound like random thrashing.  This is all followed by the loading of the
application which proceeds in what I would characterize as "normal" disk
activity.  Subsequent invocations of the same program do exhibit lessened
amounts of disk activity (apparently due to caching a la AddBuffers).  I
did a "Path Reset" and invoked commands known to be in my C: directory to
see if it was a result of directory scanning - no change.  I also tried
explicit pathname invocation (e.g. bin/mg) - no change.

....Technical details....

The disk came with a data sheet with test results and a list of eight bad
blocks:

HD  CYL    MFM BFI   HITS
0    22    8771      8
2   760    8089      8
3    33    8710      40
3   699    1755      30
4   426    9249      8
4   627    2094      21
5   659    4222      38
5   660    4220      33

I've included the bad block list info in case anyone might spot a collision
with trackdisk specific requirements (where are the root block and bitmap
blocks on this disk?).

I did the low-level format, specifying 820 cylinders, 6 surfaces, 1:1
interleave and head parking zone at cylinder 821.  Nothing unusual occurred
during the (very long) formatting process.  This was done with a program
supplied by Byte-by-Byte, named "hdtest".  Indeed, the blocks described as
bad showed up as bad during the formatting and test run.  Oh yeah - I did
map out the bad blocks.
 
There was a tense moment when I re-booted and the system complained that it
couldn't find DH0:.  I didn't panic, however.  Instead I RTFM (past tense)
and was reminded to do the high level format.  I knew that :-)!  Everything 
went fine after that, with the exception of the "condition" I am describing.

If you're still reading, thanks for being patient.  If you've had similar
experiences and have either an explanation or a solution, please share your
discoveries with me.  You don't have to be a PAL Jr. owner (hell - I'd never
hear from anybody!).  Is there a disk activity monitoring tool I can use to
"watch" disk accesses and determine the reason for this possibly strange
behavior?  I'm not too concerned with data reliability at this point, but
if I've done something obviously wrong, I'd like to undo it before I commit
large quantities of development stuff to this new disk.  The thought of
going through another backup/restore cycle is depressing (gotta' rewrite
MRBackup!!! :-).

	Thanks in advance,
		Mark

-- 
< Mark R. Rinfret,  mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr    >
< AMA / HyperView Systems               Home: 401-846-7639                   >
< 28 Jacome Way                         Work: 401-849-9930 x301              >
< Middletown, RI 02840          	"If I just had a little more time...">