Chapter 5. Maintaining ONC3/NFS
Prev |  | Next

## Chapter 5. Maintaining ONC3/NFS

This chapter provides information about maintaining ONC3/NFS. It explains how to change the default number of NFS daemons and modify automatic mounter maps. It also gives suggestions for using alternative mounting techniques and avoiding mount point conflicts. It also describes how to modify and delete CacheFS file systems.

This chapter contains these sections:

- “Changing the Number of NFS Server Daemons”

- “Temporary NFS Mounting”

- “Modifying the Automatic Mounter Maps”

- “Mount Point Conflicts”

- “Modifying CacheFS File System Parameters”

- “Deleting a CacheFS File System”

## Changing the Number of NFS Server Daemons

Systems set up for NFS normally run four `nfsd` daemons.`nfsd` daemons, called NFS server daemons, accept RPC calls from clients. Four NFS server daemons might be inadequate for the amount of NFS traffic on your server. Degraded NFS performance on clients is usually an indication that their server is overloaded.

To change the number of NFS server daemons, create the file `/etc/config/nfsd.options` on the server if it doesn't already exist and specify the number of daemons to start at system startup. For example, to have the `/etc/init.d/network` script start eight `nfsd` daemons, the `/etc/config/nfsd.options` file needs to look like this:

    cat /etc/config/nfsd.options
    8

Modify this number only if a server is overloaded with NFS traffic. In addition to increasing NFS daemons, consider adding another server to your NFS setup. The maximum recommended number of NFS daemons is 24 on a large server. If you increase the number of NFS server daemons, confirm your choice by giving this command:

    # /usr/etc/nfsstat -s
    Server NFS V3:
    calls        badcalls
    2284031      0
    null        getattr      setattr     lookup      access      readlink
    0  0%       550622 24%   8701  0%    625503 27%  512426 22%  68368  2%
    read        write        create      mkdir       symlink      mknod
    385682 16%  2965  0%     126  0%     3  0%       138  0%      0  0%
    remove      rmdir        rename      link        readdir      readdir+
    327  0%     40  0%       55  0%      1  0%       76  0%       21574  0%
    fsstat      fsinfo       pathconf    commit
    83056 3%    24033  1%    16  0%      319  0%

If the output shows many null receives, you should consider lowering the number of NFS server daemons. There is no exact formula for choosing the number of NFS daemons, but here are several rules of thumb you can consider:

- One `nfsd` for each CPU plus one to three `nfsd` `daemons` as a general resource.

- One `nfsd` for each disk controller plus one to three `nfsd` daemons as a general resource (a logical volume counts as one controller, no matter how many real controllers it is spread over).

- One `nfsd` for each CPU, one `nfsd` for each controller, and one to three `nfsd` daemons as a general resource.

## Temporary NFS Mounting

In cases where an NFS client requires directories not listed in its `/etc/fstab` file, you can use manual mounting to temporarily make the NFS resource available. With temporary mounting, you need to supply all the necessary information to the `mount` program through the command line. As with any mount, a temporarily mounted directory requires that a mount point be created before mounting can occur.

For example, to mount`/usr/demos` from the server redwood to a local mount point`/n/demos` with read-only, hard, interrupt, and background options, as superuser, enter these commands:

    mkdir -p /n/demos
    mount –o ro,bg redwood:/usr/demos /n/demos

A temporarily mounted directory remains in effect until the system is rebooted or until the superuser manually unmounts it. Use this method for one-time mounts.

## Modifying the Automatic Mounter Maps

You can modify the automatic mounter maps at any time. AutoFS accepts map modifications at any time, without having to restart the daemon. Simply make the change and run the command `/usr/etc/autofs -v`. This command reconciles any differences between`/etc/mtab` and the current map information.

With `automount`, some of your modifications take effect the next time the automatic mounter accesses the map, and others take effect when the system is rebooted. Whether or not booting is required depends on the type of map you modify and the kind of modification you introduce.

Rebooting is generally the most effective way to restart `automount`. You can also kill and restart the automatic mounter using `automount` at the command line. Use this method sparingly, however. (See the `automount``(1M)` .)

### Modifying the Master Map

