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?