HP Tru64 UNIX and TruCluster Server Version 5.1.B-4 Patch Summary and Release Notes (13156)

Problems may occur with the duplicate request cache in some cases, under heavy NFS server
load and over high aggregate network bandwidth involving changes to file systems (changes
caused by the use of the creat, link, unlink, mkdir, rmdir, truncate, utimes,
and write commands). These problems can occur if all the elements in the duplicate request
cache are cycled between an initial client transmission and subsequent retransmission. If this
occurs, the NFS server cannot detect that the retransmission is in fact a retransmission. This may
result in the repetition of a request and may cause out-of-order writes or truncation and
subsequent retruncation of a file.
This patch kit provides a tuning variable, nfs_dupcache_size, to control the size of the NFS
server's duplicate request cache, which is measured in the number of elements that are allocated
at NFS server initialization.
If it is determined that the size of the duplicate cache needs to be modified, you should change
nfs_dupcache_size. The new value for nfs_dupcache_size should be set to equal two
times the value of nfs_dupcache_entries.
You must use the dbx command to modify nfs_dupcache_size. There is no sysconfig interface
to this tuning variable.
3.2.2.14 Performance of hwmgr Commands on Large System Configurations
On large system configurations, certain hwmgr commands may take a long time to run and can
produce voluminous output. For example:
• On a system connected to a large storage area network, the hwmgr -view devices
command can take a long time to begin displaying output, because it must first select devices
from all of the hardware components in the system and then retrieve, format, and sort the
output report.
• On a maximally configured AlphaServer GS1280 system with highly interconnected storage,
the hwmgr -view hierarchy command generates thousands of lines of output.
The output from these commands is gathered and sorted in memory before the report begins to
be displayed. In a system with hundreds or thousands of attached storage units, the processing
stage can take several minutes and you will not see any output during that time.
When using the command hwmgr -view devices -cluster, the time can be even longer
and the size of the report can be larger because in most clustered configurations, mass storage
devices are reported by every member and thus appear multiple times in the generated report.
Therefore, you may need to relax the memory limits for the process running the command,
because with such a large number of devices in the configuration, the system may be unable to
gather all of the data with the default memory limit.
We recommend that you run commands that generate large reports in the background (for
example, in a batch job) and save their output into a file or set of files for subsequent examination
or historical comparison.
3.2.2.15 LSM Spin Lock Issue
A patch in this kit addresses a spin lock issue in the LSM kernel that may occur under extremely
heavy I/O loads on multiprocessor systems.
To reduce the need for certain spin locks in the kernel I/O code, you can set a new sysconfigtab
variable, Max_LSM_IO_PERFORMANCE, to 1 (the default is 0). Doing this will increase LSM
I/O performance if it is found that performance is degraded because of a highly contentious spin
lock.
Note that using this spin lock performance feature reduces some of the debugging statistics that
are normally maintained.
In order to use this feature, you must allow at least one LSM I/O daemon (voliod). The voliod
daemon was changed to prevent the number of LSM kernel I/O daemons from being set to zero
if this spin lock performance feature is turned on.
54 Tru64 UNIX Patches