Path: utzoo!utgpu!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: <13578@yunexus.YorkU.CA>
Date: 7 Aug 90 12:21:16 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13667@cbmvax.commodore.com>
Organization: York U. Computing Services
Lines: 60


 In article <30728@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes:
[in a discussion of Tannenbaum's Bullet fileserver]
| >This is very elegant, but there is 
| >a problem. We're running out of address bits again. 

jesup@cbmvax.commodore.com (Randell Jesup) writes:
| 	I submit that your situation is something of an unusual case, and is
| likely to remain unusual for at least a decade, perhaps 2.  Few machines
| (percentage-wise) even have 4 GB of storage, let alone files larger that 4GB
| (I've never even seen a file larger than 100MB, even on mainframes).

	Alas, I worked on a library system under Unix... you wouldn't believe
the space costs of describing one book (:-)).  I kept having to check that
expected file maximums wouldn't exceed disk-drive sizes each time the DBMS
vendor postponed using raw partitions gain. 100MB was perfectly plausible,
and we had to plan for at least three existing sites well over that size.
Obviously we split this across many "files".

| 	Eventually, perhaps, but not in the near future.  There are people
| who have greater needs, that's the whole justification for the selling of
| supercomputers, and the vastly expensive (read fast & large) IO systems that
| support them.  But they're a tiny minority, numbers-wise.  Until the
| number of people that require such things increases sufficiently, the only
| architectures to support the extra address bits will be the super-(and maybe
| mini-super-)computers.  Those extra address bits are _not_ free, in silicon,
| memory, etc.  (I hope we haven't started the 32+ addr bit rwars again...)

	It's always a bad idea to put a hard addressing limit on things:
Intel, based on their past needs, octupled the addressable memory available
when they introduced the 8086, even though they expected 16k was adequate.
Experience has shown them wrong (;-)).  They needed to increase it by a
somewhat larger factor [see, we're back to computer architecture again].

   	I claim that this applies to files, too, and eventually to disks.
If you put hard limits in, people crash up against them.
	In the narrow case of Bullet, you can reinvent multi-segment files[1],
improve the addressing capabilities of the hardware or a combination of the
two.  Or other ideas I haven't even dreamed of yet. 
	I confess I'd have **real** trouble selling a raw bullet file system
to a customer doing anything but cad/cam, software development[2] or small
databases. 


--dave 

[1] A file which has multiple parts (segments), and which can be manipulated
transparently as if it had only one part. Multics MSFs were the first, but
weren't transparent enough. If you substitute segment for page in the above,
the mechanism used to implement it becomes almost obvious.  Alas, it still
requires a loooooooong integral variable somewhere user-accessable for
positioning oneself.

[2] Which includes academic computing, you understand: that's what I do
these days.
-- 
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