Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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
Benefits of NFS
1)
2)
3)
4)
5)
6)