NFS notes

idea of mounting another filesystem

  O          O
 / \        / \
O   O<-----O   O     
   / \        / \
  O   O      O   O


or, the idea of a thin client, where the tree looks like this
  O<-----O (client)
 / \
O   O   
   / \
  O   O

there are device drivers for hard drives, disk drives, disk partitions, 
CD/DVD roms, but the network is somewhat different. so we use ... Network 
File System!

NFS was developed by Sun in (TIME) with the goal of becoming the de-facto 
UNIX standard for sharing files. They claim to have mostly succeeded at 
this.

NFS is a client-server architecture. The server makes filesystems 
accessible through a process called "exporting." clients can request to 
mount a filesystem, and then send requests for reading/writing files

RFC 1094
Originally, the server was intended to keep track of as little state as 
possible. In the original RFC, Sun explained that a stateless server could 
better serve its clients in the event of a server failure. Clients could 
simply repeat their requests until the server went back up, and the server 
would be able to service them as soon as possible, since it has no state 
to be lost. This is not to say that the server does not track any state at 
all, since files and directories inherently have state. Just that Sun 
wanted to avoid adding extra state in the protocol. Because of this, file 
locks and remote execution are implemented as separate services.

Uses a hierachical file system, with all internal nodes of the tree being 
directories. each entry in a directory has a name. When traversing 
directories, NFS looks components of the path one at a time, so that 
operating systems can avoid conversions from one format of path to another 
(eg, from /bin to D:\bin). One potential problem is that the server itself 
may mount remote filesystems, and thus there is the possibility for 
circular links, since any machine may be both a client and server.

The original implementations of NFS were highly insecure. To obtain a file 
handle, the client sends a filename to the server, and recieves a 
structure containing information for accessing the file, most importantly 
the inode number of the file. To read from a file, the client requests the 
inode number, offset, and number of bytes desired. There was originally no 
problem simply fishing for "interesting" files ("payroll.db, eh?") by 
guessing inode numbers. Basically, early versions had no real security. 
Later versions improved on this.

Organization:

System Calls (open, close, write, etc)
 |
 v
Virtual File System (V-Node tables) ->remote servers
|        
V         
Local
Devices


Read Ahead
Usually NFS client will request 8kb of data from the server, even if 
current process wants less. this improves efficiency through locality of 
reference. Also, the client will requst the next 8kbs from the server 
immediately after recieving the first, and cache the results, to further 
improve performance. 

NFS has had a lot of impact on UNIX development. Most systems use the 
Vnode table now, Sometimes as part of the OS itself, even if they arent 
speficically NFS, so that they can implement the features of NFS 
themselves. Sun RPC


http://www.ietf.org/rfc/rfc1094.txt
http://www.ietf.org/rfc/rfc1813.txt
http://www.ietf.org/rfc/rfc3530.txt
http://www.uwsg.iu.edu/usail/network/nfs/overview.html
The Textbook