Download presentation
Presentation is loading. Please wait.
Published byJerome Cannon Modified over 8 years ago
1
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 1 Distribuerede systemer – 26. februar 2001 Presentation based on slides by Coulouris et al, modified by Jens B Jorgensen
2
2 Chapter 8: Distributed File Systems From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001
3
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 3 File systems - purpose zOrganization, retrieval, naming, sharing and protection of files. zConvenient programming interface to disk storage. zAccess control and file-locking. zA file service: yEnables programs to store and access remote files exactly as they do local ones. yReduces the need for local disk storage and eases management and archiving.
4
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 4 File systems - concepts zFile: Sequence of data items together with set of attributes. zDirectory: A file providing a mapping from text names to internal file identifiers. zMetadata: File attributes, directories and all other persistent information used by the file system.
5
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 5 File systems - attribute record structure File length Creation timestamp Read timestamp Write timestamp Attribute timestamp Reference count Owner File type Access control list
6
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 6 File systems - modules
7
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 7 File systems - UNIX file system operations filedes = open(name, mode) filedes = creat(name, mode) Opens an existing file with the given name. Creates a new file with the given name. Both operations deliver a file descriptor referencing the open file. The mode is read, write or both. status = close(filedes)Closes the open file filedes. count = read(filedes, buffer, n) count = write(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer. Transfers n bytes to the file referenced by filedes from buffer. Both operations deliver the number of bytes actually transferred and advance the read-write pointer. pos = lseek(filedes, offset, whence) Moves the read-write pointer to offset (relative or absolute, depending on whence). status = unlink(name)Removes the file name from the directory structure. If the file has no other names, it is deleted. status = link(name1, name2)Adds a new name (name2) for a file (name1). status = stat(name, buffer)Gets the file attributes for file name into buffer.
8
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 8 Distributed file systems – required transparencies zAccess transparancy. zLocation transparency. zMobility transparency. zPerformance transparency. zScaling transparency.
9
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 9 Distributed file systems – other requirements zConcurrent file updates. zFile replication. zHardware and operating system heterogeneity. zFault tolerance. zConsistency. zSecurity. zEfficiency.
10
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 10 Distributed file systems – file service architecture (1) zFlat file service: yOperations on the contents of files. yUses UFIDs – unique file identifiers. zDirectory service: yMapping between text names and UFIDs. yGeneration of directories, addition of file names to directories, … zClient module: yProvides API for flat file services and directory service to user-level programs in client computers. yCaching of recently used file blocks.
11
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 11 Distributed file systems – file service architecture (2) Client computerServer computer Application program Application program Client module Flat file service Directory service
12
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 12 Distributed file systems – flat file service operations Read(FileId, i, n) -> Data —throws BadPosition If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items from a file starting at item i and returns it in Data. Write(FileId, i, Data) —throws BadPosition If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to a file, starting at item i, extending the file if necessary. Create() -> FileIdCreates a new file of length 0 and delivers a UFID for it. Delete(FileId) Removes the file from the file store. GetAttributes(FileId) -> Attr Returns the file attributes for the file. SetAttributes(FileId, Attr) Sets the file attributes..
13
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 13 Distributed file systems – directory service operations Lookup(Dir, Name) -> FileId — throws NotFound Locates the text name in the directory and returns the relevant UFID. If Name is not in the directory, throws an exception. AddName(Dir, Name, File) —throws NameDuplicate If Name is not in the directory, adds (Name, File) to the directory and updates the file’s attribute record. If Name is already in the directory: throws an exception. UnName(Dir, Name) —throws NotFound If Name is in the directory: the entry containing Name is removed from the directory. If Name is not in the directory: throws an exception. GetNames(Dir, Pattern) -> NameSeq Returns all the text names in the directory that match the regular expression Pattern.
14
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 14 Distributed file systems – flat file service (FFS) versus UNIX file system zUNIX has open and close operations and a read/write pointer. zFFS has no open or close operations and no notion of a read/write pointer. zFFS characteristics: yRepeatable operations, idempotent operations, at-least- once RPC semantics. yStateless servers, possible to resume operation after failure without restoration of state.
15
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 15 Distributed file systems – other issues zAccess control: yServer RPC interface is an unprotected point of access to files; require user identification. yOften, user identity submitted with every client request, and access checks performed by the server for every file operation. zHierarchic file system: A number of directories arranged in a tree structure; reference files using pathnames. zFile grouping: Collection of files located at a given server; supports movement.
16
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 16 Sun NFS - basics zNFS: Network File System. zProvides transparent access to remote files. zThe NFS protocol allows clients to perform operations on a remote file store. zThe NFS server module resides in the kernel on each computer that acts as an NFS server. zRequests referring to files in a remote file system are translated by the client module to NFS protocol operations. zThe NFS protocol is an RPC protocol.
17
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 17 Sun NFS - architecture UNIX kernel protocol Client computerServer computer system calls LocalRemote UNIX file system NFS client NFS server UNIX file system Application program Application program NFS UNIX UNIX kernel Virtual file system Other file system
18
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 18 Sun NFS – virtual file system (VFS) zDistinguishes between local and remote files. zTranslates between UNIX-independent file identifiers used by NFS and the internal file identifiers used in UNIX and other file systems. zKeeps track of the filesystems that are currently available, both locally and remotely. zPasses each request to the appropriate local system module.
19
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 19 Sun NFS – file handles zFile identifiers used in NFS. zContains the information the server needs to distinguish an individual file. zFile handle consists of: yFilesystem identifier. yi-node number of file. yI-node generation number. zThe client obtains the first file handle for a remote file system when it mounts it. zFile handles are passed between servers and clients.
20
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 20 Sun NFS – NFS client module zSupplies an interface for application programs. zEmulates the semantics of the standard UNIX file system primitives. zIs integrated with the UNIX kernel. zTransfers blocks of files to and from the server. zCaches blocks in local memory whenever possible.
21
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 21 Sun NFS - NFS server module (operations, simplified, extract) lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory dirfh. create(dirfh, name, attr) -> newfh, attr Creates a new file name in directory dirfh with attributes attr and returns the new file handle and attributes. remove(dirfh, name) status Removes file name from directory dirfh. getattr(fh) -> attr Returns file attributes of file fh. (Similar to the UNIX stat system call.) setattr(fh, attr) -> attr Sets the attributes (mode, user id, group id, size, access time and modify time of a file). Setting the size to 0 truncates the file. read(fh, offset, count) -> attr, data Returns up to count bytes of data from a file starting at offset. Also returns the latest attributes of the file. write(fh, offset, count, data) -> attr Writes count bytes of data to a file starting at offset. Returns the attributes of the file after the write has taken place. rename(dirfh, name, todirfh, toname) -> status Changes the name of file name in directory dirfh to toname in directory to todirfh. link(newdirfh, newname, dirfh, name) -> status Creates an entry newname in the directory newdirfh which refers to file name in the directory dirfh.
22
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 22 Sun NFS - mount service zA mount service process runs on each NFS server computer. zA file (/etc/exports) contains the names of local filesystems that are available for remote mounting. zClients request mounting of a remote filesystem by specifying: yRemote host name. yPathname of a directory in the remote filesystem. yThe local name with which it is to be mounted. zServer returns file handle of specified directory.
23
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 23 Sun NFS - local and remote file systems accessible on a 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.
24
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 24 Sun NFS – server caching zFile pages are held in a main memory buffer cache until the buffer space is required for other pages. zRead operations raise no consistency problem. zWrite operations offer two options: yWrite-through: Data in write operations received from clients is stored in the memory cache at the server and written to disk before a reply is sent to the client. yCommit required: Data in write operations is stored only in the memory cache. It will be written to disk when a commit operation is received for the relevant file.
25
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 25 Sun NFS – client caching zPossibly different versions of files or portions of files in different client nodes. zNFS client module caches results of read, write, getattr, lookup, and readdir operations. zTimestamp-based method used to validate cached blocks before they are used. zValidation may involve getattr calls to server. zWhen a cached page is modified, it is marked as dirty and scheduled to be flushed to the server asynchronously.
26
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 26 Andrew File System - basics zProvides transparent access to remote shared files for UNIX programs. zAccess to AFS files via the normal UNIX file primitives. zMain design goal: Scalability. zDesign characteristics: yWhole-file serving. yWhole-file caching.
27
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 27 Andrew File System – files usage patterns zFiles are small. zRead operations are much more common than write operations. zSequential access is common; random access is rare. zMost files are read and written by only one user. zFiles are referenced in bursts.
28
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 28 Andrew File System - architecture
29
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 29 Andrew File System - file name space seen by clients
30
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 30 Andrew File System - main components of the Vice service interface Fetch(fid) -> attr, dataReturns the attributes (status) and, optionally, the contents of file identified by the fid and records a callback promise on it. Store(fid, attr, data)Updates the attributes and (optionally) the contents of a specified file. Create() -> fidCreates a new file and records a callback promise on it. Remove(fid)Deletes the specified file. SetLock(fid, mode)Sets a lock on the specified file or directory. The mode of the lock may be shared or exclusive. Locks that are not removed expire after 30 minutes. ReleaseLock(fid)Unlocks the specified file or directory. RemoveCallback(fid)Informs server that a Venus process has flushed a file from its cache. BreakCallback(fid)This call is made by a Vice server to a Venus process. It cancels the callback promise on the relevant file.
31
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 31 Andrew File System - system call interception
32
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 32 Andrew File System - implementation of file system calls
33
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 33 Andrew File System – cache consistency zWhen Vice supplies a copy of a file to a Venus process, it also provides a callback promise. zA callback promise guarantees that the Venus process will be notified when other clients modify the file. zCallback promises have two states, valid or cancelled. zVice must maintain states (with callback promises). zCallback mechanism gives a dramatic reduction in the number of client-server interactions.
34
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 34 Summary zFile systems. zDistributed file systems. zSun Network File System. zAndrews File System.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.