COT 4600 Operating Systems Fall 2009 Dan C

  • Slides: 16
Download presentation
COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office

COT 4600 Operating Systems Fall 2009 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3: 00 -4: 00 PM

Lecture 15 n Last time: ¨ n Virtual Memory Today Domain Name Service (DNS)

Lecture 15 n Last time: ¨ n Virtual Memory Today Domain Name Service (DNS) ¨ Network File System (NFS) ¨ Question and answers about the project and the midterm ¨ n Next Time: Midterm – Attention: there is no make-up for any exam. If you miss it you need to go to the Academic Services and bring a letter stating that your absence was motivated. Important: phase 2 of the project is now due on Thursday, October, 22, together with HW 4. ¨ 2

3

3

The virtues of DNS n Distributed responsibility any DNS name server may act as

The virtues of DNS n Distributed responsibility any DNS name server may act as a naming authority and add authoritative records (see example on the previous slide, the right diagram) ¨ create lower-level naming domains; e. g. , UCF can create EECS, EECS can create Computing. Frontiers, etc. ¨ n Robustness ¨ High level of replication of the name servers n n There are some 80 replicas of the root name server Each organization with a name server has 2 -4 replicas Stateless name servers does not maintain any state, its public interface is idempotent ¨ A DNS server is a dedicated computer running a relatively simple code, thus less likely to fail ¨ 4

More virtues and some problems of DNS n Flexibility ¨ The same name may

More virtues and some problems of DNS n Flexibility ¨ The same name may be bound to several IP addresses. Needed to n n ¨ Allows synonyms n n ensure replication of services improve performance see for example the content delivery services provided by akamai a computer may appear to be in two different domains Indirect names Lack of authentication DNS does not use protocols to authenticate the response to a DNS request. One can impersonate a DNS server and provide a fake response. Does not guarantee accuracy a DNS cache may hold obsolite information 5

The Network File System n n n Developed at Sun Microsystems in early to

The Network File System n n n Developed at Sun Microsystems in early to early 1980 s. Application of the client-server paradigm. Objectives: Design a shared file system to support collaborative work ¨ Simplify the management of a set of workstations ¨ n n n Facilitate the backups Uniform, administrative policies Main design goals Compatibility with existing applications NFS should provide the same semantics as a local UNIX file system 2. Ease of deployment NFS implementation should be easily ported to existing systems 3. Broad scope NSF clients should be able to run under a variety of operating systems 4. Efficiency the users of the systems should notice a substantial performance degradation when accessing a remote file system relative to access to a local file system 1. Lecture 15 6

NFS clients and servers n n n Should provide transparent access to remote file

NFS clients and servers n n n Should provide transparent access to remote file systems. It mounts a remote file system in the local name space it perform a function analogous to the MOUNT UNIX call. The remote file system is specified as Host/Path Host the host name of the host where the remote file system is located ¨ Path local path name on the remote host. ¨ n The NFS client sends to the NFS server an RPC with the file Path information and gets back from the server a file handle ¨ n A 32 bit name that uniquely identifies the remote object. The server encodes in the file handle: A file system identifier ¨ An inode number ¨ A generation number ¨ n The handles are usable across system failures the server can use the information in the file handle after a failure. Lecture 15 7

Why file handles and not path names ----------------- Example 1 ------------------------ Program 1 on

Why file handles and not path names ----------------- Example 1 ------------------------ Program 1 on client 1 Program 2 on client 2 CHDIR (‘dir 1’) fd OPEN(“f”, READONLY) RENAME(‘dir 1’, ’dir 2) RENAME(‘dir 3’, ’dir 1’) READ(fd, buf, n) To follow the UNIX specification if both clients would be on the same system client 1 would read from dir 2. f. If the inode number allows the client 1 to follw the same semantics rather than read from dir 1/f ------------------ Example 2 -----------------------fd OPEN(“file 1”, READONLY) UNLINK(“f”) fd OPEN(“f”, CREATE) READ(fd, buf, n) If the NFS server reuses the inode of the old file then the RPC from client 2 will read from the new file created by client 1. The generation number allows the NSF server to distinguish between the old file opened by client 2 and the new one created by client 1. Lecture 15 8

