Download Distributed file System, Lecture Slide - Computer Science and more Slides Computer Numerical Control in PDF only on Docsity!
Distributed File Systems
Arvind Krishnamurthy
Spring 2004
Distributed File Systems
n A distributed file system provides transparent access to
files stored on a remote disk
n Usage scenario:
n You login into any zoo machine, access your home directory n Your project partner works on the workstation next to you, shares files with you
n How do you support it? Or rather, how do you implement:
n Open(filename) Ë file-descriptor n Read(file-descriptor, position, size) Ë array of bytes n Write(file-descriptor, position, size, array of bytes) Ë status
Issues
1) System size: what is the target system size?
n NFS: dozens of workstations n Sprite: 100’s of workstations n AFS: 1000’s of workstations n As the scale increases, what extra issues do you have to worry at larger scale?
2) Sharing/transparency:
n Name transparency: all three systems support n AFS: local disks, shared component n NFS: diskless, local/shared n Sprite: single shared file system, supports remote devices
3) Locating File Servers
n NFS approach
n Extend mount table: add host name n Has to be on a local disk, replicated
n AFS:
n System-wide table, special protocol for obtaining current copy n Forwarding when files move
n Extreme approach: broadcast every file name
n Servers know what files they serve, respond to broadcast n Can be cached to minimize broadcasts n On failure, broadcast request
Consistency
n Consistency is different from synchronization
n Weaker than synchronization n Reads return the value of previous write
n AFS:
n Freeze the file on open n If file changes, client gets notified. Next time client refetches the file
n NFS:
n Version number, checks occasionally, flushes if different
n Sprite:
n Version numbers, check on open, callbacks to disable caching when there is write-sharing
Failures
n What if server crashes?
n Can client wait until server comes back up, and continue as before?
n Issues: n Any data in server memory but not yet on disk can be lost n Shared state across RPCs. n Example: open, seek, read. What if server crashes after seek? n Message re-tries – suppose server crashes after it does “rm foo”, but before acknowledgement
n What if client crashes? n Might lose modified data in client cache
NFS Protocol: Stateless
n Write-through caching – when a file is closed, all modified
blocks are sent immediately to the server disk
n To the client, “close” doesn’t return until all bytes are
stored on disk
n Stateless protocol: server keeps no state about client,
except as hints to help improve performance
n Each request gives enough information to do entire operation ReadAt(inumber, position) not Read(openfile) n When server crashes and restarts, can start processing requests immediately as if nothing happened
NFS Protocol (contd.)
n Most operations are “idempotent”
n All requests are ok to repeat n If server crashes between disk I/O and message reply, client can resend message, server just does operation all over again n Read and write file block is easy (just re-read or re-write) n What about “remove”? NFS does the remove twice, and returns an error the second time
n Failures are transparent to client system
n Is this a good idea? What should happen if server crashes? Suppose you are in the middle of reading a file, and server crashes n Option 1: hang until server comes back up n Option 2: return an error n NFS does both – can select which one
Hoarding
n AFS keeps recently used files on local disk
n Most of what you need will be around
n Users can specify “hoard lists” to tell Coda to cache a
bunch of other things even if not already stored locally
n System can also learn over time which files a user tends to
use
Consistency
n What if two disconnected users write the same file at the
same time?
n No way to use callback promises since server and client cannot communicate
n Coda’s solution: cross your fingers, hope it does not
happen, and pick up pieces if it does
n Log of changes kept while disconnected n Apply changes upon reconnect n If conflict detected, try to resolve automatically, else ask the user
n In practice, unfixable conflicts almost never happen
