This document provides an overview of the Network File System (NFS) protocol. It discusses NFS's design goals of being stateless and transport independent. The document describes how NFS uses remote procedure calls and operates in a client-server model to provide a remote file system that maintains the same interface and semantics as a local Unix file system. It also covers NFS transport, operations, and differences between versions NFSv3 and NFSv4.

1. BITS Pilani
Pilani Campus
Data Storage Technologies
& Networks
Dr. Virendra Singh Shekhawat
Department of Computer Science and Information Systems

2. BITS Pilani, Pilani Campus
Topics
• Network File System protocol (NFS)
– Design goals
– Interface
– NFS Transport
– Operation
2

3. BITS Pilani, Pilani Campus
What is NFS?
• A remote file system protocol
– Designed and implemented by Sun Microsystems
– Provides Unix-like file system interface and
semantics
• It is implemented as a Client-Server application
– Client part imports file systems (from other
computers)
– Server part exports (local) file systems
• i.e. makes it visible on the network and enables access
from other computers
3

4. BITS Pilani, Pilani Campus
NFS Design Goals
• Stateless protocol
– Increased robustness – easy recovery from failures
• Support for Unix filesystem semantics
– Also supports other semantics such as MS-DOS
• Protection and Access Control same as Unix
filesystem semantics
• Transport-independent protocol
– Originally implemented on top of UDP
– Easily moved to TCP later
– Has been implemented over many non-IP-based
protocols.
4

5. BITS Pilani, Pilani Campus
NFS Design Limitations
• Design for clients and servers connected on a
locally fast network.
– Does not work well over slow links nor between
clients and servers with intervening gateways
• Stateless protocol
– Session state is not maintained
5

6. BITS Pilani, Pilani Campus
NFS- Transport[1]
• Uses a Request – Response model
– Server receives RPC – Remote Procedure Call –
requests from clients
– Can be run on top of stream (e.g. TCP) or datagram
protocol (e.g. UDP)
• Each RPC message may need to be broken into
multiple packets to be sent across the network.
– May typically require up to 6 packets
– May cause problems in UDP – in case of failure,
entire message must be retransmitted
6

7. BITS Pilani, Pilani Campus
NFS – Transport[2]
• Remote Procedure Call (RPC)
– Client sees a procedure call interface (akin to a local
procedure call)
– But the call (along with the parameters) is marshalled
into a message and sent over the network
• Marshalling may involve serializing
• Server unmarshalls the message (i.e. separates it
into pieces) and processes it as a local operation.
• The result is similarly marshalled by the server and
sent to the client which in turn unmarshalls it.
7

8. BITS Pilani, Pilani Campus
NFS- Interface
• NFS RPC requests
– Idempotent Operations(i.e. NFS client may send the
same request one or more times without any harmful
side effects)
• GETATTR, SETATTR, LOOKUP, READLINK, READ, WRITE, CREATE,
SYMLINK, READDIR, STATFS
– Non-Idempotent Operations
• REMOVE, RENAME, LINK, MKDIR, RMDIR
• Idempotency is significant because of
– slow links and lost RPC acks.
• Each file on the server is identified by a globally
unique file handle
– created when a lookup is sent by client to server
8

9. BITS Pilani, Pilani Campus
NFS- Operation[1]
• NFS protocol is stateless
– Each request is independent
• Server need not maintain information about clients and their
requests
• In practice, server caches recently accessed file
data.
– It improves performance
– and is useful for detecting retrials of previously serviced
requests
• Transaction-Commit semantics implies high
overhead:
– Synchronous writes are required for write operations.
9

10. BITS Pilani, Pilani Campus
NFS- Operation[2]
• NFS is a client-server protocol
– No discovery or registry is used.
• i.e. client must know the server and the filesystem
– Server’s filesystem has to be exported (by
mounting).
• Refer to mount system call on Unix
• Each server has a globally unique id (guid)
• Client application need not distinguish
between local and remote files
– i.e. once a filesystem is mounted applications use
the same interface for both types of files
10

11. BITS Pilani, Pilani Campus
NFS - Operation[3]
• NFS is a client-server protocol
– File manager part of client file system remains the same
as that for the local file system
• Only the file store is local or remote
• Each remote file that is active manifests as an
nfsnode in the client’s filesystem
– Recall the active file data structures:
• Per-Process File Descriptor
– Kernel File Entry
– vnode
– file-store-specific data structure
» inode for local file store and
» nfsnode for remote filestore
11

12. BITS Pilani, Pilani Campus
NFS - Operation
• Basic Protocol (Mounting): Client C, Server S
– C (mount process) -----> S(portmap daemon)
• request port address of mountd
– S (portmap daemon) ----> C
• return the port address of its mountd
– C (mount process) ----> S(mountd daemon)
• request mounting of filesystem [pathname]
– S (mountd daemon):
• get file handle for desired mount point from kernel
– S (mountd daemon) ---> C
• return filehandle of mountpoint OR error
12

13. BITS Pilani, Pilani Campus
NFS - Operation
• Basic Protocol (I/O Operation): Client C, Server S
– C (app. process): write system call
• Data is copied into kernel buffer and call returns
• nfsiod daemon wakes up
– C (nfsiod daemon) -----> S(nfs_rcv)
• Request write [buffer contents]
– S delegates request to nfsd daemon
• nfsd daemon invokes write on disk and waits for I/O
– S (nfsd daemon) ---> C (nfsiod daemon)
• return ack for the write operation
13

14. BITS Pilani, Pilani Campus
NFSv3 vs NFSv4
• NFSv3
– One RPC per RTT
– Port mapper service required to determine which network
port to listen or connect
– No caching
• NFSv4 features
– Access control lists (similar to Windows ACLs)
– Compound RPCs
– Client side caching
– Operation over TCP port 2049
– Mandating Strong security (Kerberos v5 for cryptographic
services)
14

15. BITS Pilani, Pilani Campus
Thank You!
15