Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!network.ucsd.edu!celit!dave
From: dave@fps.com (Dave Smith)
Newsgroups: comp.arch
Subject: Re: Extremely Fast Filesystems
Message-ID: <10640@celit.fps.com>
Date: 8 Aug 90 02:22:47 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13526@yunexus.YorkU.CA> <10606@celit.fps.com> <1179.26bffdbf@waikato.ac.nz>
Sender: daemon@fps.com
Reply-To: dave@fps.com (Dave Smith)
Organization: FPS Computing Inc., San Diego CA
Lines: 24

In article <1179.26bffdbf@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
>In <10606@celit.fps.com>, dave@fps.com (Dave Smith) says "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."
>
>Are you sure your customer isn't confusing the size of main *physical*
>memory with the size of *virtual* memory?

Yes.  We support (in the current product) up to 1GB of physical memory.
Convex, Cray, etc. also support main memory sizes in that range.  The customer 
in question does seismic processing and routinely has data sets in the 10GB 
range.  They have a file server which pulls several smaller files together 
into a larger virtual file to get around our current limitations on maximum
file size.

Virtual memory for a Bullet-style server is kind of like using /dev/ram as
your swap device.  Why copy in from the disk just to copy it right back
out again?
--
David L. Smith
FPS Computing, San Diego        
ucsd!celerity!dave or dave@fps.com