lkoop@pnet01.cts.com (Lamonte Koop) (09/08/90)
I'm sorry if this has at one time been discussed, but I need some information
pertaining to Quantum HDs. Specifically, I am curious about a particular
behavior of the drives after performing a write operation to the disk. It
appears that after performing said write, the drive will perform another I/O
operation a second or so later, lasting just an instant. (No, I'm not
referring to the drive dumping it's cache buffer) Furthermore, if this
operation is not performed, due to a system reset or such, no problems are
encountered with the drive, save for one peculiarity: The drive will seem
to search for something for quite a while upon re-start, then apparently
having found it, will boot normally. (This seems to be a common behavior
to all Quantums I have encountered) What exactly is this small I/O operation
doing? Thanks in advance.
--LaMonte
"The most original .sig file yet: a non-existant one."-me
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
ARPA: crash!pnet01!lkoop@nosc.mil
INET: lkoop@pnet01.cts.combryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (09/08/90)
In article <4306@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
=-I'm sorry if this has at one time been discussed, but I need some information
=-pertaining to Quantum HDs. Specifically, I am curious about a particular
=-behavior of the drives after performing a write operation to the disk. It
=-appears that after performing said write, the drive will perform another I/O
=-operation a second or so later, lasting just an instant. (No, I'm not
=-referring to the drive dumping it's cache buffer) Furthermore, if this
=-operation is not performed, due to a system reset or such, no problems are
=-encountered with the drive, save for one peculiarity: The drive will seem
=-to search for something for quite a while upon re-start, then apparently
=-having found it, will boot normally. (This seems to be a common behavior
=-to all Quantums I have encountered) What exactly is this small I/O operation
=-doing? Thanks in advance.
=-
This has nothing specifically to do with Quantum disks. The disk
access after the short timeout is caused by the Amiga's disk validator process
revalidating the disk's bitmap after a write, and occurs with all hard disks,
and floppies, too, in fact. If you reboot before the validator updates the
bitmap, then the disk validator has to read the entire file system structure
and rebuild the bitmap before allowing writes to the disk.a218@mindlink.UUCP (Charlie Gibbs) (09/10/90)
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."billsey@agora.uucp (Bill Seymour) (09/11/90)
In article <4306@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
:I'm sorry if this has at one time been discussed, but I need some information
:pertaining to Quantum HDs. Specifically, I am curious about a particular
:behavior of the drives after performing a write operation to the disk. It
:appears that after performing said write, the drive will perform another I/O
:operation a second or so later, lasting just an instant. (No, I'm not
:referring to the drive dumping it's cache buffer) Furthermore, if this
:operation is not performed, due to a system reset or such, no problems are
:encountered with the drive, save for one peculiarity: The drive will seem
:to search for something for quite a while upon re-start, then apparently
:having found it, will boot normally. (This seems to be a common behavior
:to all Quantums I have encountered) What exactly is this small I/O operation
:doing? Thanks in advance.
This isn't a Quantum phenomenon per se, it's an AmigaDOS thing. The
Filesystem write the file, then goes back later to update the disk BAM. The
pause between writing the file data and the BAM is what you're seeing. You're
right in saying it's not the Quantum flushing it's cache, but rather the Amiga
flushing *it's* cache. This time is greatly reduced under 2.0...
The long wait on bootup after a reset before the DOS cache is flushed
is caused by the system having to re-validate the drive. Since that DOS cache
hadn't been written, the bitmap flag was still set as invalid.
:--LaMonte
:
:"The most original .sig file yet: a non-existant one."-me
:
:UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
:ARPA: crash!pnet01!lkoop@nosc.mil
:INET: lkoop@pnet01.cts.com
--
-Bill Seymour ...tektronix!reed!percival!agora!billsey
=============================================================================
Bejed, Inc. NES, Inc. Northwest Amiga Group At Home Sometimes
(503) 281-8153 (503) 246-9311 (503) 656-7393 BBS (503) 640-0842lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/13/90)
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 | +-----------------------------------------------------------------------+
lkoop@pnet01.cts.com (Lamonte Koop) (09/13/90)
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