Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!orion.cf.uci.edu!paris.ics.uci.edu!nagel
From: nagel@paris.ics.uci.edu (Mark Nagel)
Newsgroups: comp.sys.next
Subject: Re: two passes to write file? (was: Lousy input sound)
Message-ID: <900@paris.ics.uci.edu>
Date: 8 Nov 88 03:46:00 GMT
References: <25795@tut.cis.ohio-state.edu> <898@accelerator> <8711@spl1.UUCP> <4301@phoenix.Princeton.EDU>
Sender: news@paris.ics.uci.edu
Reply-To: nagel@paris.ics.uci.edu (Mark Nagel)
Organization: University of California, Irvine - Dept of ICS
Lines: 21
In-reply-to: zimerman@phoenix.Princeton.EDU (Jacob Ben-david Zimmerman)

In article <4301@phoenix.Princeton.EDU>, zimerman@phoenix (Jacob Ben-david Zimmerman) writes:
|
|...okay, ignorant question here...I read earlier on that during writes,
|the optidrive does TWO passes, one to zero the fields, and one to write
|in the 'one' state bits.  Now, since it has to do two passes and needs
|to therefore know how big the files is gonna be, can it handle real-time
|contintuous 16-bit input? Or will its having to go back twice choke it
|up?  Could a rountine be written that used the main RAM as a buffer
|while it was doing its double write?  Would it be fast enough to get
|everything written to disc AND 'catch up' before the RAM was consumed?

I believe that the concept of "file" is unknown at the level you
are concerned with.  The disk will do passes for each *block* it
writes to disk.  In essence, this is two passes per file, but happens
much differently.  From a user level, this is no different than
any other disk, although perhaps a bit slower, since each block
requires two passes to be written.

Mark D. Nagel
  UC Irvine - Dept of Info and Comp Sci | The probability of someone
  nagel@ics.uci.edu             (ARPA)  | watching you is proportional to
  {sdcsvax|ucbvax}!ucivax!nagel (UUCP)  | the stupidity of your action.