Distributed Computer Systems

1. Distributed Computer Systems • Distributed File Systems • Characteristics • File Services Components • Design Issues • The SUN Network File System (NFS)

2. A Traditional File systemLayered Design File File IDs Name • Each layer depends on the layers below it. Directory module File module Access control module File access module Block module Device module iNode checks permission for operation read or write file data Access allocated blocks Disk I/O and buffering 3

3. Distributed file service • Fulfills a function similar to the conventional ones • Provides user programs with access to remote files without copying them to a local disk. • Provides access to files from diskless nodes. 4

4. Ttransparency Support • Network transparency • Concurrency transparency • Failure transparency • Replication and Migration transparency 5

5. Network Transparency • Access • Single set of operations to access local and remote files. • Programs written to operate on local files and remote file. • Location • Clients should see a uniform file name space • Files can be relocated without changing their pathnames 6

6. Concurrency Transparency • There should not be a conflict if two or more clients are changing the same file simultaneously. • Most file services follow UNIX standards in: • providing advisory (coordinate independent processes) or • mandatory file or record-level locking • Standard I/O system calls enforce the locking protocol • With the cost of lower access speed 7

7. Failure Transparency • Design can be based on at-most –once semantics or, • Maybe Call semantics with a server designed in terms of idempotent operations (duplicate requests do not result in invalid updates of files) or, • Stateless servers- so that they can be restarted after failure without having to recover previous state

8. File Service components • A flat file service • Directory service • Client module User Program User Program User Program Client Module Application Programming Interface Network File service RPC interface Directory service RPC Interface Directory Service File service 12

9. Client computer Server computer Directory service Application Application program program Flat file service Client module File service architecture Coulouris et al Figure 8.5 - Addison-Wesley

10. Flat File service • Exports an interface for use by clients. • Implements operations on contents of files. • All flat file service requests use unique File Descriptors • When a new file is created the flat file service generates and returns a new file descriptor 13

11. Directory service • Exports an interface for use by clients. • Provides a mapping between text names for files and their file descriptors. • Provides functions for obtaining file descriptors and updating directories. • It is a client of flat file service: • its directory files are stored in files of flat file service. 14

12. Client Module • A single client module runs in each client computer. • Extends the operations of flat file and directory service. • Holds information about the network locations of the flat file server and directory server processes. • Can implement a cache of recently-used file blocks at the client. 15

13. Design Issues: flat file service • Offer a simple, general purpose set of operations. • Fault tolerance • Stateless servers • Idemponent server operations: • Design RPC interface in terms of idempotent operations 16

14. Statefull servers • In a Stateful Filing System • A file is opened before it is read(written), • All internal information are copied into internal system tables. • The client specific information can be maintained between requests • then closed after use. • If a server fails and the client continues running, all the internal information held by the server is lost! 9

15. Stateless Servers • A client sends a request to the server • The server • carries out the request • sends a reply to client • removes from its internals all client-specific information • No client-specific information is maintained between requests. 10

16. Design Issues-Directory services • Separation of directory service from the file service: • A single file service can use different directory services, each supporting a different name syntax and access control regime. • For example the same file service can be used with both UNIX and MS/DOS directory services. 17

17. Interfaces: Flat File Service • An interface is list of service procedures. • Typical RPC interface for flat file service: Read (File, i, n) (Data) Reads a sequence up to n items in File starting at i and returns it in Data Write (File, i, Data) Writes a sequence of Data to File starting at i. Create() File Creates a new file of length 0 and delivers a UFID for it. Delete(File) Removes File from the file store Truncate (file, l) If l<Length(File):shorten the file to length l. GetAttributes(File) Attr Returns the file attributes. SetAttributes(File, Attr) Sets the file attributes. 19

18. Interfaces: Directory Service • A typical RPC interface for the directory service: Lookup(Dir, Name, AccessMode, UserID) Locates text name in directory and returns the relevant UFID. (File) AddName (Dir, Name, File, UserID) If Name is not in the directory, add the (Name, File) pair to directory Removes the entry containing Name If Name already exists. UnName (Dir, Name) Replaces the OldName by NewName if OldName already exists ReName(Dir, OldName, NewName) Returns all the text names in the directory that match the regular expression given by Pattern GetNames (Dir, Pattern) NameSeq 20

19. The Sun Network File System (NFS) • A de facto standard supported by many vendors. • Provides transparent access to remote files for clients running on UNIX and other systems. • Supports symmetrical client-server relationship. • Support for hardware and OS heterogeneity. • Can be configured to use either TCP or UDP 21

20. Transparency support • Access transparency • Location transparency* • Failure transparency • Performance transparency • Migration transparency 22

21. Location Transparency • Each client establishes a file name space by adding remote file systems to its local name space: • File systems have to be exported by their server nodes and remote-mounted by a client. Server 1 Client Server 2 / (root) / (root) / (root) export People Jane Craig John ... ... vmunix usr nfs users Joe ann james Remote mount Remote mount x staff students 23

22. Figure 8.10Coulouris et alLocal and remote file systems accessible on an NFS client Note: The file system mounted at /usr/students in the client is actually the sub-tree located at /export/people in Server 1; the file system mounted at /usr/staff in the client is actually the sub-tree located at /nfs/users in Server 2.

23. Mounting • The client obtains the first file handle for a remote file system when it mounts it • File handles are passed from the servers to clients in the results of lookup, mkdir, and create operations and • From the clients to the servers in the argument list of all server operations

24. Client computer Server computer Application Application program program UNIX system calls UNIX kernel UNIX kernel Virtual file system Virtual file system Local Remote UNIX UNIX Other file system NFS NFS file file client server system system NFS protocol NFS architectureCoulouris et al

25. NFS layers • The RPC interface - integrates file and directory operations • Handles system calls such as read, write, mkdir, link, lookup, ... • The Virtual File System layer • Distinguishes between local and remote files • Translates between UNIX-independent identifiers used by NFS and internal file handles. • Message handling layer • The NFS clients and servers modules communicate using RPC. 25

26. Virtual File System layer (VFS) • Has one VFS structure for each mounted file system and one v-node per open file. VFS structure Remote File System relates a remote file system to the local directory on which it is mounted. Local Directory v-node local local file index(i-node) local/remote indicator file reference file system id i-node inode generation remote File handle of the remote file 26

27. Virtual File System layer (VFS) • File handle is derived from UNIX I-node by adding the 2 extra fields VFS structure file system id i-node inode generation Remote File System relates a remote file system to the local directory on which it is mounted. Local Directory v-node local local file index(i-node) local/remote indicator file reference file system id i-node inode generation remote 26 File handle of the remote file

28. Client Caching • The client module caches the results of read, write, getattr, lookup and readdir. • Writes by client do not result in the immediate updating of cached copies of the file in other clients so • NFS uses a timestamped-based method to validate cached blocks: • Every time a client caches a block it also caches the last modified time. 29

29. Client integration in UNIX • The client module is integrated with the kernel and is not supplied as a library for loading into client processes so: • users can access files via UNIX system calls without recompilation or reloading; • A single client module serves for all user level processes, with a shared cache of recently-used blocks.

30. Server integration in UNIX • The NFS server is integrated with the UNIX kernel mainly for performance reasons. • The servers use cache at the server machine to access files. • The write operation is replaced by write-through operation when cache is use: • Any write to cache must immediately modify corresponding disk blocks.