Systems Programming Lec8 - Distributed File Services, Study notes of Computers and Information technologies

Download Systems Programming Lec8 - Distributed File Services and more Study notes Computers and Information technologies in PDF only on Docsity!

1111

Systems Programming

Distributed File Systems

2 Distributed File Systems – Overview A distributed file service is an essential component of any distributed system, providing: ► Access to data files ► Access to application executable files ► Access to system configuration information stored in files ► Persistent location-transparent Inter-Process Communication (IPC) via shared files (used by some distributed applications). Key challenges include: ► Transparency ► Reliability ► Performance

4 Distributed File Systems – Overview File management systems typically have a layered module structure, with each module depending only on the layers below it: Directory module: Relates user-attributed filenames to file IDs File module: Relates file IDs to particular (physically stored) files Access control module: Checks permission for operation requested File access module: Reads or writes file data or attributes Block module: Accesses and allocates disk blocks (see note 1) Device module (disk device driver): Disk I/O and buffering (see note 2) Note1. A file is physically stored as one or more disk blocks. Note2. The disk device driver provides low-level access to the physical disk.

5 Distributed File Systems – Transparency requirements 1 The following aspects of transparency are requirements for a distributed file service: Access transparency Client programs should be unaware of the distribution of files. A single set of operations is provided for access to local and remote files. Programs written to access local files should not have to be modified in order to access remote files. Location transparency Client programs should not have to know the true location of the files they use. Client programs should see a uniform file name space. The name space should appear the same from any computer.

7 Distributed File Systems – Transparency continued Consider the transparency issues of the following scenarios:

• (^) Word – Accessing a file on C:
• (^) Word – Accessing a file on J:
• (^) FTP used to transfer a file
• (^) File explorer used to copy files from C: to a USB memory drive In each case consider the extent of transparency in terms of:
• (^) Access
• (^) Location

8 Distributed File Systems – Requirements beyond transparency Support for hardware and operating system heterogeneity

• because heterogeneity is so prevalent in distributed systems
• typically computers chosen to host services have very different characteristics to those used for front-end access. Scalability
• because systems need to be able to grow and be reconfigured with minimal disruption. Replication transparency
• needed in large systems for reasons of performance, low-latency (including geographical proximity), reliability. Migration transparency
• often NOT supported, but makes reconfiguration (especially dynamic automated reconfiguration) much easier and more effective (for example to balance loads on servers.

10 Distributed File Systems – File Sharing Semantics 1 The way in which file sharing is provided, in terms of Atomicity, Locking etc. is known as file sharing semantics. There are several well-known file sharing Semantics: Method Comment UNIX Semantics Every operation on a file (e.g. read, write) is instantly visible to all processes (forced serializability). Easy to implement if there is only one copy of each file held by the file service and no client caches. (direct remote access to a single central copy) Session Semantics Files are ‘locked’ for the duration of the access session (delimited by an Open and a Close). Only the client that has opened the file can see intermediate states of the file. Other clients only see the effects of changes after the file has been closed. This is a barrier to concurrency. Good if concurrent access to files is rare.

11 Distributed File Systems – File Sharing Semantics 2 Method Comment Immutable Files No updates are possible - A new version of the file must be created. Clients that have cached the file receive an invalidation message when a new version is created. Simplifies sharing and replication. Transactions All changes have the all-or-nothing property. Necessary for consistency where replica writeable copies exist. Good way of achieving concurrency transparency (so long as the ACID properties are met).

13 Distributed File Systems – Replication and Consistency 2 R/W Cached copy of file R/O Cached copy of file Invalid copy of file Write^ Read Client process 1 Client process 2 Client process 3 Hard disk File service main storage File server process In this animation, assume all file accesses are to the same file Request fileSend file Request file R/O Cached copy of file Send file Read Request fileSend file Read Update file Invalidate (^) invalidate Invalid copy of file

14 Distributed File Systems – File service components 1 User Program User Program User Program Client module Directory Service module File Service module Application Programming Interface Directory service RPC/RMI interface File Service RPC /RMI interface Not aware of the underlying structure or complexity of the file access Network interface

16 File service This service is concerned with implementing operations on the contents of files ( read , write ). Unique File Identifiers (UFIDs) are used to refer to files in all requests to the file system. Directory Service The directory service provides a mapping between text names and UFIDs. It also provides the functions for generating and updating directories and creating / deleting files ( create dir , delete dir , create file , delete file , list files in directory ). Client Module A single client module runs on each client computer, and integrates the operations of the file service and the directory service under a single API; this is available to user programs in client computers. In particular the client module must provide location transparency to the application programs. The application programs should only have to specify a file by its filename, regardless of location. The client module may implement a caching system. Distributed File Systems – File service components: division of responsibilities

17 Distributed File Systems – The Sun Network File System (NFS) NFS provides transparent access to remote files for client programs running on UNIX (originally) and now is available for many systems. NFS is: ► the de-facto standard distributed file system, and a useful reference scheme by which to measure others, ► the oldest distributed file system standard still in popular use, ► the most-used distributed file system (apart from the Microsoft native file system used in front-end access systems), ► the most ubiquitous file system – available for almost every platform (H/W and O/S). Typically every computer in the system will have both NFS client and server modules installed in its system kernel: → Each computer can act as both a client and server and the files at every machine can thus be made available for remote access. However in larger systems it is common to dedicate some machines to providing the file service.

19 Distributed File Systems – Concurrency transparency root exports people oneil steve jens server root nfs users krishna jennifer nitish server root usr students staff client remote mount Remote mounting NFS filesystems ( physical view ) The students and staff directories are ‘mount points’ remote mount

20 Distributed File Systems – Concurrency transparency oneil steve jens (^) krishna jennifer nitish root usr students staff client Remote mounting NFS filesystems ( logical view ) The ‘mount points’ are transparent, the different physical file systems are seen as one logical filesystem