🚀 go-pugleaf

In article <7135@bsu-cs.bsu.edu> neubauer@bsu-cs.bsu.edu (Paul Neubauer) writes:
>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)
>>they are assigned unique segments, and applications may allocate
>
>Does this mean that the maximum file size is 1MB?  How difficult does this
>make it to deal with, e.g., large databases?

Yes and no.  To handle larger needs, there is a library of routines
for handling Multi-Segment Files.  MSFs are specially marked and
organized directories which are treated by many programs as a single
file.  The stream and record-oriented file I/O library will
automatically create and use MSFs, and standard file manipulation
commands (copy, delete, etc.) operate on them as if they were ordinary
files.  Database managers use MSFs, of course (in fact,
keyed-sequential files, the basis of the MRDS relational database, are
ALWAYS implemented as MSFs, with one segment holding the key B-tree,
and the others holding the data).  User programs that wish to do their
own memory-mapped segment access (rather than calling the file I/O
routines) and permit operation on both segments and MSFs can call
msf_manager_ library routines (these make ordinary segments look like
single-component MSFs, automatically create new MSF components, and
automatically convert segments into MSFs when necessary).


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar