\magnification\magstep1

\def\sect#1{\medskip\noindent{\bf #1}\smallskip}

\rightline{\hbox{\vbox{\halign{#\hfil\cr
Kenneth Duda\cr
6.853 PS 1\cr
Thu Mar  4 17:51:40 1993\cr}}}}

\centerline{\hbox{\vbox{\halign{\hfil #\hfil\cr
Referee's Report\cr
{\it The Sprite Network Operating System}\cr
Authors: Osterhout, Cherenson, Douglis, Nelson, and Welch\cr
Reviewer: Ken Duda (MIT)\cr
March 4, 1993\cr}}}}

\baselineskip = 21pt plus 4pt

This paper describes the implementation of the Sprite Network
Operating System, a UNIX-like kernel designed to be run on each node
in a network of cooperating workstations.  Sprite's primary extensions
of the traditional UNIX networked computing environment (such as Sun's
Networked Computing Environment) are a network-transparent cached file
system, a fork that shares data among the children, remote system
calls via RPC, and process migration.

The paper is very clear, easy to follow, logically organized, and
presents several interesting ideas.  However, I believe this paper
could be significantly improved by adding discussion of the weaknesses
of the project being described (the Sprint Network Operating System);
therefore, I advised that this paper be accepted on the condition that
the author makes certain minor revisions.

\sect{General Comments}

The paper implements certain things in certain ways and talks about
the advantages.  I feel these comparisons would be more honest if the
paper also discussed the disadvantages.  For example, the stuff on
shared memory is much weaker than the paper tries to make it sound.
Several versions of UNIX allow the sharing of specific blocks of
memory between processes, so that domain boundaries remain in force.
In Sprite, processes sharing memory share their entire data segments
(static and dynamic, ``for simplicity'').  The problem with this is
that all protection boundaries are gone.  Two Sprite processes sharing
memory are much more like two threads running in the same process than
like two mostly-independent processes.

A major issue which this paper essentially fails to address, but I
believe is important for a comprehensive evaulation of the system, is
the problem of scalability.  The paper claims that a single Sprite
file server could serve perhaps 50 nodes.  Ok; however, it does not
appear to be possible for $n$ file servers to serve 50$n$ nodes.
There are several sources of this lack of scalability: the fact that
the root file system lives only on a single node (implying that system
software, such as binaries typically found in /usr/bin, live only on
one node as well); the fact that file system clients find the
locations of parts of the file hierarchy through a broadcast protocol
(the same poor tradeoff between protocol efficiency and convenience of
configuration that Apple made with Appletalk); the statement that
``Sprite keeps track of which machines are idle and selects one as the
target for [process] migration''; and the fact that file servers
remember every client that has a file open.

One would like to believe that reliability would increase over a
distributed system.  However, if each node depends on one file server
for system software, one file server for swap, one for the user's
files, and furthermore each server can get into trouble if its clients
crash (see notes below), the user now loses if any of several machines
goes down rather than only if his private machine goes down.  I
believe there are reliability considerations that should be addressed.

\sect{Specific Suggestions}

Page 24 column 3 top: This assumes that total network transparency is
a goal.  The Andrew File System (AFS) is network-transparent for all
sub-directories under /afs, and the rest of the file system is
traditional.  This way, the user can use NFS file servers if desired,
and can explicitly reference the local disk.  I understand that if I
had a swap server with 500 megabytes of RAM for every 50 machines, and
a relatively unloaded network, I might be better off swapping to the
swap server than to local disk, but with most common systems local
disks still have a performance advantage, but the fact that a
network-transparent file system forces me to forego using other file
systems and being able to reference my local disk should be made
explicit.  Furthermore, if Sprite is as non-scalable as it appears,
then requiring a fully network-transparent file system looks like it
will make it very awkward to access my files from outside my Sprite
domain, whereas with AFS I can access my files in Boston from Palo
Alto as if they were on the local machine.

Page 26 column 2 bottom: If the kernel has many internal locks, is
there a possibility of deadlock among kernel threads?

Page 27 column 3 top: If Sprite were being used over a larger area,
would it be possible to make it secure, or is the insecure nature of
RPC intrinsic?

Page 28 column 2 bottom: Reconfiguring NFS does not need to be nearly
this cumbersome; do not blame poor system administration on NFS.  File
systems can be unmounted and remounted while the machine runs, so
scripts to reconfigure clusters by brute force (rsh'ing mount and
umount commands to each machine as root) can be written.  Also see
{\tt attach} (Project Athena Technical Report {\it mumble}) for a way
this can be handled without administrator intervention at all.

Page 31 column 1 bottom: How does the server force the client to flush
dirty blocks?  It must receive an acknowledgement that the flush is
complete, right?  What if the client has crashed?  Similarly, at the
top of the next column, it notifies all clients with the file open to
stop caching.  Are these separate RPC calls?  If a client has gone
down, does the whole system hang?

Page 32 column 3 bottom: A performance comparison with AFS would be
great, since as you say it uses an alternate caching approach.

Page 33 column 1 bottom: If many nodes share a file server for backing
store, a space hog can run several people out of swap simultaneously.
This is a reliability/efficiency trade-off which was presented in the
paper as a simple improvement.



\bye



