Lecture 22: Distributed File What is distributed Systems clients

local cache cache cache disk n (NFS) u v2 n Distributed file u v3 network system is a part of n Andrew File System (AFS) distributed system u the original that provides a user with a unified view u DCE Distributed File System (DCE DFS) servers cache cache of the files on the network.

server server server disk disk disk

A machine that holds the shared files is called a server, a machine that 2 accesses the files is called a client. 3

Design goals for a distributed file Distributed file system design system considerations n A machine that holds the shared files is called a server, a machine that n network transparency - clients should be able to access remote files accesses the files is called a client. using the same operations that apply to local files. n stateful or stateless operation u n location transparency - the name of the file should not reveal its location stateful server retains information about the client operations in the network. between requests and uses this state information to service n User mobility - users should be able to access shared files from any subsequent requests. Requests such as open or seek are inherently node in the network. stateful - ether client or server has to remember the state information. Stateless server requests - are self-contained - no n Fault tolerance - the system should continue to function after failure of a information needs to be kept in between. single component (a server or a network segment). It may, however, u degrade in performance or make part of the file system unavailable. stateful server is faster (it can take advantage of the knowledge of client’s state to eliminate network traffic); stateless servers can n Scalability -0 the system should scale well as its load increases. Also, it recover from failures easier. should be possible to grow the system incrementally by adding components. n semantics of sharing u n File mobility - it should be possible to move the files from one physical Unix semantics - the changes made by one client to a file are location to another in a running system. immediately visible to other clients accessing this file u session semantics - changes are propagated to other clients when 4 the file is either opened or closed. 5

Remote Procedure Calls (from previous lectures) Network File System (NFS) v2

pack unpack n call parameters parameters call developed by in 1985, now supported by Each RPC most Unix and some non-Unix systems. client client server stub stub server invocation by a n NFS is a protocol by which machines share files client process calls return return n NFS is stateless - no requests to open and close a file. unpack pack a client stub, which results results Read/write operations (unlike Unix read and write) pass the builds a message offset of the file as a parameter kernel kernel and sends it to a n simple crash recovery - no persistent information about the client is server stub maintained on server - in client crashes the server is not affected; if server crashes - the client keeps repeating the request until it is network satisfied (the server is back online) n problem with statlessness - the writes have to be committed to n The server stub uses the message to generate a local stable storage before reporting successful completion of the procedure call to the server write. Why? This includes inodes as well as data blocks of a file n If the local procedure call returns a value, the server stub builds a message and sends it to the client stub, which receives it and returns the result(s) to the client 6 7 Network File System (NFS) v2 (cont.) NFS v2 performance improvements, v3 n Client-side caching: u every NFS operation requires network access - slow. client can cache user-level client process the data it currently works on to speed up access to it. system calls u problem - multiple clients access the data - multiple copies of cached UNIX kernel UNIX kernel data may become inconsistent. u Solutions - cache only read-only files; cache files where inconsistency virtual file system is not vital (inodes) and check consistently frequently local remote NFS n deferral of writes UNIX protocol UNIX NFS NFS u client side - the clients bunch s together (if possible) before file client server file write system system sending them to server (if the client crushes - it knows where to restart) u a sever must commit the writes to stable storage before reporting them to a client. Battery backed non-volatile memory (NVRAM) is used local network local (rather than the disk). NVRAM -> disk transfers are optimized for disk disk disk head movements and written to disk later. n v3 allows delayed writes by introducing commit operation - all writes are client computer server computer “volatile” until the server processes commit operation. n Virtual file system - abstracts the functions of a file system from it’s n Requires changes in semantics - applications programmer cannot assume implementation, can be implemented over various FS 8 that all the writes are done and should explicitly issue commit . 9

NFS Andrew File System (AFS) network appliances n Developed in Carnegy-Mellon University in 1982 (dedicated n AFS was made to span large campuses and scale well therefore NFS the emphasis was placed on offloading the work to the clients servers) n as much as possible data is cached on clients, uses session semantics - cache consistency operations are done when file is opened or closed n Auspex NS500 n AFS is stateful, when a client reads a file from a server it holds a n NW and FS run callback, the server keeps track of callbacks and when one of the functional multi- clients closes the file (and synchronizes it’s cached copy) and processing updates it, the server notifies all the callback holders of the change kernel (FMK) - a breaking the callback, callbacks can be also broken to conserve “stripped down” version of Unix (no shared memory, processes never storage at server terminate) which allows NW and FS to context switch fast and service n problems with AFS: requests quickly. NW receives a request - if its NFS it passes it to FS if u not a processor running regular Unix (SunOS) services it. even if the data is in local cache - if the client performs a write a complex protocol of local callback verification with the server must be used; cache consistency preservation leads to deadlocks 10 11 u in a stateful model, it is hard to deal with crushes.

DCE Distributed File System (DCE DFS) AFS vs. NFS

n NFS is simpler to implement, AFS is cumbersome n Modification of AFS by Open Software Foundation for its due to cache consistency synchronization Distributed Computing Environment (DCE) mechanisms, etc n one of the major modifications - cache consistency n NFS does not scale well - it is usually limited to a mechanism is streamlined by using tokens. Each file LAN, AFS scales well - it may span the Internet contains a tokens for, n NFS performs better than AFS under light to u data, status, lock, etc. medium load. AFS does better under heavy load n a client can “check out” a token from a server for a n NFS does writes faster. particular file. Only if a client holds a lock token the client is allowed to modify the file; if a client holds status token it is allowed to modify status of the file n tokens provide finer degree of control than callbacks of AFS

12 13