Vidya Academy of Science &

Technology, Thrissur

Network File System

CS402

Mr. Sivadasan E.T.

Associate Professor
Computer Science & Engineering
 Network File System

➢ Sun Microsystem’s Network File System (NFS)

has been widely adopted in industry and in
academic environments since its introduction in
1985.

➢ Although several distributed file services had

already been developed and used in universities
and research laboratories, NFS was the first file
service that was designed as a product.
 Network File System

➢ The design and implementation of NFS have

achieved success both technically and
commercially.

➢ NFS provides transparent access to remote files for

client programs running on UNIX and other
systems.
 Network File System

➢ The client-server relationship is symmetrical: each

computer in an NFS network can act as both a client
and a server; and the files at every machine can be
made available for remote access by other machines.

➢ Any computer can be a server, exporting some of its

files, and a client, accessing files on other machines.
 Network File System

➢ NFS protocol – a set of remote procedure calls that

provide the means for clients to perform operations
on a remote file store.

➢ The NFS server module resides in the kernel on each

computer that acts as an NFS server.
 Network File System

➢ Requests referring to files in a remote file system are

translated by the client module to NFS protocol
operations and then passed to the NFS server module
at the computer holding the relevant file system.
 Network File System

➢ The NFS client and server modules communicate

using remote procedure calls.

➢ It can be configured to use either UDP or TCP, and

the NFS protocol is compatible with both.

➢ A port mapper service is included to enable clients to

bind to services in a given host by name.
 Network File System

➢ The RPC interface to the NFS server is open: any

process can send requests to an NFS server;

➢ If the requests are valid and they include valid user

credentials, they will be acted upon.

➢ The submission of signed user credentials can be

required as an optional security feature, as can the
encryption of data for privacy and integrity.
 Virtual file system

NFS provides access transparency:

➢ User programs can issue file operations for local or

remote files without distinction.

➢ The integration for local or remote files without

distinction is achieved by a virtual file system (VFS)
module, which has been added to the UNIX kernel to
distinguish between local and remote files.
 Virtual file system

➢ The file identifiers used in NFS are called file

handles.
➢ A file handle is opaque to clients and contains
whatever information the server needs to distinguish
an individual file.
➢ The filesystem identifier field is a unique number that

is allocated to each filesystem when it is created.

 Virtual file system

➢ The i-node number of a UNIX file is a number that

serves to identify and locate the file within the file
system in which the file is stored.

➢ The i-node generation number is needed because in

the conventional UNIX file system i-node numbers
are reused after a file is removed.
 Virtual file system

➢ In the VFS extensions to the UNIX file system, a

generation number is stored with each file and is
incremented each time the i-node number is reused.

➢ A VFS structure relates a remote file system to the

local directory on which it is mounted.
 Virtual file system

➢ The virtual file system layer has one VFS structure

for each mounted file system and one v-node per
open file.

➢ The v-node contains an indicator to show whether a

file is local or remote.
 Client integration
➢ The NFS client module plays the role described for
the client module in our architectural model,
supplying an interface suitable for use by
conventional application programs.

➢ The NFS client module cooperates with the virtual

file system in each client machine.

➢ It shares the same buffer cache that is used by the

local as well as remote input-output system.
 Access control and authentication

➢ Unlike the conventional UNIX file system, the NFS

server is stateless and does not keep files open on
behalf of its clients.

➢ So the server must check the user’s identity against

the file’s access permission attributes afresh on each
request, to see whether the user is permitted to access
the file in the manner requested.
 NFS server interface

➢ The NFS file access operations read, write, getattr

and setattr are almost identical to the Read, Write,
GetAttributes and SetAttributes operations defined
for our flat file service model.
 NFS server interface
➢ The file and directory operations are integrated in a

single service;

➢ The creation and insertion of file names in

directories is performed by a single create operation,

➢ Which takes the text name of the new file and the file
handle for the target directory as arguments.

➢ The other NFS operations on directories are create,

remove, rename, link etc..
 Mount service
➢ The mounting of subtrees of remote filesystems by
clients is supported by a separate mount service
process that runs at user level on each NFS server
computer.

➢ Clients use a modified version of the UNIX mount

command to request mounting of a remote
filesystem, specifying the remote host’s name, the
pathname of a directory in the remote filesystem
and the local name with which it is to be mounted.
 Mount service

➢ The remote directory may be any subtree of the

required remote filesystem, enabling clients to mount
any part of the remote filesystem.

➢ The location (IP address and port number) of the

server and the file handle for the remote directory are
passed on to the VFS layer and the NFS client.
Mount service
 Pathname translation
➢ UNIX file systems translate multi-part file pathnames

to i-node references in a step-by-step process

whenever the open, creat or stat system calls are
used.
➢ Each part of a name that refers to a remote-mounted
directory is translated to a file handle using a
separate lookup request to the remote server.
➢ The lookup operation looks for a single part of a

pathname in a given directory and returns the

corresponding file handle and file attributes.
 Automounter

➢ The automounter maintains a table of mount points

(pathnames) with a reference to one or more NFS
servers listed against each.

➢ It behaves like a local NFS server at the client

machine.
 Automounter

➢ When the NFS client module attempts to resolve a

pathname that includes one of these mount points, it
passes to the local automounter a lookup() request
that locates the required filesystem in its table and
sends a ‘probe’ request to each server listed.

➢ The filesystem on the first server to respond is then

mounted at the client using the normal mount
service.
 Server caching
➢ In conventional UNIX systems, file pages, directories

and file attributes that have been read from disk are
retained in a main memory buffer cache until the
buffer space is required for other pages.

➢ If a process issues a read or a write request for a page

that is already in the cache, it can be satisfied without
another disk access.
➢ Read-ahead anticipates read accesses and fetches the

pages following those that have most recently been

read, and delayed-write optimizes writes.
 Client caching

➢ The NFS client module caches the results of read,

write, getattr, lookup and readdir operations in order
to reduce the number of requests transmitted to
servers.
➢ Client caching introduces the potential for different
versions of files or portions of files to exist in
different client nodes, because writes by a client do
not result in the immediate updating of cached copies
of the same file in other clients.
 Client caching
➢ Clients are responsible for polling the server to check

the currency of the cached data that they hold.

➢ A timestamp-based method is used to validate
cached blocks before they are used.
➢ Each data or metadata item in the cache is tagged

with two timestamps:

➢ Tc is the time when the cache entry was last
validated.
➢ Tm is the time when the block was last modified

at the server.
 Client caching
➢ Formally, the validity condition is:

➢ The selection of a value for t involves a compromise

between consistency and efficiency.
 Other optimizations

➢ In NFS version 3, there is no limit on the maximum

size of file blocks that can be handled in read and
write operations;
➢ Clients and servers can negotiate sizes larger than 8

kbytes if both are able to handle them.

Thank you !..