1 / 14

Sun NFS

Sun NFS. Distributed File System Presentation 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……)

moshe
Download Presentation

Sun NFS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sun NFS Distributed File System Presentation by Jeff Graham and David Larsen

  2. Sun NFS Overview • OS Independence • NFS specification written with many UNIX file system similarities, but allows for OS agnostic implementation • Stateless server, statefulclient (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

  3. NFS Architecture Diagram

  4. Paper’s Comparison of Major v2 and v3 Differences Version 2 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 • 32 Bit File Sizes • Synchronous Writes Only • No ability to check pre-op file attributes • Directory contents and file attributes requested individually

  5. 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

  6. 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

  7. 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?

  8. 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

  9. 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.

  10. Paper’s Comparison of v2 and v3 Performance – Sequential Writes

  11. Critical Review of NFS Paper Presented Idea Potential Improvement While clearly meant to compare Version 2 to Version 3, some comparisons to performance of other network file systems would be helpful. • Paper focused on comparing NFS Version 3 to Version 2

  12. Critical Review of NFS Paper Presented Idea Potential Improvement Include information on how file locking or other safety measures can be used • Paper presents no description for how multiple clients can share the same file without ill effects

  13. 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

  14. Questions?

More Related