Brent B. Welch. Naming, State Management, and UserLevel Extensions in the Sprite Distributed File System. University of California at Berkeley UCB/CSD 90/567. April 1993  Home/Search   Document Not in Database   Summary   Related Articles   Check

....network operating system. The Sprite kemel s facilities are almost identical to those of UNIX, and most of the applications running on the cluster are standard UNIX applications. Sprite has two features that made it a particularly interesting candidate for measurement: its network file system [17] and process migration [2] Sprite s network file system provides a single system image: there is a single shared file hierarchy with no local disks. The file system uses large file caches in the main memories of both clients and servers, and it ensures the consistency of data in the caches even ....

Welch, B. B., Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, PhD Thesis, University of California, Berkeley, February 1990. Also available as Technical Report UCB/CSD 90/567. 212

....improve upon NFS without adding excessive implementation complexity. 1.1. Status of the project The original Spritely NFS experimental work was done in 1988. At that time, we asserted (perhaps naively) that since the Sprite researchers had devised a recovery protocol for their system [31], the problem of recovery was solved in principal for Spritely NFS as well. The Sprite recovery protocol, however, was not entirely satisfactory for Spritely NFS (see section 5) 1 and so during the next few years, several people participated in a discussion of possible alternatives. In early ....

....feature does complicate both the client and server implementations in a number of ways, and for that reason is not entirely satisfying. 5. Overview of the recovery protocol Several different recovery mechanisms might have been used for Spritely NFS. The original recovery mechanism used in Sprite [31] depends on a facility implemented in the RPC layer that allows the clients and servers to keep track of the up down state of their peers. When a client sees a server come up, the Sprite file system layer then reopens all of its files. This approach provides more general recovery support than is ....

Brent B. Welch. Naming, State Management, and User-Level Extensions in the Sprite Distributed File System. PhD thesis, Department of Electrical Engineering and Computer Science, University of California---Berkeley, February, 1990. Technical Report UCB/CSD 90/567.

....In particular we discussed FileSystem and FileSystemType scopes. Since naming is separated from data management, there are corresponding scopes related to the naming component. A NameSpace and a NameSpaceType. For example, X.500 would be a NameSpaceType 6. This problem has also been pointed out in [Welch, 93] 102 scope while a particular X.500 namespace would be a NameSpace scope. These scopes are at the same level as the FileSystem and FileSystemType scopes. The other interesting scope related aspect of naming is related to client scopes. One of the common debates in operating systems is the scope of a ....

....X.500 namespace would be a NameSpace scope. These scopes are at the same level as the FileSystem and FileSystemType scopes. The other interesting scope related aspect of naming is related to client scopes. One of the common debates in operating systems is the scope of a federated namespace. Sprite [Welch, 90] implements a uniform namespace for a cluster of workstations, UNIX [Ritchie, 74] provides a uniform namespace for all the processes on one machine and Plan 9 [Pike, 93] provides a per process namespace. In the PFS architecture, there is a namespace associated with a process scope. However, that ....

B. Welch, Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, Ph.D. Dissertation, Dept. of Electrical Engineering and Computer Science, University of California, Berkeley.

....combined form. For autonomy as well as performance, the operations invoked on a named object need to be sent to the entity that manages the object. The former is illustrated by the vnode interface [Kleiman, 1986] while the latter is seen in the prefix table mechanism used by the Sprite file system [Welch, 1990]. An example of the application of name service is named objects implemented by the memory substrate. In this case, the name service is consulted to generate cluster wide unique names while creating objects and to ensure speedy resolution of names for other calls. 7.4 Composing System Software ....

B. Welch (1990) Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, Ph.D. Dissertation, Dept. of EECS, University of California, Berkeley.

....a serializable write operation must have a corresponding cache component that provides for serializability through some suitable mechanism like locking. In the distributed file system world, rudiments of decomposition can be found in the Vnode interface [Kleiman, 86] and the Sprite file system [Welch, 90]. Our approach carries this decomposition further, beyond virtual file systems. The proposed framework allows incremental changes to one or more components of the repository. An implementor can choose the most convenient representation for a subset of the namespace, the names contained therein, ....

Welch B., Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, Ph.D. Dissertation, University of California, Berkeley.

....remotely using NFS. The Slowdown column indicates how much slower NFS was than Sprite. In each case the server machine was the same type as the client machine. See [11] for details of the benchmarking. network indicate that only about 50 of newly written data is ever returned to the file server [15]. Table I compares the performance of Sprite and UNIX NFS for a fileintensive benchmark. On identical hardware configurations, the benchmark ran 45 to 110 slower under UNIX NFS than under Sprite. Mike Nelson s dissertation shows that most of the performance difference is due to the difference in ....

Welch, B. Naming, State Management, and User-Level Extensions in the Sprite Distributed File System. Ph.D. Dissertation, University of California at Berkeley, 1990.

....system, are used for overall performance, and it is convenient that they can also be used for fast recovery. 3.1. Distributed State Recovery In contrast to NFS [7] Sprite uses state on the file server in order to increase performance, but it must recover this state during a file server reboot [8]. For example, some of the state on the file servers is used to keep track of which workstations are caching which files. If a client workstation asks to read a file that is cached for writing on another client, the file server knows to find the most up to date copy of the file on the client ....

Brent B. Welch Naming, State Management, and User-Level Extensions in the Sprite Distributed File System. Technical Report Number: UCB/CSD 90/567, University of California at Berkeley. PhD Thesis, May 1990.

No context found.

Welch90. B. B. Welch, Naming, State Management, and User-Level Extensions in the Sprite Distributed File System, PhD Thesis, 1990. University of California, Berkeley.

No context found.

Brent B. Welch. Naming, State Management, and UserLevel Extensions in the Sprite Distributed File System. University of California at Berkeley UCB/CSD 90/567. April 1993

No context found.

B. B. Welch. Naming, State Management, and User-Level Extensions in the Sprite Distributed File System. Ph.D. dissertation, Computer Science Division, Dept. of Electrical Engg. and Computer Sciences, University of California, Berkeley, 1990.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC