The Sprite Network Operating System
--- Ousterhout et al., 1988


- motivation for a new OS: networks, large memories, multiprocessors;

- Sprite hopes to hide the distribution of the system as much as
  possible and make available the same ease of sharing and
  communication that is possible on time-shared machines;

- overall goal: provide simple and efficient mechanisms that
  capitalize on the three technology trends;

- facilities: transparent network file system, mechanism for sharing
  writable memory between processors on a single workstation, and a 
  mechanism for migrating processes between machines;

- RPC is implemented; used to implement network file system;

- Sprite caches file data on both server and client machines.  A
  simple cache consistency maintains a single-version semantics;

- instead of using a special swap area, the VM system uses ordinary
  files;

- a home machine is used for each migrated process, to allow for
  location dependent information;

- physical memory sharing is achieved using the VM system;

- the file system provides network and name transparency; a single
  hierarchy is accessible to all workstations;

- shared address spaces is motivated by multiprocessors;  a parameter
  to the fork syscall informs if the child and parent processes should 
  share the same data and code segments (all-or-nothing sharing);

- a system call is provided to implement process migration;

- efficient RPC mechanism, suitable for request-response operations;
  fragmentation is used to support large messages; implicit
  acknowledgements and retransmission are implemented by the RPC engine;

* Sprite kernels trust each other, and they assume that the network
* wire is physically secure.  this is unsuitable for non-LAN
* environments;

* instead of using static mount tables, Sprite uses dynamic prefix
* tables.  Each machine keepts its own prefix table.  For every
* absolute path name, the kernel performs a longest-prefix match in the
* prefix table, which results in a server name and token (like an
* i-node).  The file is then requested.  The server contacted may
* return a file handle (token) or a second path name, if the original 
* name crosses a server boundary.  In order to discover which server 
* hosts the desired filesystem (called a domain in Sprite), the client 
* performs a broadcast, sending the desired prefix name, which is 
* answered by the server hosting the filesystem (the response includes 
* the token needed for the client to insert a new entry in its 
* prefix table).

- cache consistency is kept over blocks, which are 4KB;  each block in
  the cache is identified by a token for a file and a block location
  within the file;

- file writes used a delayed-write approach;

- two mechanisms for ensuring cache consistency: sequential
  write-sharing (SWS) and concurrent write-sharing (CWS);

- SWS occurs when a file is never written when open by another
  machine.  Sprite handles SWS by using versioning.  When a machine
  opens a file, it receives the latest version from the server and
  erases from its cache the blocks related to old versions of the
  file;

- CWS is dealt with by Sprite by disabling caching! When the server
  receives an open request that will result in CWS, if flushes dirty
  blocks back from the current writer and notifies all clients that
  this file cannot be cached anymore (for a limited time).
  Measurements show that CWS is rare.

- Sprite's VM system has 3 different characteristics:

	- uses ordinary files for backing storage.  Uses a single
	  server with every machine having a specific directory;
	  this improves locality and simplifies process migration; 
	  another important point is that these pages are cached
 	  in the server, making the access faster than to a local
	  disk. To avoid double-caching, the VM system bypasses the
	  local file cache when reading and writing backing files;

	- sticky segments.  Code segments for popular programs are
	  kept in main memory;

	- VM-FS negotiation.  the file cache can grow and shrink in
	  response to changing demands on the VM and FS.  Each
   	  "subsystem" keeps an age count on every page.  When one 
	  of them needs more memory, to oldest entry in each 
	  subsystem are compared.

- in Sprite, backing files simplify the transfer of the virtual memory
  image during process migration.  The old machine simply pages out
  the dirty pages and transfers information about the backing files
  to the target machine.  They are then fetched on demand from the 
  backing server.

- Sprite achieves transparency by assigning each process a home node
  (the one in which the process was created), which handles
  machine-dependent system calls;

- migration can take from milisseconds to tens of seconds, depending
  on the number of dirty pages.