Chapter Contents |
Previous |
Next |
Using the NFS Client |
fstab
, specifies a mount that occurs at session or program startup.
Saving File-System Context |
The serial sharing of file system context is accomplished
by using the
mnttab
file. Not sharing context can be easier. When only a few file
systems are mounted, reissuing the mounts in each program can be faster than
reading and writing the
mnttab
file. NFS mounts are very fast and involve
minimal processing on the server.
Unfortunately, processing the
mnttab
file at program
startup and shutdown adds noticeable delays to otherwise fast commands and
programs. The NFS sample programs
cd
,
pwd
, and
ls
illustrate this. Overall NFS performance is much better when a single
program does many operations. Sharing is required, however, if working directory
changes are to be preserved from one program to the next. You should always
save the file-system context when you are working with the SAS/C Debugger
in a cross-development environment.
You do not need to create the
mnttab
file yourself. The
NFS client library will create it automatically. It will also be deleted each
time you log on to the NFS server. Note that, unlike the conceptually similar
UNIX
/etc/mnttab
file, this file has a binary format. It also contains information,
notably the current working directory, that is held by the kernel in UNIX.
Finally, the
mnttab
file cannot be shared simultaneously
by many programs. If you are managing multiple programs that use NFS concurrently,
either set up multiple
mnttab
files or set them up not to save context at
all.
To avoid serial sharing, do not set the environment
variable. In this case, the MOUNT command and the sample cd
command appear to have no effect, because the changes that
they request are not saved when they end. When not sharing file system context,
you invoke all your mounts with the
fstab
configuration file.
Setting Up an fstab Configuration File |
When NFS starts with no
mnttab
file available, either because
there is no serial sharing of file system context or because NFS has not yet
been used, the NFS client library searches for an
fstab
configuration file
that specifies which initial mounts to perform. The
fstab
file removes the
need to issue mount commands manually each time NFS is used.
The
fstab
configuration file format is identical to that
used in most UNIX systems. It should have a series of lines that specify mount
points that use the following format:
server : directory mount-point type options
Fields are separated by white space, and any fields that
follow the options parameter are ignored. You can also include
comments in the
fstab
configuration file. The pound (#) character that appears at the
beginning of a line or that is preceded by white space indicates that the
rest of the line is a comment.
Note:
It must not be a name that
was created by NFS client features of the server. This is a common source
of confusion. Users of the NFS server are often accustomed to specifying directory
names that are not physical directories on their system. As discussed earlier,
the design of NFS does not cause these names to be propagated automatically
to NFS clients of that server.
The mount-point parameter
must be a pathname in the directory hierarchy that is being created on the
mainframe. In order for the first directory to be mounted, the mount point
must be a slash (/), which indicates the root directory. Following NFS conventions,
later mount points must be actual directories in a file system that have already
been mounted. The directories that are being mounted then obscure the contents
of the directory that they are mounted on.
The type parameter must be
nfs
. As in UNIX, the table definition is generalized to accommodate
multiple types of file systems; however, at present only NFS file systems
are supported.
Mount options, which are described in Mount Options, generally are not needed.
Example fstab configuration file shows a typical
fstab
configuration file:
Example fstab configuration file
# My NFS setup byrd.unx:/local/u/bill / nfs #No mount options server.unx:/tools /tools nfs ro # Mount tools read-only elgar.langdev:c:/ /lang nfs # Mount from OS/2
This example assumes that the
/local/u/bill
directory
on
byrd.unx
contains subdirectories that are called
tools
and
lang
. Presumably these
are empty directories that were set up to serve as mount points for the second
and third mounts. If they are not empty, any contents that they have are obscured
to the mainframe user by the second and third mounts. Instead of seeing the
contents of the local directories, the corresponding directory trees from
the
/tools
directory on server.unx and the
c:/
directory on
elgar.langdev
are seen by the mainframe user at those locations.
The
fstab
data set is located in the following manner:
ETC_FSTAB
, its value is used. Note that the default style is
ddn:
. Remember to include
the style at the beginning of the name if you want a different one, such as
in
tso:etc.fstab
.
NFS_PREFIX
environment variable.
The
fstab
data set cannot itself be accessed with the
path:
prefix. See Accessing Files for information about the
path:
prefix.
Mount Options |
Mount Options contains the options that you can specify.
Chapter Contents |
Previous |
Next |
Top of Page |
Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.