Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!lll-winken!uunet!philmtl!philabs!linus!munck
From: munck@linus.UUCP (Robert Munck)
Newsgroups: comp.arch
Subject: Re: Re: 386/486 Virtual Memory Question...
Message-ID: <56193@linus.UUCP>
Date: 15 Jun 89 11:19:37 GMT
References: <4427@ficc.uu.net> <310003@hplvli.HP.COM>
Reply-To: munck@faron.UUCP (Robert Munck)
Organization: The MITRE Corporation, Bedford MA
Lines: 25

In article <310003@hplvli.HP.COM> boyne@hplvli.HP.COM (Art Boyne) writes:
>Actually, for ... simulations, the 4 Mbyte file limit is serious.  I have
>seen a simulation whose output file was 100 MByte... also 
>CAD/CAM design files that frequently go 6-8 Mbyte each.
>

Sure, no matter what upper limit you chose, there'll be users who
need it to be higher.  The question is, can the job be done within
the limits?  For example, the simulation output could be directed
to a tape or into a sequence of files, since it's (probably)
sequential.  The CAD/CAM file is more of a problem, as it's probably
random access.  It happens that the higher-level OS that is to
be implemented on my secure kernel has an entity-relationship-attribute
file system that can put multiple tiny files in one of my 4K byte
minimum segments or build structures of larger files.  The CAD/CAM
file is probably a data structure that could be spread over many
nodes in the ERA structure.  In other words, the CAD/CAM system writers
could construct their data structure in the ERA filespace rather than
in a single linear file.

The idea that the file system be used to construct arbitrarily-complex
applications data structures is relatively new in the world, as is having
the components of such a file system be strongly typed, with full 
inheritance.
                                -- Bob Munck