The interaction between the NSF client and server n Set of RPCs; ¨ lookup(dirfh,

The interaction between the NSF client and server n Set of RPCs; ¨ lookup(dirfh, name) ¨ create(dirfh, name, attrr) remove(dirfh, name) getattr(fh) setattr(fh, attr) read(fh, offset, count) ¨ ¨ /* the FS server extracts the file system identifier and inode number /* from dirfh; then asks the identified file system to look up the inode /* number in dirfh. The selected target system uses the inode number /* to identify the directory inode. Then the NSF server searches the /* directory identified by inode for the file name. If found it returns a /* handle for the file (ifulesystem. Id+inode. Number+gennr). The NSF /* sends this file handle to the client. /* create file name with a set of attributes, attr; dirfh current directory /* remove a file /* get file attributes /* set file attributes /* read from the file with file handle fh count bytes starting at offset Lecture 15 9

The RPC triggered by the following sequence: fd OPEN(“f”, READONLY) READ(fd, buf, n) CLOSE(fd)

The RPC triggered by the following sequence: fd OPEN(“f”, READONLY) READ(fd, buf, n) CLOSE(fd) Lecture 15 10

More on RPCs n To improve performance: There is no need to issue an

More on RPCs n To improve performance: There is no need to issue an RPC to close a file open for READONLY. ¨ If the application modifies the file then the NFS client will issue a CLOSE system call on the remote file system. ¨ n n Each RPC is tagged with a transaction number; this way the only once semantics is enforced. The NFS server is stateless, this simplifies its design The only state it maintains is the disk files ¨ Every RPC must contain all the information necessary for the NFS server to execute the call. For example the READ should contain the position of the cursor. ¨ The client cannot distinguish between a slow server and a server which has failed. ¨ It is impossible to implement the UNIX system calls correctly because the UNIX specification requires that maintaining state. ¨ Lecture 15 11

Vnodes – extending UNIX file system to support NFS n n n Vnode a

Vnodes – extending UNIX file system to support NFS n n n Vnode a control structure kept in volatile memory (not on the disk) which abstracts a file or a directory; it is implemented by either the local or the remote file system. When a file system call must carry out an operation on a file it invokes the corresponding function through the vnode interface. The local file system module in UNIX contains the code for operations such as: descriptor tables, ¨ current directory ¨ Name lookup ¨ Most of this code can be moved to the file system call layer and be provide by the vnode Lecture 15 12

Example: open a file The user program issues an OPEN The file system call

Example: open a file The user program issues an OPEN The file system call layer invokes PATHNAME_TO_VNODE. It passes 1. 2. - 3. The vnode for the current directory Path name The PATHNAME_TO_VNODE Parses the path Invokes LOOKUP for every element of the pathname If the directory specified by the pathname is a local directory then the vnode layer LOOKUP invokes the LOOKUP procedure implemented on local file system to obtain a vnode for the pathname component. If the directory specified by the pathname is a remote directory then the vnode LOOKUP invokes the LOOKUP procedure implemented by the client. Next the NSF client invokes the LOOKUP RPC call on the NFS server passing as arguments the file handle. 4. 5. The NFS server extracts the file system identifier, and the inode number. Then looks up the directory vnode, invocks the LOOKUP in the vnode layer and passes the pathname as argument. The vnode layer invokes LOOKUP procedure implemented by the local file system. The local file system looks up the name and if present creates a vnode and returns the vnode file handle to the NFS client Lecture 15 13

Example Lecture 15 14

Example Lecture 15 14

Coherence n n Read/write coherence is guaranteed only for OPEN and CLOSE and it

Coherence n n Read/write coherence is guaranteed only for OPEN and CLOSE and it is called CLOSE-TO-OPEN coherence. NFS close-to-open coherence: The client stores with each block of data in its cache the modification of the block’s vnode at the time the client reads the data from the server. ¨ When a user program opens a file the client sends a GETATTR request to fetch the last modification of the file. It does not read the block unless it was modified from the version in cache. ¨ The client WRITE modifies only the cached version. ¨ At the time of a CLOSE the client sends the cached version to the server/ ¨ Lecture 15 15

Lecture 15 16

Lecture 15 16