Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!ames!oliveb!sun!pope@vatican From: pope@vatican (John Pope) Newsgroups: comp.unix.wizards Subject: Re: Write-Behind (was Re: Record-access libraries) Message-ID: <74266@sun.uucp> Date: 24 Oct 88 17:52:29 GMT Article-I.D.: sun.74266 References: <287@cvbnet2.UUCP> <107@minya.UUCP> <74161@sun.uucp> <14122@mimsy.UUCP> Sender: news@sun.uucp Reply-To: pope@vatican (John Pope) Organization: Sun Microsystems, Inc. Lines: 22 In-reply-to: chris@mimsy.UUCP (Chris Torek) In article <14122@mimsy.UUCP>, chris@mimsy (Chris Torek) writes: >Why do you think DEC thought the 16 kB in the UDA50 was such a >wonderful buffer? I guess because it was 16k more than they had before *:o) . My UDA-50 documentation has virtually nothing in it about controller optimization - maybe it's in one of the parts with "this section deliberately omitted" on it. >[the UDA-50] does not report the transfer as done until it has in fact been >written. It *may* reorder writes, however (it is hard to tell for sure). Most of the "smart" SMD and IPI controllers seem to do this now. I believe most of them treat reads and writes the same within the elevator (or whatever) algorithm, but I've seen at least one implementation of disksort() in the operating system that optimized reads ahead of writes on the theory that processes don't wait for writes. Such algorithms may also have made their way on board a disk controller or two... John Pope Sun Microsystems, Inc. pope@sun.COM