Path: utzoo!attcan!uunet!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.YorkU.CA (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: Extremely Fast Filesystems
Message-ID: <13580@yunexus.YorkU.CA>
Date: 7 Aug 90 12:33:25 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13526@yunexus.YorkU.CA> <10606@celit.fps.com>
Organization: York U. Computing Services
Lines: 34

dave@fps.com (Dave Smith) writes:
| 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.

	Agreed.  I think I'd like your customer (:-)).

| 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.

	If one restricts the problem to the fileserver, and agrees that the
data will appear on the compute engine as a series of pages when needed,
then one need merely (ahem) ensure that the fileserver has enough memory for
a number of complete files and can feed the required pages to the compute
machine when asked.  This kind of fileserver is only slightly different
from what we have now, but it's a difference in **nature**, so it won't be
easy to do "right".
	Right now, I'd have to restrict Bullet to easily decomposable data
problems, like software development and teaching (lots of little files),
CAD/CAM (moderatly monstrous files), and with a bit of arm-waving,
transaction processing.


	In my next rant[tm], I'll touch on architectural support for VERY
LARGE FILES (:-)).

--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | "And the next 8 man-months came up like
CANADA. 416-223-8968  |   thunder across the bay" --david kipling