Open System Services NFS Management and Operations Guide

Configuration and Reliability
To increase the reliability of the OSS NFS subsystem:
• Configure the OSS NFS manager process and the port mapper process to run as process
pairs (specify BACKUPCPU with the RUN command).
• Configure the LAN and SERVER objects with the BACKUPCPU attribute to enable automatic
restart in case of failure.
• Place the subvolumes reserved for OSS NFS configuration files and the OSS data files on
mirrored disk volumes.
Reliability Risks in File Operations
This topic describes some reliability risks inherent with OSS NFS files and suggests how to minimize
them.
Lack of OSS NFS Concurrency Control
Applications in the Guardian environment can use protected-write access so that two users cannot
simultaneously modify the same file. However, OSS NFS does not provide such concurrency control;
that is, two users can simultaneously edit the same file, and there is no mechanism to protect them
from overwriting each other.
Client-Side NFS Caching
NFS clients typically keep a cache of data read from NFS files, which makes the lack of concurrency
even more of a problem. Many NFS clients also perform buffered writes, and UNIX applications,
like text editors, might cache an entire file in memory. These modes of operation greatly increase
the potential for lost data in the event of network or workstation failure. All writes buffered in
memory are lost.
These risks do not mean that NFS should not be used to edit files—only that it should not be used
to edit the single master copy of files. Instead, use a version-control scheme where a working copy
of the file is checked out, edited and tested, then checked back in. The check-out mechanism
provides concurrency control by indicating when a file is already checked out. The master copy
would be vulnerable to corruption only if a failure occurs during the check-in process, and at that
time, a valid working copy would still be available.
OSS NFS Component Restart Recovery
Many situations can cause OSS NFS components to be restarted, including software updates,
warm starts, and processor failures. Such a restart can be made without loss or corruption of data
if the REUSE-SERVERID attribute of the SUBSYS object is TRUE. When this attribute is FALSE, file
handles cached in the client are no longer valid and OSS NFS clients are required to remount the
filesets on the NonStop system.
Backup Using Client Workstations
OSS NFS can be used to back up files, but the NFS protocol does not provide the same facilities
that are available on NonStop systems.
Configuration and Reliability 67