Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!nosc!crash!pnet01!lkoop
From: lkoop@pnet01.cts.com (Lamonte Koop)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Quantum Hard Drives
Message-ID: <4384@crash.cts.com>
Date: 13 Sep 90 06:56:17 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 36

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.


--LaMonte

"The most original .sig file yet: A non-existant one!"

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
ARPA: crash!pnet01!lkoop@nosc.mil
INET: lkoop@pnet01.cts.com