Path: utzoo!attcan!uunet!van-bc!
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Quantum Hard Drives
Message-ID: <1970@lpami.wimsey.bc.ca>
Date: 12 Sep 90 21:24:40 GMT
Lines: 64
Return-Path: <lpami!lphillips>
To: van-bc!rnews

In <4384@crash.cts.com>, lkoop@pnet01.cts.com (Lamonte Koop) writes:
>a218@mindlink.UUCP (Charlie Gibbs) writes:
>>In article <4306@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop)
>>asks what that extra I/O operation is that occurs a second or so
>>after writing to his hard disk.
>>
>>     Are you *sure* it's not the cache being dumped?  This is a
>>file system function which happens on every Amiga disk drive (hard
>>or floppy) that I've ever seen.  That this is what you're seeing
>>is confirmed by your report of extensive disk activity on a re-boot
>>where this final I/O wasn't performed.  Without that final write to
>>flush the buffers, the disk is left in a compromised state.  That
>>extra I/O on re-boot is just the disk-validator cleaning things up
>>again; you're fortunate that it was able to do so without putting
>>up all sorts of nasty requesters telling you to use DiskDoctor (ugh!).
>>
>>Charlie_Gibbs@mindlink.UUCP
>>Intel puts the "backward" in "backward compatible."
>
>
>No...it's not the buffers being flushed:  I did find out what it was though;
>AmigaDOS updating the bitmap/hash tables (essentially what you are saying,
>with only a slight difference).  Those long boot-up searches are indeed the
>validator, but it is basically going through all the files to update the hash
>tables, not write-out buffer data. [Else this same effect wouldn't occur
>during a power-down interruption, and it does indeed]  One good point: NEVER
>DO THIS ON PURPOSE!!!  You are right that even though what it is doing is
>slightly different, the requesters from the deep could easily still show up.

You are saying the same things, but Charlie is more accurate. The small flash
of the disk light a few seconds after a write is a CMD_UPDATE being sent to the
driver, which will write out _ANY_ 'dirty' buffers. A 'dirty' buffer may
contain any sort of data at all, including header information, bitmap
information, or data itself. After any write, the 'dirty' buffers will
include at least part of the bitmap.

This is a different operation from the validation that you see later.

When the disk does a lot of seeking on power up (or on a reboot, or on a
diskchange), is is the validator doing it, but it is NOT 'updating the hash
tables'.

As Charlie said, it is doing this because the disk was left in a 'compromised
state'.  The compromised state is detected when the 'bitmap valid' flag in the
root block is determined to be all zeros.  It is virtually guaranteed to be all
zeros if the CMD_UPDATE is not allowed to do its thing, but the bitmap is by no
means the only part of the disk that can be compromised by prematurely booting
or as the result of a crash.

At any rate the validator traverses all directory and file headers, following
the hash tables and using them to determine what bits should be on/off in the
bitmap. At the end of this operation, if successful, the new bitmap is written
out. Note that at no time are any hash tables changed by the validator.

-larry

--
It is not possible to both understand and appreciate Intel CPUs.
    -D.Wolfskill
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+