`automount` consults the master map only at startup time. A modification to the master map (`/etc/auto.master``)` takes effect only after the system has been rebooted or `automount` is restarted (see “Modifying Direct Maps”). With AutofS, the change takes effect after the `autofs` command is run.

### Modifying Indirect Maps

You can modify, delete, or add to indirect maps (the files listed in `/etc/auto.master` or `/etc/auto_master`) at any time. Any change takes effect the next time the map is used, which is the next time a mount is requested.

### Modifying Direct Maps

Each entry in a direct map is an `automount` or `autofs` mount point, and the daemon mounts itself at these mount points at startup, and with AutoFS, when `autofs` is run. With `autofs`, the changes are noted immediately, since it stays in sync with `/etc/mtab`.

With `automount`, adding or deleting an entry in a direct map takes effect only after you have gracefully killed and restarted the `automountd` daemon or rebooted. However, except for the name of the mount point, you can modify direct map entries while `automount` is running. The modifications take effect when the entry is next mounted, because `automount` consults the direct maps whenever a mount must be done.

For instance, with `automount`, suppose you modify the file `/etc/auto.indirect` so that the directory `/usr/src` is mounted from a different server. The new entry takes effect immediately (if `/usr/src` is not mounted at this time) when you try to access it. If it is mounted now, you can wait until automatic unmounting takes place to access it. If this is not satisfactory, unmount the directory with the `umount` command, notify `automount` with the command `/etc/killall -HUP automount` that the mount table has changed, and then access the directory. The mounting should be done from the new server. However, if you want to delete the entry, you must gracefully kill and restart the `automount` daemon. The `automount` process must be killed with the SIGTERM signal:

    /etc/killall -TERM automount

You can then manually restart `automount` or reboot the system.

| Note: If gracefully killing and manually restarting `automount` does not work, rebooting the system should always work.

## Mount Point Conflicts

You can cause a mount conflict by mounting one directory on top of another. For example, say you have a local partition mounted on `/home`, and you want `automount` to mount other home directories. If the `automount` maps specify `/home` as a mount point, `automount` hides the local home partition whenever it mounts.

The solution is to mount the server's `/home` partition somewhere else, such as `/export/home`, for example. You need an entry in `/etc/fstab` like this:

    /net/home    /export/home    xfs rw,raw=/dev/rhome 0 0

This example assumes that the master file contains a line similar to this:

    /home        /etc/auto.home

It also assumes an entry in `/etc/auto.home` like this:

    terra        terra:/export/home

where `terra` is the name of the system.

## Modifying CacheFS File System Parameters

| Note: Before changing parameters for a cache, you must unmount all file systems in the cache directory by using the `umount` command.

The following command changes the value of one or more parameters:

    cfsadmin -u –o parameter_list cache_directory

| Note: You can only increase the size of a cache, either by number of blocks or number of inodes. If you want to make a cache smaller, you must remove it and re-create it with new values.

The following commands unmount `/local/cache3` and change the `threshfiles` parameter to 65%:

    # umount /local/cache3
    # cfsadmin -u -o threshfiles=65 /local/cache3

### Displaying Information About Cached File Systems

The following command returns information about all file systems cached under the specified cache directory.

    cfsadmin -l cache_directory

| Note: The block size reported by `cfsadmin` is in 8 KB blocks.

The following command shows information about the cache directory named `/usr/cache/nabokov`:

    # cfsadmin -l /usr/cache/nabokov

      cfsadmin: list cache FS information
         Version        2   4  50
       maxblocks     90% (1745743 blocks)
        hiblocks     85% (1648757 blocks)
       lowblocks     75% (1454786 blocks)
       maxfiles      90% (188570 files)
        hifiles      85% (178094 files)
       lowfiles      75% (157142 files)
      neteng:_old-root-6.2_usr_local_lib:_usr_local_lib
      neteng:_usr_annex:_usr_annex
      bitbucket:_b_jmy:_usr_people_jmy_work
      neteng:_old-root-6.2_usr_local_bin:_usr_local_bin

This example shows multiple mount points for a single cache: `neteng` and `bitbucket`.

## Deleting a CacheFS File System

The following command deletes a file system in a cache:

    cfsadmin –d cache_id cache_directory

| Note: Before deleting a cached file system, you must unmount all the cached files systems for that cache directory.

The cache ID is part of the information returned by `cfsadmin –l`.

The following commands unmount a cached file system and delete it from the cache`:`

    # umount /usr/work
    # cfsadmin -d _dev_dsk_c0t1d0s7 /local/cache1

You can delete all file systems in a particular cache by using `all` as an argument to the `–d` option. The following command deletes all file systems cached under `/local/cache1`:

    # cfsadmin -d all /local/cache1

The `all` argument to `–d` also deletes the specified cache directory.

Prev | Table of Contents | Next
Chapter 4. Setting Up and Testing ONC3/NFS |  | Chapter 6. Troubleshooting ONC3/NFS