Section 14: Distributed Storage

Transcription

1 CS162 May 5, 2016 Contents 1 Problems NFS Expanding on Two Phase Commit

2 1 Problems 1.1 NFS You should do these exercises after a basic introduction to NFSv2. You should know about the design principles behind NFS. 1. NFS is designed to be stateless so that crash recovery is easy. For this reason, NFS does not keep track of clients open files because that would be difficult to maintain and recover after a crash. In order to communicate about files in a self-contained way, NFS employs file handles, which contain all information needed by the server to find a file. NFSv2 supports the following stateless protocol, built on file handles. NFSPROC_GETATTR expects: file handle returns: attributes NFSPROC_SETATTR expects: file handle, attributes NFSPROC_LOOKUP expects: directory file handle, name of file/directory to look up returns: file handle NFSPROC_READ expects: file handle, offset, count returns: data, attributes NFSPROC_WRITE expects: file handle, offset, count, data returns: attributes NFSPROC_CREATE expects: directory file handle, name of file, attributes NFSPROC_REMOVE expects: directory file handle, name of file to be removed NFSPROC_MKDIR expects: directory file handle, name of directory, attributes returns: file handle NFSPROC_RMDIR expects: directory file handle, name of directory to be removed NFSPROC_READDIR expects: directory handle, count of bytes to read, cookie returns: directory entries, cookie (to get more entries) Discuss how you would implement an NFS client to support the POSIX file system interface. Your client should support the use of file descriptors and be able to call open(), read(), write(), and close() just as it would for a local file system. The client would keep track of all open files using file descriptor mappings. When a user provides a file descriptor in a read() or a write(), the client will figure out which file the user is referring to, and send the appropriate request to the NFS server, then translate the response back to the user. 2

3 The client will also keep track of file offsets and advance them when the user calls read() or write(). Whatever file offsets are used will be translated into NFS requests. 2. NFS servers support idempotent requests. When a client fails to receive a response from the server, it just tries again until a response is received. Why are NFS read and write requests considered idempotent, while the POSIX interface is not idempotent? Discuss the pros and cons of idempotency in these protocols. NFS write requests are stateless. The same request will always write the same data to the same offset. Applying a write once has the same effect as applying it twice, and so on. As stated above, this is nice because we don t have to worry about duplicated requests wreaking havoc. Idempotent requests operate under the assumption of statelessness. The POSIX interface keeps state about open files and file offsets. This is fragile because it relies on having a reliable system. However, this is an easier interface for a user to interact with. 3. NFS clients use caches to improve performance and reduce network traffic. This introduces a new problem of cache consistency. Describe a scenario under NFSv2 that would result in a stale cache. Describe the behavior that the affected user would see. Alice s cache might become invalid if Bob changes a file while it s in Alice s cache. 4. If you were designing a distributed storage protocol, how would you solve the cache consistency problem? Be creative! (a) You could somehow notify clients of changes in files as soon as they happen (as AFS does). (b) You could have every cache access check the modification time by sending a GETATTR request to the NFS server (the semi-solution provided by NFS). (c) Servers and clients can prevent consistency problems by checking files against checksums. 5. The Andrew File System (AFS) takes a very different approach to cache consistency. Firstly, servers do store state about which clients have a copy of a file. When a file is changed, the server immediately notifies all clients with the old version of the file. Thus, clients will not suffer from stale caches. Discuss the pros and cons of AFS and NFS. AFS is stateful. If the server crashes, clients are badly affected. In NFS, a server crash would have no effect other than loss of availability. As mentioned, AFS solves the problem of cache consistency by actively invalidating client caches, but this comes at the cost of fragility. AFS Pro: Relative to NFS, less server load: (a) Disk as cache - more files can be cached locally (b) Callbacks - server not involved if file is read-only For both AFS and NFS: central server is bottleneck! (a) Performance: all writes and cache misses go to server (b) Availability: Server is single point of failure 3

4 (c) Cost: server machines high cost relative to workstation 4

5 1.2 Expanding on Two Phase Commit 1. For HW4, you implemented a slightly simplified 2PC protocol in which your leader server would continuously query its followers in the event of a crash during Phase-2. What s the problem with this design? over-simplification. follower could never come back up. 2. Suppose we extend our HW4 implementation as follows: if we receive an ABORT or timeout from one of our followers in Phase 1, we instead send a rollback message to all followers in Phase 2. We do not block on a follower if it does not respond within some timeout. What sort of data structure would you need in our followers to support rollbacks? undo log 3. Suppose that as a proof-of-concept, the CS162 staff scales up their HW4 to 100 followers with a fault tolerance of 10 followers. CS162 is low on funding so we re forced to fit our followers with cheap disks; these disks tend to fail put() and get() requests somewhat often. We decide to use a quorum consensus algorithm. Why might this be a good idea? 4. Your CS162 TA excitedly tells you that he has optimized the staff system s W and R to both be 5. Let your TA know why their system is unreliable. 5