Upload
victor-fox
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
Sun NFSDistributed File SystemPresentation by Jeff Graham and David Larsen
Sun NFS Overview• OS Independence
• NFS specification written with many UNIX file system similarities, but allows for OS agnostic implementation
• Stateless server, stateful client (Kind of……)
• Simplicity in crash recovery
• No need for server to maintain memory of past transactions (Kind of…..)
• Implemented on UDP/IP (RPC) – though TCP may also be used.• TCP useful in that the transport layer can prevent duplicate requests
• Transparency in Access
• Sun’s NFS client written to allow network file access be transparent to user
• Once mounted, using remote file system is just as easy as using local file system
NFS Architecture Diagram
Paper’s Comparison of Major v2 and v3 Differences
Version 2
• 32 Bit File Sizes
• Synchronous Writes Only
• No ability to check pre-op file attributes
• Directory contents and file attributes requested individually
Version 3
• 64 Bit File Sizes
• Synchronous and Asynchronous Writes Allowed
• Introduction of pre-op and post-op attributes for weak cache consistency
• Provides support for directory contents and file attributes in a single operation
Stateless Server• Simplified Crash Recovery
• Idempotentcy
• Many requests (such as reading data) idempotent by nature
• Others, such as creating, moving, and deleting files are not• Servers maintain a duplicate request cache to prevent replays of recent requests
• Most servers store this cache in RAM, so a server crash can lead to destructive request duplication
• Implementations may store some other types of state
• Read-ahead caching for expected read requests
• File locking can be problematic (and inherently stateful)
• Additional lock daemon necessary
• Server crashes cause locks to be lost
Stateful Clients• Client stores data not committed to server
• Weak cache consistency
• Client caches and compares file attributes (modified time) for cache invalidation• Compare pre-operation attribute to post-operation attribute
• Based on result of comparison, client that updated the file knows if its cached data is correct or not
• Saves client from having to re-download file from NFS server unnecessarily
• Clients responsible for validating data after a server crash
Crash Recovery• Unique 8-byte write verifier changed after server crash
• Client uses this to know if it must re-commit data that would have been lost if server crashed
• Client/Server contract: server may not discard uncommitted data without changing this identifier
• Client re-sends uncommitted data upon detecting that a server crash occurred
• Implementation question: update write verifier after a clean shutdown?
Synchronous Writes• Client requests synchronous write
• Server must commit data to stable storage before responding
• Server sends confirmation to client once data is stored
• Client does not need to track data that is confirmed as written
Asynchronous Writes• Client requests asynchronous write
• Server acknowledges write request• Acknowledgment means only that server has received request
• Data may or may not be stored to stable storage
• Client responsible for confirming (via a COMMIT request)• Once server responds to COMMIT request, data has been saved
• Client is responsible for caching all data until COMMIT is verified.
Paper’s Comparison of v2 and v3 Performance – Sequential Writes
Critical Review of NFS Paper
Presented Idea
• Paper focused on comparing NFS Version 3 to Version 2
Potential Improvement
• While clearly meant to compare Version 2 to Version 3, some comparisons to performance of other network file systems would be helpful.
Critical Review of NFS Paper
Presented Idea
• Paper presents no description for how multiple clients can share the same file without ill effects
Potential Improvement
• Include information on how file locking or other safety measures can be used
Sun NFS Drawbacks• Weak support for multiple users needing to modify the same file
• Implementations can allow encryption, but it is not part of the protocol
• Cross-implementation capability would be difficult, perhaps impossible, if not defined in the protocol
Questions?