🚀 go-pugleaf

In article <2906@sdcsvax.UCSD.EDU> mishkin@apollo.UUCP (Nathaniel Mishkin) 
writes:
>Jim Rees's article (which may or may not have been posted yet) gives
>the outlines of how Apollo uses the single-level store idea to implement
>its distributed filesystem.
>
:
>now), we added "touch ahead":  Mapped segments (32K regions of virtual
:
>we did do was make it so that segments can be marked "flush-behind";
:
>better is "grow-ahead":  Note that when you're writing a new file, the
:
>All in all, mapped I/O is a nice and useful idea, but anyone who thinks
>that it will perform just like a traditional sequential I/O system withOUT
>any special purpose features like the ones described above is whistling
>in the dark.  Also, some of the features don't always work like you'd
>think/hope.
:

Thank you for writing such an informative summary.  These are exactly the
features that are needed.  The third, new-file "grow-ahead", is something that
is missing, but is sorely needed, in VSOS.  VSOS actually pages in new
untouched pages from disk.  Your article gave me hope: not all the lessons of
the past have been forgotten (or, for the more emotional: MULTICS and TSS
live!   :-)

Two more questions:  

1)  Does Aegis have an advise function that allows a process to give
    advanced information to the system about which pages are needed?
    VSOS has this, and it turns out to be very useful.  Example:  A
    "large" fluid dynamics code which doesn't fit in memory (we only
    have 64 MBytes :-)  )  is structured so that it touches memory
    semi-sequentially.  The programmer calls ADVISE periodically to
    let the system know which pages will be needed next.  The 
    resulting system call sets PAGER going, and the process continues
    to run.  When the process gets to that memory, it is fortuitously
    already there.  This can result in unbelievable performance
    improvements in some cases.

2)  How much of this is available in Apollo's Un*x environment?  It
    would be nice if Aegis provided a "real" BSD Unix environment,
    but still had the "advanced" facilities available as system
    services.



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")