"The Sprite Network Operating System" Ousterhout, Cherenson, Douglis, Nelson, Welch Is this a good paper? When was this paper written? 1987 What are their stated goals? Good performance for networked workstations Hide distribution; emulate single time-shared machine Take advantage of large memories, for caching Take advantage of multiprocessor workstations What techniques do they employ? Kernel uses RPC (user programs do not) Transparent network file system Shared memory between processes on same CPU File servers on a network Prefix tables to make a uniform file name space Process migration File caching on clients; cache consistency Disk cache / VM cache tradeoff (why aren't they the same?) Processes behave whether migrated or not -- sys calls forwarded home What's the point of prefix tables? Make sure all machines have the same directory structure. Allow updating of that directory structure. Separates naming of files from file access... How do prefix tables work? Client has a table (but only a subset). Finds longest match in table. How does a client learn about new prefixes? Server returns a magic kind of file at mount point. Causes client to broadcast to look up new prefix. Why does the prefix arrangement make sense? Separates naming from file access. Takes advantage of name hierarchy. Files with same prefix likely to be on same server. Why not broadcast a request for *every* file name lookup? Then I could move files among file servers. Why did they add memory sharing among processes? To support multiple CPUs. Do they provide general shared memory pages? No. Just special fork that shared all of data segment. Also shared memory doesn't work across machines. Why do they separate the VM and disk caches? They have different consistency policies. Can't do VM consistency by refusing to cache... Why is the separation awkward? Need to decide how much to give to each type of cache. Why do they support process migration? What does migrating a process involve? What happens when the migrated process makes system calls? In general, sent back to home machine. Except for special cases. For example, file access is transparent. What if a migrated process had a pipe open to another process? Presumably reads/writes sent back to home machine. Other process might be migrated as well... What if the migrated process shared memory with other processes? They don't have general distributed shared memory. They have to have migrated as well. Remember, shared mem was to take advantage of multiprocessors. Not means as a general sharing/communication mechanism. What happens if a migrated process forks? What machine does the child run on? What is its home machine? What machine does its PID exist on? Who can it share memory with? What happens if the child then migrates? What if the home machine crashes? What happens to migrated processes while home is down? What happens to them after home re-starts? Do they provide transparent device access? I.e. does /dev/whatever work across the network? Would this be good to have? If it were general, you'd get remote window system access for free. How does Sprite provide consistency for file contents? Write-back cache. If file only open once, that client allowed to write-cache. open checks w/ server is currently cached data ok? if not, server asks previous writer for latest data If open twice: (once for write, once for read, presumably) all caching disabled. all reads and writes go to server So server keeps track of the sharing state of each file. Can we precisely characterize consistency as seen by app? Does a read() see data from most recent write()? Probably. We don't know about near-simultaneous operations. Example w/ two writers? Are we sure we get most recent one? What if the server reboots while clients have files open? It needed to know who has each file open. It needed to know who had dirty file blocks, even if not open. Suppose we were writing a data base on top of Sprite. Store whole database in a single file. Does Sprite provide the consistency we want? No. We probably want a per-block shared/exclusive scheme. Per-block state might also generalize to shared VM caching? How does Sprite provide consistency for file system meta-data? E.g. directory contents. All operations go to server, apparently. For example, no name-to-file-handle caching. If I create a file, do you see it right away? What kind of environment would Sprite be useful in? Same as Athena (though a lot less complete). Would Sprite be a good foundation for programming distributed systems? Does it provide communication mechanisms to programs? Is it helpful in parallelizing over multiple machines? Does it help mask faults, via replication perhaps? Does it provide support for tolerating or recovering from faults? How would one evaluate Sprite? How would you decide if it had met its goals? How would you decide if it were useful? Does Sprite achieve its goals? Yes, they provide the specific features they promised. How aggressive was Sprite at providing full transparency? Not very. Only file system. Would there have been a lot of benefit to being more transparent? I.e. did they make reasonable decisions? Was Sprite's vision of the workstation of the future correct/relevant? Yes, pretty close to what we use today. Similar: individual workstations, shared network file system. Main difference: migration