Xref: utzoo comp.arch:17582 comp.databases:6725
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!news
From: cliffc@sicilia.rice.edu (Cliff Click)
Newsgroups: comp.arch,comp.databases
Subject: Re: Extremely Fast Filesystems
Keywords: addressing,fractions,floating-point,caches
Message-ID: <1990Aug8.010203.18560@rice.edu>
Date: 8 Aug 90 01:02:03 GMT
References: <13667@cbmvax.commodore.com> <13578@yunexus.YorkU.CA> <dczq02zP01Hc01@JUTS.ccc.amdahl.com>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 27

In article <dczq02zP01Hc01@JUTS.ccc.amdahl.com> rbw00@JUTS.ccc.amdahl.com (  213  Richard Wilmot) writes:
>davecb@yunexus.YorkU.CA (David Collier-Brown) wrote:
>
>> 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.
>>
>    ... stuff deleted
>
> [ ...stuff about using fractional addressing deleted... ]
>
>So when will I see fractional addressing?

Humm... infinite precision fractional addressing... isn't this equivalent to
using "bignums"?  Suppose I take a fractional addressing system, and generate
a fraction digit-by-digit, 2 digits for each letter of a person's name.  
Suddenly I have a unique fraction which is some permutation of a name.  In
other words I have a system where names are addresses, and since names have 
no length limit, I have no limit to my file sizes.  I say a rose by any other 
addressing mode is a rose; what your describing is nothing more than a 
key-access file system.

Cliff Infinite Fractions Click
-- 
Cliff Click                
cliffc@owlnet.rice.edu