\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