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


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

(A loosely coupled file system for loosely coupled hardware)

(Sections: Intro, Protocols, Implementation)


In NFS, the file system resides on one or more _file servers_

_Client_ machines can access files on the server

Clients can share directories and files 


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)


A network OS like NFS must manage 

   - individual workstations
   - file servers
   - communications

(NFS does not require that all machines be running the same OS)

Communication is through _protocols_ that give form and meaning
to the messages


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

Client and server interface must be well defined
(especially if we are running more than one OS)

Protocols define the possible client-server interactions


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

To do a mount, a client sends the server
   - a mount request, with 
   - a path name on the server

The server does not care where the client mounts the directory

If server path name is legal and has been exported, the server
returns a _file handle_ to the client

The file handle contains

   - file system & disk info
   - i-node of directory
   - protection info
     (all relative to the server)

(Exports and mounts are often done at boot time)

(/etc/rc is a script run at boot time and usually
 contains export and mount commands)


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

Clients send messages to read and write files and directories  

To read a file

   - On open, client sends server a `LOOKUP file name' request

   - Server returns a file handle

   - Client sends server `READ(handle, offset, size)' requests

(Writes are similar)

The _server_ does not have to remember anything about open
connections 

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


Problems with NFS:

Locks (exclusive file access) are more complicated

Authentication is necessary

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

[ The NIS (Network Information Service) database stores:

   - key/value pairs (given a key, it returns the value)
   - encrypted passwords
   - maps machine names to addresses ]


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

Three software layers:

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

The system call layer 
   - handles sys calls open, read, write, etc.
   - parses file paths
   - checks arguments
   - calls the VFS

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


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

  mount boskone.cs:/usr/local/bin /home/motteler/bin2 <flags>
             [server]                 [client]

The mount program:

   - parses the paths

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

The NFS server on boskone (on receiving the request) 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 k-9 NFS client layer constructs a `remote node' (r-node),
to hold the file handle

The k-9 VFS layer constructs a v-node for /usr/local/bin
(similar to i-node request)

The v-node is set to point to the r-node

Every v-node points either to an 
   - r-node  (in the NSF client layer), or an
   - i-node  (in the local OS)

Now, suppose k-9 tries to run bin2/emacs

The pathname `bin2/emacs' is parsed

The v-node for bin2 is gotten

The 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

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