Design and Implementation of the Sun Network File System

Introduction

• The network file system(NFS) is a client/service application that provides shared file storage for clients across a network.
• An NFS client grafts a remote file system onto the client’s local file system name space and makes it behave like a local UNIX file system.
• Multiple clients can mount the same remote file system so that users can share files.

Goals

• The design of NFS had four major goals.
  
  • It should work with existing applications, which means NFS ideally should provide the same semantics as a local UNIX file system.
  • It should be easy to retrofit into existing UNIX systems.
  • The client should be implementable in other operating systems
    such as Microsoft’s DOS, so that a user on a personal computer can have access to the files on a n NFS server.
  • It should be efficient enough to be tolerable to users.

NFS Implementation

Three main layers

• System call layer:Handles calls like open, read and close.
• Virtual File System Layer
  
  • Maintains table with one entry (v-node) for each open file.
  • v-nodes indicate if file is local or remote.
    
    • If remote it has enough info to access them.
    • For local files, FS and i-node are recorded.

• NFS Service Layer

  • This lowest layer implements the NFS protocol.

• 

NFS Client/Server Structure

• Client programs have file descriptors, current directory, &c.
• When client programs make system calls.
  
  • NFS v-node implementation sends RPC to server.
  • Kernel half of that program waits for reply.
  • So we can have one outstanding RPC per program.
• Server kernel has NFS threads, waiting for incoming RPCs.
  
  • NFS thread acts a lot like user program making system call.
  • Find vnode in server corresponding to client’s vnode.
  • Call that vnode’s relevant method.

The NFS File Handle

• A mounter sends a remote procedure call to the file server host and asks for a file handle.
• A file handle is a structured name,containing a file system identfier, an inode number, and a generation number-which it uses to locate the file.
• Why use file handles to name files and directories instead of path names.
  
  • 
  • When program 1 invokes READ, program 1 would read “dir2/f” according to the UNIX specification.
  • Unfortunately, if the NFS client were to use path names, then the READ call would result in a remote procedure for the file “dir1/f”.
  • To avoid this problem, NFS clients name files and directories using file handles.

The NFS remote procedure calls

- The NFS remote procedure calls are designed so that the server can be stateless, that is the server doesn’t need to maintain any other state than the on-disk files.

Consistency

• Close-to-open consistency
  
  • If I write() and then close(), then you open() and read(), you see my data, otherwise you may see stale data.
  • When a user program opens a file, the clients check with the server if the client has the most recent version of the file in its cache.
    
    • If so, the client uses the version in its cache.
    • If not, it removes its version from its cache.
  • The client implements READ by returning the data from the cache, after fetching the block from the server if it is not in the cache.
  • The client implements WRITE by modifying its local cached version, without incurring the overhead of remote procedure calls.
  • When the user program invokes CLOSE on the file, CLOSE will send any modifications to that file to the server and wait until the server acknowledges that the modifications have been received.
• 

---

文章下载