Sprite is a new operating system for networked uniprocessor and multiprocessor workstations with large physical memories. It implements a set of kernel calls much like those of 4.3 BSD UNIX, with extensions to allow processes on the same workstation to share memory and to allow processes to migrate between workstations. The implementation of the Sprite kernel contains several interesting features, including a remote procedure call facility for communication between kernels, the use of prefix tables to implement a single file name space and to provide flexibility in administering the network file system, and large variable-size file caches on both client and server machines, which provide high performance even for diskless workstations.

Abstract not found

A pseudo-device is a mechanism in the Sprite network file system that lets a userlevel server process emulate a file or I/O device. Pseudo-devices are accessed like regular files or devices, and they exist in the file system name space. Pseudo-devices are implemented by transparently mapping client operations on the pseudo-device into a request-response exchange with a server process. The interface to pseudodevices is general enough to be a transport mechanism for a user-level RPC system. It also provides a stream-oriented interface with write-behind and read-ahead for an asynchronous connection between clients and server. Sprite uses pseudo-devices to implement at user level its terminal drivers, the internet protocol suite, and the X-11 window system server. The pseudo-device implementation provides as fast or faster communication, both local and remote, than a UNIX UDP socket connection. + .sp 1c April, 1988 1. Introduction This paper describes pseudo-devices, a mechan...

This paper describes a facility that transparently extends the Sprite distributed file system to include foreign file systems and arbitrary user services. A pseudo-filesystem is a sub-tree of the distributed hierarchical name space that is implemented by a user-level server process. A pseudo-file-system fits naturally into the Sprite distributed system; the server runs on one host and access from other hosts is handled in the same way as remote access to Sprite file servers. The pseudo-file-system interface is general enough to be used for version control systems, access to archival storage, as well as access to other kinds of file systems. We currently use a pseudofile -system server to provide access to NFS file servers from Sprite workstations. Performance results of the NFS server are given in order to evaluate the cost associated with user-level implementation of services. + December 16, 1992 ########################### + This work was supported in part by the Defens...

Introduction "Stateless" servers have been popularized by NFS [Sandberg85]. The benefit of a stateless server is that the server can crash and reboot and no special recovery action is required. Clients simply retry their operations until they get a response from the server. There are two draw-backs to this approach, however. First, clients can get stuck if they try to contact a server that stays down for a long time. Second, and much more important, a stateless server suffers a performance hit because all changes in the service's internal state+ must be saved on stable storage. We advocate keeping state in main-memory instead of logging state to disk so that we can implement higher performance services. We are motivated by our distributed file system that uses stateful servers to support a high performance distributed caching system[Nelson88]. For reliability a server's state is replicated in the main-memory of other hosts so that the system can recover from failure of a serv