Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!ucsd!network.ucsd.edu!celit!dave
From: dave@fps.com (Dave Smith)
Newsgroups: comp.arch
Subject: Re: Extremely Fast Filesystems
Message-ID: <10606@celit.fps.com>
Date: 7 Aug 90 01:47:36 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13526@yunexus.YorkU.CA>
Sender: daemon@fps.com
Reply-To: dave@fps.com (Dave Smith)
Organization: FPS Computing Inc., San Diego CA
Lines: 21

In article <13526@yunexus.YorkU.CA> davecb@yunexus.YorkU.CA (David Collier-Brown) writes:
>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).
>

I thought the Bullet file server was neat, but...I showed the paper to
one of our customers.  He read through it and laughed.  He said that
he wanted to have files bigger than his main memory, that was the
whole point of disks.

The Bullet server doesn't address the problems of very large files.  I also
see problems with the Bullet server when two large files (~ as large as the
memory size) are needed at the same time.

--
David L. Smith
FPS Computing, San Diego        
ucsd!celerity!dave or dave@fps.com