Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@oberon.csg.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Multics & Memory mapped files Message-ID: Date: 12 Feb 90 22:17:57 GMT References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <2106@crdos1.crd.ge.COM> <5180@crdgw1.crd.ge.com> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 22 In-Reply-To: hammondr@sunroof.crd.ge.com's message of 9 Feb 90 14:19:19 GMT >Everybody seems to be missing the crucial fact about memory mapped files! > >They ONLY work for cases where the file size is < virtual address space!!! > >They are not a a generally useful solution which works over all possible >implementations. UNIX file I/O does work over all situations! Anecdote: The BSD kernel used to check the "seek pointer" of a file before access, even on sequential files and special devices. If the seek pointer were negative, an error was returned. Gould built a device called an HS[CXD] (I can't remember the exact name - similar to the so-called "Cray-Channel" (in fact, a modified system was used for Cray connectivity). Reasonably mongo I/O throughput (even now). Only took a few seconds for the seek pointer to reach 2^(31) and turn negative -- at which point the device stopped working. Moral: UNIX file I/O may not work in all situations. -- Andy Glew, aglew@uiuc.edu