• Choose a category
• All
• Classic-Fiction

By Root 379 0

any utility to correlate the filehandles printed in the error messages with the pathname of the file on the remote server. Filehandles are generated by the NFS server and handed opaquely to the NFS client. The NFS client cannot make any assumptions as to the structure or contents of the filehandle, enabling servers to change the way they generate the filehandle at any time. In practice, the structure of a Solaris NFS filehandle has changed little over time. The following script takes as input the filehandle printed by the NFS client and generates the corresponding server filename:[2]

#!/bin/sh

if [ $# -ne 8 ]; then

echo "Usage: fhfind e.g."

echo

echo "fhfind 1540002 2 a0000 4d 48df4455 a0000 2 25d1121d"

exit 1

fi

FSID=$1

INUMHEX='echo $4 | tr [a-z] [A-Z]'

ENTRY='grep ${FSID} /etc/mnttab | grep -v lofs'

if [ "${ENTRY}" = "" ] ; then

echo "Cannot find filesystem for devid ${FSID}"

exit 1

fi

set - ${ENTRY}

MNTPNT=$2

INUM='echo "ibase=16;${INUMHEX}" | bc'

echo "Searching ${MNTPNT} for inode number ${INUM} ..."

echo

find ${MNTPNT} -mount -inum ${INUM} -print 2>/dev/null

The script takes the expanded filehandle string from the NFS write error and maps it to the full pathname of the file on the server. The script is to be executed on the NFS server:

mahimahi# fhfind 800006 2 a0000 3ef 12e09b14 a0000 2 4beac395

Searching /spare for inode number 1007 ...

/spare/test/info/data

The eight values on the command line are the eight hex digits in the filehandle reported in the NFS error message. The script makes strict assumptions about the contents of the Solaris server filehandle. As mentioned before, the OS vendor is free to change the structure of the filehandle at any time, so there's no guarantee this script will work on your particular configuration. The script takes advantage of the fact that the filehandle contains the inode number of the file in question, as well as the device id of the filesystem in which the file resides. The script uses the device id in the filehandle (FSID in line 10) to obtain the filesystem entry from /etc/mnttab (line 13). In line 11, the script obtains the inode number of the file (in hex) from the filehandle, and applies the tr utility to convert all lowercase characters into uppercase characters for use with the bc calculator. Line 18 and 19 extract the mount point from the filesystem entry, to later use it as the starting point of the search. Line 21 takes the hexadecimal inode number obtained from the filehandle, and converts it to its decimal equivalent for use by find. In line 26, we finally begin the search for the file matching the inode number. Although find uses the mount point as the starting point of the search, a scan of a large filesystem may take a long time. Since there's no way to terminate the find upon finding the file, you may want to kill the process after it prints the path.

Throughout this chapter, we used tools presented in previous chapters to debug network and local problems. Once you determine the source of the problem, you should be able to take steps to correct and avoid it. For example, you can avoid delayed client write problems by having a good idea of what your clients are doing and how heavily loaded your NFS servers are. Determining your NFS workload and optimizing your clients and servers to make the best use of available resources requires tuning the network, the clients, and the servers. The next few chapters present NFS tuning and benchmarking techniques.

* * *

[2] Thanks to Brent Callaghan for providing the basis for this script.

Chapter 16. Server-Side Performance Tuning

Performance analysis and tuning, particularly when it involves NFS and NIS, is a topic subject to heated debate. The focus of the next three chapters is on the analysis techniques and configuration options used to identify performance bottlenecks and improve overall system response time. Tuning a network and its servers is similar to optimizing a piece of user-written code. Finding the obvious flaws and correcting poor programming