nfs, nfs_intro - Network File System (NFS) information
NFS is a facility for sharing files in a heterogeneous
environment of processors, operating systems, and networks.
Sharing is accomplished by mounting a remote file
system or directory on a local system and then reading or
writing the files as though they were local.
Sharing file systems has the following advantages: Removes
the need to copy files across the network from one system
to another Provides easier access to remote files Reduces
the risk of having out-of-date copies of the same file on
different systems
The NFS Environment [Toc] [Back]
NFS is based on the client-server model, in which client
systems request resources from other systems called
servers. A server is any host system or process that provides
a network service. A client is any host system or
process that uses services from a server.
A single host, or server, can provide more than one service.
Servers are passive; they do not call clients, they
wait for clients to call them.
A one-to-one correspondence between servers, clients, and
systems does not always exist. A system that acts as a
server can also act as a client. A server that exports
file systems and directories can also mount remote file
systems and directories exported by other systems, thus
becoming a client. To export a file system or directory
is to make it available for NFS clients to mount remotely
on their local systems.
The /etc/exports file defines the NFS file systems and
directories that can be exported. The following table
summarizes the distinctions between client and server systems
for NFS mounts.
--------------------------------------------------------------
Client Server
--------------------------------------------------------------
Requests a remote mount Responds to the mount request
Reads the /etc/fstab file Reads the /etc/exports file
Checks if the server is known Checks if the client is known
--------------------------------------------------------------
The client always initiates the remote mount. The server
completes the bindings, subject to access-control rules
specific to NFS. Because most network administration
problems occur at bind time, you should know how a client
binds to a server and what access control policy each
server uses. For more information on access control, see
the NFS Service section and the Network Administration:
Services manual.
You mount a remote file system by using either the mount
command or an automatic mounting daemon, such as Automount
or AutoFS. In addition, you can use the WebNFS protocol,
which bypasses mount and gives direct access to the WebNFS
served file system.
An NFS client selects a specific server from which to
mount a file system or directory. A client can mount file
systems and directories from several different servers.
Network Transport Protocols [Toc] [Back]
NFS can use either the Transmission Control Protocol (TCP)
or User Datagram Protocol (UDP) protocol. The TCP protocol
is best for congested wide area networks because of
its superior retransmit features and congestion control.
The UDP protocol is best in networks where congestion and
lost messages are not a problem because its lower overhead
might yield higher throughput. The client selects the
transport protocol in the mount command.
The NFS Service [Toc] [Back]
Once a remote file system or directory is mounted, it can
be used as a local file system by client programs. Typically,
a client mounts one or more remote file systems and
directories at start up time, if lines similar to the following
are in the /etc/fstab file. The mount program
reads these lines when the system starts up: titan:/usr2
/usr2 nfs rw,bg 0 0 venus:/usr/man /usr/man nfs rw,bg 0 0
The first line in the example shows that the /usr2 directory
at system titan is mounted at local mount point /usr2
when you boot the local system. The rest of this line
describes the mount. See fstab(4) for a description of
the file format.
NFS servers control access to their resources by limiting
named file systems and directories to a specific set of
clients with an entry in the /etc/exports file. The
/etc/exports file allows you to limit access to NFS
clients but not to individual remote users. By default in
Tru64 UNIX, mounts can be limited to client superusers
only.
The following four programs implement the NFS service:
portmap mountd nfsiod nfsd
A client's mount request is transmitted to the remote
server's mountd daemon after obtaining its address from
portmap. A port mapper is a Remote Procedure Call (RPC)
daemon that maps RPC program numbers of network services
to their UDP or TCP protocol port numbers.
The mountd daemon checks the access permission of the
client and returns a pointer to the file system or directory.
After the mount is completed, access to files and
directories at and below that mount point go through the
pointer to the server's NFS daemon (nfsd) using remote
procedure calls. Some file access requests (write-behind
and read-ahead) are handled by the block I/O daemon
(nfsiod) on the client.
PC-NFS [Toc] [Back]
The PC-NFS facility provides the benefits of NFS to personal
computers on your network. PC-NFS enables personal
computers to share resources and exchange files, and like
NFS, is based on the client-server model. The client
software runs on the personal computer; the server software
resides in the /usr/sbin directory.
For information on the PC-NFS client, see your PC-NFS
client documentation.
For instructions on making the PC-NFS server available to
clients, refer to Network Administration: Services.
The NFS Locking Service [Toc] [Back]
The NFS Locking Service (rpc.lockd) allows you to create
advisory locks on files and file regions on local and
remotely mounted file systems. Advisory locks are not
enforced.
To make use of the NFS Locking Service, a programmer needs
to understand how to use the fcntl system call or the
lockf subroutine. See fcntl(2) and lockf(3) for programming
information.
File locking is a way to manage access to shared files. A
process takes the following steps when locking a file or
region of a file: Determines if the file or region within
the file is locked Applies a lock if the file or region is
not locked Makes the changes to the file or region Unlocks
the file or region
The NFS Locking Service coordinates the dispersal of locks
to remote file systems. It communicates with the kernel
and status monitor (rpc.statd) of the local system, as
well as with the other lock daemons on the network.
The NFS Locking Service uses a stateless approach to failure
recovery. The fundamental element of this approach is
that the status monitor detects both client and server
recoveries. This approach is passive. When the client
status monitor detects that a failed server has reinitialized
(recovered), it notifies the local locking daemon of
the failure. The lock daemon then activates the appropriate
recovery mechanism.
If the NFS server fails and the NFS Locking Service is
enabled, all the locks managed by the server's local processes
are lost. However, when the server recovers, the
lock manager daemons on the client systems send reclaim
requests for the NFS locks. The server lock manager
reestablishes the previously acquired locks associated
with the reclaim requests, provided the requests are
received within the grace period built into the NFS Locking
Service.
During the grace period, the server lock manager honors
only reclaim requests. Once the grace period expires,
reclaim requests are no longer valid, and the server lock
manager accepts only new requests. At this time, the
server lock manager cannot reestablish old locks. A user
process whose lock could not be reclaimed is sent a
SIGLOST signal. The client lock manager can create new
locks by using the interface primitives in the fcntl system
call or the lockf subroutine.
If a client fails while it is using the NFS Locking Service,
then when the client recovers, the status monitor
daemon notifies the appropriate servers. The server lock
manager then releases the locks. The client applications
can then issue new lock requests as part of their recovery
procedure.
Automatic Mounting Daemons [Toc] [Back]
NFS clients can optionally run an automatic mounting daemon,
such as Automount or AutoFS. These daemons are
client interfaces that perform remote mounts
automatically, and only when they are needed. If you need
to access a remotely mounted file or directory, the
selected daemon mounts it, keeping it mounted as long as
you need it.
The automount and autofsd daemons are told which remote
file systems to mount from a database file called a map.
A map lists the remote file systems that the selected daemon
monitors, their locations, and any mount options. The
maps can be shared through NIS.
There are three types of maps: Master - Although not
required, the master map helps to organize mounts. If a
master map exists, it is read first when the automount or
autofsmount commands are invoked, acting as a pointer to
other maps.
Both commands look for an NIS map called auto.master
when invoked. They can also be instructed to
use a local master map. Direct - Specifies a key
that is the pathname of the mount point, and a
location, which is the location of the file system
or directory in which it resides, specified in this
format: server:pathname. For direct maps, a local
mount point is specified as an absolute pathname,
such as /doclib. Indirect - Like a direct map,
specifies the pathname of the mount point and the
location of the file system on which it resides.
For indirect maps, a local mount point is specified
as a simple pathname, such as docsrc because the
whole map is associated with a directory.
For more information these daemons, see automount(8), autofsd(8), and autofsmount(8). Or, refer to the Network
Administration: Services manual.
Commands: autofsmount(8), automount(8), nfsstat(8)
Daemons: autofsd(8), automount(8), mountd(8), nfsd(8),
nfsiod(8), rpc.lockd(8), rpc.statd(8)
Files: advfs(4), cdfs(4), fstab(4)
Technical Overview, Network Administration: Services delim
off
nfs(4)
[ Back ] |
