Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Unix block I/O (was Re: Memory hierarchy)
Message-ID: <11738@dog.ee.lbl.gov>
Date: 3 Apr 91 22:41:52 GMT
References: <2845@shodha.enet.dec.com> <1998@kuling.UUCP> <2832@shodha.enet.dec.com> <1991Mar28.152952.18380@rice.edu> <00670398761@elgamy.RAIDERNET.COM>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 19
X-Local-Date: Wed, 3 Apr 91 14:41:52 PST

In article <00670398761@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM
(Eric Lee Green) writes:
>... If I recall right, the vast majority of Unix kernals basically
>do I/O a block at a time into cache RAM, then copy it by hand into
>the user's data buffers.

Mostly right.  Although mapping buffers copy-on-write is possible it
is often not cost-effective.  Also, the size of a `block' is not well
defined here; this makes a lot of difference.

>Some do pre-reading, which speeds sequential access, but puts random
>access into the doghouse

The code typically triggers off `the last read for this file was block
n, this one is block n+1, so get n+2', which avoids this (again it depends
on `block size', which typically varies from 512 to 65536 bytes).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov