CMSC 421 Operating Systems Lecture Notes
(c) 1995 Howard E. Motteler


NFS (Network File System)
==========================

In NFS, the file system resides on one or more `file servers'

NFS manages the communication between clients and servers

  - Servers `export' part or all of their directory tree

    (exports are specified in /etc/exports)

  - Clients import (i.e., mount) these file systems 

    ("Mount" is the unix command to attach a file system 
      at some point in an existing directory tree, e.g., 
      mount /dev/fp021 ~/floppy )

  - Clients can then access selected directories and files
     on the server


NFS Protocols
==============

NFS does not require that all machines run the same OS,
so the client/server interface must be well defined

Client/server interactions are via network messages
(typically via UDP, User Datagram Protocol)

The NFS protocol defines the format of these messages


NFS mount protocol
-------------------

The mount command lets a client access parts of a server's
file system

To do a mount, a client sends the server

   - a mount request, including

   - a path name on the server

The server does not care where the client mounts the directory

If the requested path exists and has been exported, the server
returns a `file handle' to the client

The file handle contains the following information (relative
to the server):

   - file system & disk info

   - i-node of directory

   - protection info


Such mounts are usually done at system startup

/etc/rc is a script (or family of scripts, these days) that
runs at boot time and may contain export and mount commands)


Directory and File Access Protocol
-----------------------------------

Clients send messages to read and write files and directories  

   - When a client does an open(fname,...), the system
     sends the server a LOOKUP(fname) request

   - The server returns a "file handle" if the file exists
     and has been exported

   - When the client doe a read(chan,...), the system sends
     the server a READ(handle, offset, size) request

(Writes are done similarly)

The server does not have to maintain tables of files open for
clients; it is said to be "stateless"

There is no OPEN or CLOSE message; LOOKUP serves for OPEN


NFS Implementation
===================

There are three software layers

   - system call layer 
   - virtual file system  (VFS; v-nodes)
   - NFS client/server    (communication; r-nodes)


[ NFS layer figure ]


The system call layer handles the sys calls open, read,
write, etc.  This layer

   - checks arguments
   - parses file paths
   - calls the VFS


The VFS maintains a table of `virtual i-nodes', or `v-nodes',
one for each open file

In general, every v-node points either to an 

   - r-node  (in the NSF client layer), or an
   - i-node  (in the local OS)


Example: suppose we execute the following command on k-9.cs
-------

  mount  boskone.cs:/usr/local/bin  /bogey/bin  <flags>
           [server is boskone]      [client is k-9]

The mount program on k-9

  - parses the paths

  - sends a request to boskone.cs for the file handle
    for /usr/local/bin (on boskone)

The NFS server on boskone (typically "nfsd") 

  - checks /etc/exports to see if it is ok to export 
    /usr/local/bin

  - If so, a file handle for this directory is sent to k-9

The mount program on k-9 then does the following

  - The NFS client layer constructs a `remote node' (r-node),
    to hold the file handle it just received

  - The VFS on k-9 has a v-node for /bogey/bin (the directory
    must exist for a mount to be valid)

  - this v-node is set to point to the new r-node, which
    contains the handle for /usr/local/bin on boskone


Now, suppose k-9 tries to run /bogey/bin/emacs

  - The pathname /bogey/bin/emacs is parsed

  - The v-node for /bogey/bin is gotten

  - This v-node points to an r-node, so we get the remote
    file handle H1

  - The remote file handle H1 points to the `bin'
    subdirectory of /usr/local/bin on boskone.cs

  - `bin/emacs' is looked up on boskone.cs, and a file handle
     H2 is returned, that points to emacs on boskone

  -  An r-node is made on k-9.cs to hold the handle H2

  -  A v-node is made, to point to this r-node

Emacs can now be read (or loaded, to run) through this v-node


Efficiency
===========

Transfers are typically done in 8K blocks

Client automatically asks for `next block' 
(this is called `read ahead')

Both servers and clients have caches

Server cache is a `regular' file system cache

Clients have 

   - attributes (i-node cache)
   - data cache

When an i-node (v-node) or data block is needed, the cache is
checked first

Caching causes problems when sharing data among several clients

Caches are flushed regularly

This helps, but does not *guarantee* that NFS will still behave
the same as a single local file system


Locks (exclusive file access) are sometimes needed

These are difficult with NFS; the simple stateless server
allows programs to have out-of-date copies


Security
=========

Some sort of authentication is needed

  - Old NFS simply included user and group id with messages
  - (but how does server know who is *really* sending messages?)
  - Some version now use encryption to authenticate transactions

The NIS (Network Information Service) database stores

  - key/value pairs
  - encrypted passwords
  - maps machine names to addresses