🚀 go-pugleaf

In article <40284@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
>Multics and Burroughs segments, however, don't get in the way in that
>manner, unless you want to have a single object that doesn't fit in a
>segment (in the case of Multics, the max size is 1MB).  [...]>>
>[...]  In addition, when files are
>mapped into the address space (which is the only way to access files)

In article <7135@bsu-cs.bsu.edu> neubauer@bsu-cs.bsu.edu (Paul Neubauer) writes:
>Does this mean that the maximum file size is 1MB?  How difficult does this
>make it to deal with, e.g., large databases?

  Well, both yes and no.

  Multics files are either single-segment or multi-segment. A
multi-segment file, not unexpectedly, can hold a fair bit of data. This
allows for things like MRDS (one of the first relational databases) and
other "large" creatures. It can even be turned to advantage, since you
can work with locality-of-reference and physical database design tricks
(clustering) to give good, inexpensive access patterns.
  The usual problem lies with implementation: a user can tell if a file
is single-segment versus multisegment, and come to depend on one or the
other case being true. (An MSF is a sort-of-directory, with contents
called 0, 1, 2, ...). And one could run out of bits to represent the
length, which was a bit count stored in an integer (36-bit machine
word).

  About the time I was leaving (:-{) the experiments with active objects
(an early object-orientation scheme) promised to make the distinction
moot. Alas, I don't know if that came true.  

--dave (source: organick) c-b
-- 
David Collier-Brown,  | {toronto area...}lethe!dave
72 Abitibi Ave.,      |  Joyce C-B:
Willowdale, Ontario,  |     He's so smart he's dumb.
CANADA. 223-8968      |