Sun NFS Overview

Network File System (NFS) is a protocol originally developed by Sun

Microsystems in 1984 as a distributed file system which allows a computer to
access files over a network as easily as if they were on its local disks. NFS is one
of many protocols built on the Open Network Computing Remote Procedure Call
system (ONC RPC).

Terminology
Server
contains all of the files and directories responsible for maintaining the file
system.
Client
requester of directory and file information does the actual reading and
writing of files
file handle
a way to access a file without giving the file name similar to a file
descriptor on a local file system
RPC
Initial implementations of RPC used the UDP communication protocol
o if no response in a certain amount of time, just re-send the request
Today both UDP and TCP are used
o implemented on top of the IP protocol
Virtual File System
Major goal of NFS is system independence
Concept of the Virtual File System (VFS)
o this is an interface that the client side must implement
o if implemented properly, the client can then communicate with the
NFS server regardless of what type of system each is
Can allow different file systems to live on the same client
Increasing Performance
Cache directory entries
o allows for fast pathname traversal
For small executable files
o send the entire file on execution
o versus demand page-in of executable file
o most small executable files touch all pages of the file
o a form of read-ahead
Hard Issues
Authentication
o user passes uid and gid on each call
o very large number of uids and gids on a distributed system
o NFS uses a yellow pages
o just a big database of users and their rights
Concurrent Access
o what if two users open a file at the same time?
o could get interleaved writes

especially if they are large writes.

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
Suns 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

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
request
Data may or may not be stored to stable storage

received

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.

Benefits of NFS
1)
2)
3)
4)
5)
6)

Cross platform Data sharing ( file system independent)

Machine based access ( Security)
Simple to implement ( widely used)
Open standard ( RFC 1813) for NFS version 3
Completely transparent to the file system ( can manage large database)
Security integrated with NTFS: makes more secured NFS resource

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
************