Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!cca!mirror!rayssd!galaxia!amanpt1!mrr From: mrr@amanpt1.zone1.com (Mark Rinfret) Newsgroups: comp.sys.amiga.tech Subject: ST-251 in a PAL Jr. Keywords: disk,odd behavior Message-ID: <476@amanpt1.zone1.com> Date: 18 Jun 88 13:45:56 GMT Organization: Aquidneck Management Associates Lines: 88 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...">