The Sun File System

The SUN file system is a widely used commercial implmentation of a file service. As part of its networking strategy SUN put the key interfaces into the public domain. This has meant that other system manufacturers have been able to interface to SUN equipment. Thus a network running SUN NFS can support IRIS machines, HP machines and PCs as well as many other machines.

This is the system used at SJU.

Design Goals of NFS

Access transparency

NFS provides an API that looks just like the Unix file system. Existing programs can thus run without modification.

Location transparency

Each client mounts remote file systems into its name space. Thus the hierarchical file system appears local although some of it is remote.

Failure Transparency

The service is stateless and most of the operations for file access are idempotent.

Preformance transparency

Both client and server employ caching to achieve satisfactory performance.

Migration transparency

NFS provides a mount service that allows for file systems to be mounted from several servers. Originally all the required file systems were mounted at boot time. This proved to be cumbersome now thay are automounted that is to say mounted when a request for soem file in the system is made.

Issues that were not addressed were

Replication transparency

NFS does not support file replication. NIS is a separate service that supports the replication of simple databases.

Concurrency transparency

NFS does not improve on the rudimentary Unix locking faclities.

Scalability

Originally desigend on the assumption that each server would have 5 - 10 clients.

Implementation

The interface to the file service is achieved through a virtual file system in the Unix kernal. This interfaces to both the local file system and an NFS client. The NFS client senmds requests to the NFS server. Which can [perform the following operations.

lookup(dirfh, name)

Returns a file handle and the attributes for the file name in the directory dirh

create(dirfh, name, attr)

Create a new file name in the directory dirfh with attributes attr and returns the new file handle and attributes.

remove(dirfh, name)

Removes file form the directory returns status

getattr(fh)

Get attributes of fh

setattr(fh, attr)

det attributes of fh

read(fh, offset, count)

Returns up to count bytes of data form a file starting at offset. Also returns the latest attributes of the file.

write(fh, offset, count, data)

Writes count bytes from data at offset returns new attributes

rename(dirfh, name, newdirfh, newname)

renames the file (like mv)

link(newdirfh, newname, dirfh, name)

Creates an entry in the directory newfh referring to name in dirfh

symlink(newdirfh, newname, string)

Create an entry newname in the directory newdirfh of type symbolic link with value string

readlink(fh)

Returns the string that is associated to the symbolic link identified by fh

mkdir(dirfh, name, attr)

Creates a new directory name with attributes attr and returns the new file handle and attributes

rmdir(dirfh, name)

removes the (empty) directory name from the parent directory dirfh

readdir(dirfh, cookie, count)

Returns up to count bytes of directory entries from dirfh. cookie is an opaque pointer to the next entry in the directory, 0 gives first entry.

stats(fh)

returns file system information for the file system containing fh

Other Issues

• File Handles: file system id , inode number of file, inode generation number (needed since conventional Unix reuses inodes)
• vnodes are kept by the Virtual file system. Ther eis one for each open file. It shows in particular whether the file is local or remote.
• Access control. The server must check access rights on each request.
• Path name translation is handled by the client. This may involve several machines.
• Mount service. Remore file systems are mounted into the local file system. this can be a hard mount or a soft mount In a hard mount user processes requesting service are blocked until the request is satisfied. In soft mount thay are notified after a preset number of unsucessful tires.
• Automounter. This allows remote file systems to me automatically mounted whenever an empy mount point is reached in acerssing a file. The automounter probes the listed severs to find which one is ready to serve the system.
• Server caching. NFS servers use a write through cache.
• Client Caching Results of reads, writes, getattr, lookup and readdir are cached. Note that client writes do not cause a write of the original file. Timestamps are used to manage consistency.

Return to Networks home page

Last Changed: 1 November 1995