Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!rutgers!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga
Subject: Re: A2090 question
Keywords: A2090
Message-ID: <3119@cbmvax.UUCP>
Date: 11 Jan 88 14:03:45 GMT
References: <4938@well.UUCP>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 38

In article <4938@well.UUCP> sjm@well.UUCP (Stephen Moehle) writes:
>
>
>     I am quite puzzled by the behaviour of my new A2090 hard disk controller
>card.  Whenever I write to the disk, about two seconds later the disk is 
>accessed again.  This I take it is the Disk Validator (DV) in action.  So far
>so good.  What is bothering me is that when the DV is doing whatever it does 
>the display freezes.  Nothing is drawn to screen.  This lasts for only a 
>second but is quite anoying.  Is this normal, i.e am I going to have to learn 
>to live with it?  Perhaps a CATS person could explain it to me.  By the way, I 
>have a B2000 rev 4.2, 3 Megs of memory, 2 floppies, and one ST506 hard disk.  
>Thanks. 
>
>Stephe 
There are 2 cases where the disk can be accessed after you have done a write
to a file.  In the first case, it is the Filesystem that's doing the write.
When you open a new file and write to it, the bitmap on disk is invalidated.
After 3 seconds, if no more disk requests have been made, the filesystem will
write the rootblock and affected bitmap blocks back to disk.  There's no point
writing them if there is still disk activity going on, hence the 3 second
timeout.  Actually, this brings to mind a word of warning, don't reboot your
amiga within 3 seconds of writing to your hard disk unless you want to wait
yonks for the validator to fix up the bitmap.

The second case occurs at the driver level.  Remember that question during
prep "Do you want the heads parked after 3 seconds of inactivity?".  I ALWAYS
answer no to this prompt.  This option does exactly what you would think but
achieves it in a strange manner.  I don't think the driver busy waits to
seek the head to the park cylinder, but I do think it sends individual seek
commands for each track.  The interrupt overhead for this operation is quite
high and a large number of interrupts happen before the seek is completed.
Since hddisk.device runs at a higher priority than the normal CLI processes,
you will be locked out until this operation is complete.  So, I think it is
this feature that is biting (and annoying) you.  I know it's a drag, but you
will probably have to re-prep and reformat your drive to turn off the head
parking feature.

	Steve