car@pte.UUCP (Chris Rende) (03/17/89)
In article <28319@ucbvax.BERKELEY.EDU>, jas@ernie.Berkeley.EDU (Jim Shankland) writes: > In article <3299@sybase.sybase.com> tim@phobos.UUCP (Tim Wood) writes: > > > I'm talking about avoiding all the OS file system above the "read > > disk block/write disk block" level. > > SunOS 4.0 has the ability to map sections of files directly into user > process space (mmap() et al.). Instead of doing explicit file I/O, > you map a file section into your address space, and then just read > or write that part of your address space. If the pages you reference > haven't been read yet, they will be faulted in. The kernel buffer > cache is bypassed -- i.e., there is no copy between kernel space and > user space. And you can force writes by msync()'ing parts of your address > space. You get shared memory "for free" by mapping the same file > into several processes' address spaces. Amazing. This description is basically the method which Multics has been using for YEARS to manage disk/memory. All I/O on Multics is done through a pointer to some segment which may be on disk or in memory. The hardware keeps track of which pages of the segment are in memory and which in on disk. Each segment exists SOMEWHERE on the Multics file system. This includes all temporary memory allocations like stack and heap. The Multics counter-part of the the Unix "Standard I/O package" actually just translates pseudo file operations into segment operations. It is easy to simply bypass the file operations and use segment operations. A single library call returns a pointer to a new (or old) segment. Then, by simply referencing through the pointer you can examine or modify the data in the segment. > (A practical concern: if you want to port your DBMS around, you have > to wait about 50 years, until efficient, standardized implementations > of mmap() are ubiquitous.) No, just go 15 or 20 years BACK - to Multics. > If you've read this far, I'd certainly be interested in your comments. Henry Spencer once made an observation that went something like this: "Those who don't know Unix are doomed to recreate it, poorly." Well, I'll see you Unix and raise you Multics: "Those who don't know Multics are doomed to recreate it, eventually." car. -- Christopher A. Rende Multics,DTSS,Unix,Shortwave,Scanners,StarTrek uunet!edsews!{rphroy!}pte!car Minix,PC/XT,Mac+,TRS-80 Model I: Buy Sell Trade ...!mcf!pte!car Precise Technology & Electronics, Inc. "I don't ever remember forgetting anything." - Chris Rende
farber@pcpond.UUCP (David J. Farber) (03/18/89)
I second car's comment and raise an article . In an article titled " All Systems In Synch --The impact of ultra high speed networking on Computer Architecture" Gary Delp and I also pointed out the contributions of multics to the future directions of machines and software systems. (Unix Review Feb 1989) Dave