Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!super!rminnich
From: rminnich@super.ORG (Ronald G Minnich)
Newsgroups: comp.arch
Subject: Re: Extremely Fast Filesystems
Message-ID: <30728@super.ORG>
Date: 4 Aug 90 19:48:14 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA>
Sender: news@super.ORG
Reply-To: rminnich@super.UUCP (Ronald G Minnich)
Organization: Supercomputing Research Center, Bowie, Md.
Lines: 41

>puder@zeno.informatik.uni-kl.de (Arno Puder) writes:
>| Tanenbaum's philosophy is that memory is getting cheaper and cheaper,
>| so why not load the complete file into memory? This makes the server
>| extremely efficient. Operations like OPEN or CLOSE on files are no
>| longer needed (i.e. the complete file is loaded for each update).

Yes, note that BULLET does not support a write command. You create, 
delete, and read files. If memory serves, thats it. 
This is very elegant, but there is 
a problem. We're running out of address bits again. 

I gave the standard "why shared memory is a nice way to do a high speed
network interface" talk the other day and someone pointed out that on 
Multics, with memory-mapped files, you always had to support the read-write 
interface for any program because the address space of the machine was too 
small for the memory-file abstraction to cover all files, and if your 
program couldn't deal with all files, it was useless. So you hacked your
program: if the file is too big, do it read write, otherwise use memory
files. And people realized that it was easier just to do read write,
and stopped bothering with memory files. Obviously this applies
to architectures we have now: lots of files are bigger than the 4 Gb address
space of my Sun, and things are not getting any better. And of course on 
Crays you don't get memory-mapped files at all. So the programs I now write
that use memory-mapped files on SunOS always have an out in the event that the 
mmmap fails or the system I am on does not support it. Conclusion: Bullet is 
really cool, as are memory-mapped files, but their eventual utility is 
limited by computer architecture questions. Since read-write is more general,
maybe it is the wave of the future. Gee, i don't like that! I have several
programs that got lots faster because calls to read() were replaced by 
an address computation. But my architectures have left me in a bind.
For your example gigabyte/second file system I can run through my Sun's
address space in 4 seconds. 

   Now what do we do? Maybe the next round of address spaces should be 
large enough to address all the atoms on the planet- that should cover 
us for a while. 
ron
-- 
1987: We set standards, not Them. Your standard windowing system is NeUWS.
1989: We set standards, not Them. You can have X, but the UI is OpenLock.
1990: Why are you buying all those workstations from Them running Motif?