Chapter 4. Setting Up and Testing ONC3/NFS
Prev |  | Next

## Chapter 4. Setting Up and Testing ONC3/NFS

This chapter explains how to set up ONC3/NFS services and verify that they work. It provides procedures for enabling exporting on NFS servers, for setting up mounting and automatic mounting on NFS clients, and for setting up the network lock manager. It also explains how to create a CacheFS file system. Before you begin these procedures, you should be thoroughly familiar with the information provided in Chapter 2, “Planning ONC3/NFS Service.”

This chapter contains these sections:

- “Setting Up the NFS Server”

- “Setting Up an NFS Client”

- “Setting Up the Automatic Mounters”

- “Setting Up the Lock Manager”

- “Setting Up the CacheFS File System”

- “Mounting a Cached File System”

| Note: To do the procedures in this chapter, you should have already installed ONC3/NFS software on the server and client systems that will participate in the ONC3/NFS services. The ONC3/NFS Release Notes explain where to find instructions for installing ONC3/NFS software.

## Setting Up the NFS Server

Setting up an NFS server requires verifying that the required software is running on the server, editing the server's `/etc/exports` file, adding the file systems to be exported, exporting the file systems, and verifying that they have been exported. The instructions below explain the setup procedure. They assume that NFS software is already installed on the server. Do this procedure as the superuser on the server.

1. Check the NFS configuration flag on the server.

   When the `/etc/init.d/network` script executes at system startup, it starts NFS running if the `chkconfig` flag nfs is `on`. To verify that nfs is `on`, type the `chkconfig` command and check its output, for example:

       # /etc/chkconfig
               Flag                 State
               ====                 =====
               ...
               nfs                  on
               ...

   This example shows that the `nfs` flag is set to `on`.

2. If your output shows that `nfs` is `off`, type this command and reboot your system:

       /etc/chkconfig nfs on

3. Verify that NFS daemons are running.

   Four nfsd and four biod daemons should be running (the default number specified in `/etc/config/nfsd.options` and `/etc/config/biod.options`). Verify that the appropriate NFS daemons are running using the `ps` command, shown below. The output of your entries looks similar to the output in these examples:

       ps -ef | grep nfsd
       root   102       1  0  Jan 30 ?     0:00 /usr/etc/nfsd 4
       root   104     102  0  Jan 30 ?     0:00 /usr/etc/nfsd 4
       root   105     102  0  Jan 30 ?     0:00 /usr/etc/nfsd 4
       root   106     102  0  Jan 30 ?     0:00 /usr/etc/nfsd 4
       root  2289    2287  0 14:04:50 ttyq4 0:00 grep nfsd
       ps -ef | grep biod
       root   107       1  0  Jan 30 ?     0:00 /usr/etc/biod 4
       root   108       1  0  Jan 30 ?     0:00 /usr/etc/biod 4
       root   109       1  0  Jan 30 ?     0:00 /usr/etc/biod 4
       root   110       1  0  Jan 30 ?     0:00 /usr/etc/biod 4
       root  2291    2287  4 14:04:58 ttyq4 0:00 grep biod

   If no NFS daemons appear in your output, they were not included in the IRIX kernel during NFS installation. To check the kernel, type this command:

       strings /unix | grep nfs

   If there is no output, rebuild the kernel with this command, then reboot the system:

       /etc/autoconfig -f

4. Verify that mount daemons are registered with the portmapper.

   Mount daemons must be registered with the server's portmapper so the portmapper can provide port numbers to incoming NFS requests. Verify that the mount daemons are registered with the portmapper by typing this command:

       /usr/etc/rpcinfo –p | grep mountd

   After your entry, you should see output similar to this:

       100005  1   tcp  1230  mountd
       100005  1   udp  1097  mountd
       391004  1   tcp  1231  sgi_mountd
       391004  1   udp  1098  sgi_mountd

   The sgi_mountd in this example is an enhanced mount daemon that reports on SGI-specific export options.

5. Edit the `/etc/exports` file.

   Edit the `/etc/exports` file to include the file systems you want to export and their export options (`/etc/exports` and export options are explained in “/etc/exports and Other Export Files” in Chapter 2). This example shows one possible entry for the `/etc/exports` file:

       /usr/demos -ro,access=client1:client2:client3

   In this example, the file system `/usr/demos` are exported with read-only access to three clients: client1, client2, and client3. Domain information can be included in the client names, for example client1.eng.sgi.com.

6. Run the `exportfs` command.

   Once the `/etc/exports` file is complete, you must run the `exportfs` command to make the file systems accessible to clients. You should run `exportfs` anytime you change the `/etc/exports` file. Type this command:

       /usr/etc/exportfs -av

   In this example, the `–a` option exports all file systems listed in the `/etc/exports` file, and the`–v` option causes `exportfs` to report its progress. Error messages reported by `exportfs` usually indicate a problem with the `/etc/exports` file.

7. Use `exportfs` to verify your exports.

   Type the `exportfs` command with no parameters to display a list of the exported file system(s) and their export options, as shown in this example:

       /usr/etc/exportfs
       /usr/demos -ro,access=client1:client2:client3

   In this example, `/usr/demos` is accessible as a read-only file system to systems client1, client2, and client3. This matches what is listed in the `/etc/exports` file for this server (see instruction 5 of this procedure). If you see a mismatch between the `/etc/exports` file and the output of the `exportfs` command, check the `/etc/exports` file for syntax errors.

The NFS software for this server is now running and its resources are available for mounting by clients. Repeat these instructions to set up additional NFS servers.

## Setting Up an NFS Client

Setting up an NFS client for conventional mounting requires verifying that NFS software is running on the client, editing the `/etc/fstab` file, adding the names of directories to be mounted, and mounting the directories in `/etc/fstab` by giving the `mount` command or by rebooting your system. These directories remain mounted until you explicitly unmount them.

| Note: For instructions on mounting directories not listed in `/etc/fstab`, see “Temporary NFS Mounting” in Chapter 5.

The procedure below explains how to set up NFS software on a client and mount its NFS resources using the `mount` command. You must do this procedure as the superuser.

1. Use `chkconfig` to check the client's NFS configuration flag.

   To verify that `nfs` is `on`, give the `chkconfig` command and check its output (see “Setting Up the NFS Server” in this chapter for details on `chkconfig`).

2. If your output shows that `nfs` is `off`, type this command and reboot your system:

       /etc/chkconfig nfs on

3. Verify that NFS daemons are running.

   Four nfsd and four biod daemons should be running (the default number specified in `/etc/config/nfsd.options` and `/etc/config/biod.options`). Verify that the appropriate NFS daemons are running using the `ps` command, shown below. The output of your entries looks similar to the output in these examples:

       ps -ef | grep nfsd
       root   102      1  0  Jan 30 ?      0:00 /usr/etc/nfsd 4
       root   104    102  0  Jan 30 ?      0:00 /usr/etc/nfsd 4
       root   105    102  0  Jan 30 ?      0:00 /usr/etc/nfsd 4
       root   106    102  0  Jan 30 ?      0:00 /usr/etc/nfsd 4
       root  2289   2287  0 14:04:50 ttyq4 0:00 grep nfsd
       ps -ef | grep biod
       root   107      1  0  Jan 30 ?      0:00 /usr/etc/biod 4
       root   108      1  0  Jan 30 ?      0:00 /usr/etc/biod 4
       root   109      1  0  Jan 30 ?      0:00 /usr/etc/biod 4
       root   110      1  0  Jan 30 ?      0:00 /usr/etc/biod 4
       root  2291   2287  4 14:04:58 ttyq4 0:00 grep biod

   If no NFS daemons appear in your output, they were not included in the IRIX kernel during NFS installation. To check the kernel, type this command:

       strings /unix | grep nfs

   If there is no output, rebuild the kernel with this command, then reboot the system:

       /etc/autoconfig -f

4. Edit the `/etc/fstab` file.

   Add an entry to the `/etc/fstab` file for each NFS directory you want mounted when the client is booted. The example below illustrates an `/etc/fstab` with an NFS entry to mount `/usr/demos` from the server redwood at mount point `/n/demos`:

       /dev/root          /         efs rw,raw=/dev/rroot 0 0
       /dev/usr           /usr      efs rw,raw=/dev/rusr 0 0
       redwood:/usr/demos /n/demos   nfs ro,bg 0 0

   | Note: The background (`bg`) option in this example allows the client to proceed with the boot sequence without waiting for the mount to complete. If the `bg` option is not used, the client hangs if the server is unavailable.

5. Create the mount points for each NFS directory.

   After you edit the `/etc/fstab` file, create a directory to serve as the mount point for each NFS entry in `/etc/fstab` file. If you specified an existing directory as a mount point for any of your `/etc/fstab` entries, remember that the contents of the directory are inaccessible while the NFS mount is in effect.

   For example, to create the mount point `/n/demos` for mounting the directory `/usr/demos` from server redwood, give this command:

       mkdir -p /n/demos

6. Mount each NFS resource.

   You can use the `mount` command in several ways to mount the entries in this client's `/etc/fstab`. See the `mount`(1M) reference page for a description of the options. The examples below show two methods: mounting each entry individually and mounting all fstab entries that specify a particular server. The first example is:

       mount /n/demos

   In this example, only the mount point is specified. All other information needed to perform the mount, the server name redwood and its resource `/usr/demos`, is provided by the `/etc/fstab` file.

   The second example is:

       mount -h redwood

   In this example, all NFS entries in`/etc/fstab` that specify server redwood are mounted.

   | Note: If you reboot the client instead of using the `mount` command, all NFS entries in `/etc/fstab` are mounted.

The NFS software for this client is now ready to support user requests for NFS directories. Repeat these instructions to set up additional NFS clients.

## Setting Up the Automatic Mounters

Since the automatic mounters run only on NFS clients, all setup for the automatic mounters is done on the client system. This section provides two procedures for setting up the automatic mounters: one for setting up a default `automount` or `autofs` environment and one for setting up a more complex environment.

### Setting Up a Default Automatic Mounter Environment

If you set up a default automatic mounter environment on a client, at system startup`automount (`or `autofs)` reads the`/etc/config/automount.options` file (or `/etc/config/autofs.options` file) for mount information. By default, the options file contains an entry for a special map called `–hosts`. The `–hosts` map tells the automatic mounter to read the hosts database (`/etc/hosts`, NIS and/or DNS (BIND); see the `resolver`(4) reference page) and use the server specified if the hosts database has a valid entry for that server. When using the `–hosts` map, when a client accesses a server, the automatic mounter gets the exports list from the server and mounts all directories exported by that server. `automount` uses `/tmp_mnt/hosts` as the mount point, and `autofs` uses `/hosts`.

A sample`–hosts` entry in `/etc/config/automount.options` is:

    -v    /hosts    -hosts    -nosuid,nodev

Use this procedure to set up the default automatic mounter environment on an NFS client. You must do this procedure as the superuser.

1. Verify that NFS flags are on.

   By default, the `nfs` and `autofs` flags are set to `on`. To verify that they are on, give the `chkconfig` command and check its output (see instruction 1 of “Setting Up an NFS Client” in this chapter for sample `chkconfig` output). If either flag is set to `off`, or you wish to use `automount`, use one of these sets of commands to reset it, then reboot:

       /etc/chkconfig nfs on
       /etc/chkconfig automount on
       or
       /etc/chkconfig nfs on
       /etc/chkconfig autofs on

2. Verify that the default configuration is working:

       cd /hosts/servername

   In place of servername, substitute the hostname of any system whose name can be resolved by the hostname resolution method you are using (see the `resolver`(4) reference page). If the system specified is running NFS and has file systems that can be accessed by this client, `automount` mounts all available file systems to `/tmp_mnt/hosts/`servername (`autofs` uses `/hosts/`servername). If the system is not running NFS or has nothing exported that you have access to, you get an error message when you try to access its file systems.

3. Verify that directories have been mounted, for example:

       mount
       servername:/ on /tmp_mnt/hosts/servername type nfs (rw,dev=c0005)(for automount)
       or
       servername:/ on /hosts/servername type nfs (rw,dev=c0005)(for autofs)

   The automatic mounter has serviced this request. It dynamically mounted `/hosts/`servername using the default automatic mounter environment.

### Setting Up a Custom Automatic Mounter Environment

A customized automatic mounter environment allows you to select the NFS directories that are dynamically mounted on a particular client, and allows you to customize the options in effect for particular mounts. You must complete four general steps to set up a customized automount environment:

1. Creating the maps.

2. Starting the automatic mounter program.

3. Verifying the automatic mounter process.

4. Testing the automatic mounter`.`

#### Step 1: Creating the Maps

A customized automatic mounter environment contains a master map and any combination of direct and indirect maps. Although a master map is required, the automatic mounter does not require both direct and indirect maps. You can use either direct or indirect maps exclusively. AutoFS comes with a default `/etc/auto_master` file that can be modified.

Instructions for creating each type of map are given below. Notice from these instructions that a crosshatch (`#`) at the beginning of a line indicates a comment line in all types of maps. Include comment lines in your maps to illustrate map formats until you become familiar with each map type.

1. Create or modify the master map on the client.

   The master map points the automatic mounter to other files that have more detailed information needed to complete NFS mounts. To create the master map, become superuser and create a file called `/etc/auto.master` (for `automount`) with any text editor. With AutoFS, modify the default `/etc/auto_master` file.

   Specify the mount point, map name, and any options that apply to the direct and indirect maps in your entries, for example:

       #Mount Point   Map Name            Map Options
       /food/dinner   /etc/auto.food      -ro
       /-             /etc/auto.exercise  -ro,soft
       /hosts         -hosts              -nosuid,nodev

2. Create the indirect map.

   Create your indirect map and insert the entries it needs. This example is the indirect map `/etc/auto.food`, listed in `/etc/auto.master` (or /etc/auto_master) in instruction 1:

       #Directory    Options      Location
       ravioli                    venice:/food/pasta
       crepe         -rw          paris:/food/desserts
       chowmein                   hongkong:/food/noodles

3. Create the direct map.

   Create your direct map and insert the entries it needs. This example is the direct map `/etc/auto.exercise`, listed in `/etc/auto.master` (or /etc/auto_master) in instruction 1:

       #Directory        Options   Location
       /leisure/swim               spitz:/sports/water/swim
       /leisure/tennis             becker:/sports/racquet/tennis
       /leisure/golf               palmer:/sports/golf

#### Step 2: Starting the Automatic Mounter Program

You can set up the software on a client so that the automatic mounter starts when the client is booted, and you can also start the automatic mounter from the command line. The procedures in this section explain how to set up the automatic mounter to start during the boot sequence.

If the automatic mounter is configured on at system startup, the `/etc/init.d/network` script reads the contents of the `/etc/config/automount.options` file (or `/etc/config/autofs.options` and /etc/ auto_master files for `autofs`) to determine how to start the automatic mounter program, what to mount, and how to mount it. Depending on the site configuration specified in the options file, the automatic mounter either finds all necessary information in the options file, or it is directed to local or NIS maps (or both) for additional mounting information.

If you plan to use NIS database maps other than the `–``hosts` built-in map, you need to create the NIS maps. See the NIS Administration Guide for information on building custom NIS maps.Follow this procedure to set the automatic mounter to start automatically at system startup:

1. Configure the automatic mounter on with the `chkconfig` command (if needed):

       /etc/chkconfig automount on
       or
       /etc/chkconfig autofs on

2. Modify the `/etc/config/automount.options` file (or `/etc/auto_master` file).

   Using any standard editor, modify `/etc/config/automount.options` (or `/etc/auto_master`) file to reflect the automatic mounter site environment. (See `automount`(1M) or `autofs`(1M) for details on the options file). Based on the previous examples, the `/etc/config/automount.options` file contains this entry:

       -v -m -f /etc/auto.master

   The `/etc/config/autofs.options` file contains this entry:

       -v

   The `–v` option directs error messages to the screen during startup and into the `/var/adm/SYSLOG` file once the automatic mounter is up and running. The `–m` option tells `automount` not to check the NIS database for a master map. Use this option to isolate map problems to the local system by inhibiting `automount` from reading the NIS database maps, if any exist. The`–f` option tells `automount` that the argument that follows it is the full pathname of the master file.

   | Note: In general, it is recommended that you start the automatic mounter with the verbose option (`–v`), since this option provides messages that can help with problem solving.

3. Reboot the system.

#### Step 3: Verifying the Automatic Mounter Process

Verify that the automatic mounter process is functioning by performing the following two steps.

1. Validate that the automatic mounter daemon is running with the ps command:

       ps -ef | grep automount
       or
       ps -ef | grep autofs

   You should see output similar to this for `automount`:

       root 455 1  0   Jan 30 ? 0:02 automount -v -m -f /etc/auto.master
       root   4675  4673  0 12:45:05 ttyq5    0:00 grep automount

   You should see output similar to this for `autofs`:

       root 555 1  0   Jan 30 ? 0:02 autofs -v - /etc/auto_master
       root   4775  4773  0 12:45:05 ttyq5    0:00 grep autofs

2. Check the `/etc/mtab` entries.

   When the automatic mounter program starts, it creates entries in the client's `/etc/mtab` for each of the automatic mounter's mount points. Entries in `/etc/mtab` include the process number and port number assigned to the automatic mounter, the mount point for each direct map entry, and each indirect map. The `/etc/mtab` entries also include the map name, map type (direct or indirect), and any mount options.

   Look at the `/etc/mtab` file. A typical `/etc/mtab` table with `automount` running looks similar to this example (wrapped lines end with the \ character):

       /dev/root / efs rw,raw=/dev/rroot 0 0
       /dev/usr /usr efs rw,raw=/dev/rusr 0 0
       /debug /debug dbg rw 0 0
       /dev/diskless /diskless efs rw,raw=/dev/rdiskless 0 0
       /dev/d /d efs rw,raw=/dev/rd 0 0
       flight:(pid12155) /src/sgi ignore \
           ro,port=885,map=/etc/auto.source,direct 0 0
       flight:(pid12155) /pam/framedocs/nfs ignore \
           ro,port=885,map=/etc/auto.source,direct 0 0
       flight:(pid12155) /hosts ignore ro,port=885,\
           map=-hosts,indirect,dev=1203 0 0

   A typical `/etc/mtab` table with `autofs` running looks similar to this example:

       -hosts on /hosts type autofs (ignore,indirect,nosuid,dev=1000010)
       -hosts on /hosts2 type autofs \           (ignore,indirect,nosuid,vers=2,dev=100002)
       -hosts on /hosts3 type autofs \ (ignore,indirect,fstype=cachefs,backfstype=nfs,dev=100003)
       /etc/auto_test on /text type autofs\
       (ignore,indirect,ro,nointr,dev=100004)
       neteng:/ on /hosts2/neteng type nfs \
       (nosuid,vers=2,dev=180004)

   The entries corresponding to`automount` mount points have the file system type `ignore` to direct programs to ignore this `/etc/mtab` entry. For instance, `df` and `mount` do not report on file systems with the type `ignore`. When a directory is NFS mounted by the `automount` program, the `/etc/mtab` entry for the directory has `nfs` as the file system type. `df` and `mount` report on file systems with the type `nfs`.

#### Step 4: Testing the Automatic Mounter

When the automatic mounter program is set up and running on a client, any regular account can use it to mount remote directories transparently. You can test your automatic mounter setup by changing to a directory specified in your map configuration.

The instructions below explain how to verify that the automatic mounter is working.

1. As a regular user, `cd` to an automounted directory.

   For example, test whether the automatic mounter mounts `/food/pasta`:

       cd /food/dinner/ravioli

   This command causes the automatic mounter to look in the indirect map /etc/auto.food to execute a mount request to server venice and apply any specified options to the mount. `automount` then mounts the directory `/food/pasta` to the default mount point `/tmp_mnt/food/dinner/ravioli`. The directory `/food/dinner/ravioli` is a symbolic link to `/tmp_mnt/food/dinner/ravioli`. `autofs` mounts the directory `/food/pasta` to the default mount point `/food/dinner/ravioli`.

   | Note: The `/food/dinner` directory appears empty unless one of its subdirectories has been accessed (and therefore mounted).

2. Verify that the individual mount has taken place.

   Use the `pwd` command to verify that the mount has taken place, as shown in this example:

       % pwd
       /food/pasta

3. Verify that both directories have been mounted with the automounter.

   You can also verify automounted directories by checking the output of a `mount` command:

       % mount

   `mount` reads the current contents of the `/etc/mtab` file and includes conventional and automount mounted directories in its output.

The custom configuration of automount is set up and ready to work for users on this client.

## Setting Up the Lock Manager

The NFS lock manager provides file and record locking between a client and server for NFS-mounted directories. As an NFS utility, the lock manager is in effect when NFS software is installed and operating properly on both the server and client systems. It is implemented by two daemons, lockd and statd (see `lockd`(1M) and `statd`(1M)). These daemons must be running on an NFS server and its clients for the lock manager to function.

The NFS lock manager program must be running on both the NFS client and the NFS server to function properly. Use this procedure to check the lock manager setup:

1. Use `chkconfig` on the client to check the lock manager flag.

   To verify that the `lockd` flag is `on`, give the `chkconfig` command and check its output (see instruction 1 of “Setting Up an NFS Client” in this chapter for sample `chkconfig` output). If your output shows that `lockd` is `off`, give this command and reboot your system:

       /etc/chkconfig lockd on

2. Verify that `rpc.statd` and either `rpc.lockd` or `nfsd` are running.

   Give these `ps` commands and check their output to verify that the lock manager daemons, `rpc.statd` and either `rpc.lockd` or `nfsd` are running:

       ps -ef | grep statd
       root   131     1  0   Aug  6 ?        0:51 /usr/etc/rpc.statd
       root  2044   427  2 16:13:24 ttyq1    0:00 grep statd
       # ps -ef | grep lockd
       root   129     1  0   Aug  6 ?        0:51 /usr/etc/rpc.lockd
       root  2045   427  2 16:13:24 ttyq1    0:00 grep lockd
       # ps -ef | grep nfsd
       root   102      1  0  Jan 30 ?        0:00 /usr/etc/nfsd 4
       root   104    102  0  Jan 30 ?        0:00 /usr/etc/nfsd 4

   If `rpc.statd` is not running, start it manually by giving the following command:

       /usr/etc/rpc.statd

   If neither `rpc.lockd` or `nfsd` is running, start `rpc.lockd` manually by giving the following command:

       /usr/etc/rpc.lockd

3. Repeat instructions 1 and 2, above, on the NFS server, using `rpc.lockd` instead of `nfsd`.

## Setting Up the CacheFS File System

When you set up a cache, you can use all or part of an existing file system. You can also set up a new slice to be used by CacheFS. In addition, when you create a cache, you can specify the percentage of resources, such as number of files or blocks, that CacheFS can use in the front file system. The configurable cache parameters are discussed in the section “Cache Resource Parameters”.

Before starting to set up CacheFS, check that it is configured to start on the client.

1. Check the CacheFS configuration flag.

   When the `/etc/init.d/network` script executes at system startup, it starts CacheFS running if the `chkconfig` flag `cachefs` is `on`.

   To verify that `cachefs` is `on`, type the `chkconfig` command and check its output, for example:

       /etc/chkconfig
       Flag                 State
       ====                 =====
       ...
       cachefs              on
       ...

   This example shows that the `cachefs` flag is set to `on`.

2. If your output shows that `cachefs` is `off`, type this command and reboot your system:

       /etc/chkconfig cachefs on

### Front File System Requirements

CacheFS uses a local EFS or XFS file system for the front file system.You can use an existing EFS or XFS file system for the front file system or you can create a new one. Using an existing file system is the quickest way to set up a cache. Dedicating a file system exclusively to CacheFS gives you the greatest control over the file system space available for caching.

| Caution: Do not make the front file system read-only and do not set quotas on it. A read-only front file system prevents caching, and file system quotas interfere with control mechanisms built into CacheFS.

### Setting Up a Cached File System

There are two steps to setting up a cached file system:

1. You can create the cache with the `cfsadmin` command. See “Creating a Cache”. This procedure should be used when you do not want the default parameters that are used when the cache directory is created with the `mount` command.

2. You must mount the file system you want cached using the `-t cachefs` option to the `mount` command. See “Mounting a Cached File System”.

### Creating a Cache

The following example is the command to create a cache using the `cfsadmin` command:

    cfsadmin –c directory_name

The following example creates a cache and creates the cache directory `/local/mycache`. Make sure the cache directory does not already exist.

    cfsadmin -c /local/mycache

This example uses the default cache parameter values. The CacheFS parameters are described in the section “Cache Resource Parameters”. See the `cfsadmin`(1M) reference page and “cfsadmin Command” for more information on `cfsadmin` options.

### Setting Cache Parameters

The following example shows how to set parameters for a cache.

    cfsadmin -c -o parameter_list cache_directory

The parameter_list has the following form:

    parameter_name1=value,parameter_name2=value,...

The parameter names are listed in Table 2-2. You must separate multiple arguments to the `–o` option with commas.

| Note: The maximum size of the cache is by default 90% of the front file system resources. Performance deteriorates significantly if an EFS file system exceeds 90% capacity.

The following example creates a cache named `/local/cache1` that can use up to 80% of the disk blocks in the front file system and can grow to use the front file system blocks without restriction unless 60% (or more) of the front file system blocks are already in use.

    cfsadmin -c -o maxblocks=80,threshblocks=60 /local/cache1

The following example creates a cache named `/local/cache2` that can use up to 75% of the files available in the front file system.

    cfsadmin -c -o maxfiles=75 /local/cache2

The following example creates a cache named `/local/cache3` that can use 75% of the blocks in the front file system, that can use the files in the front file system without restriction unless total file usage already exceeds 60%, and that has 70% of the files in the front file system as an absolute limit.

    cfsadmin -c -o \ maxblocks=75,threshfiles=60,maxfiles=70 /local/cache3

## Mounting a Cached File System

There are two ways to mount a file system in a cache:

- Using the `mount` command

- Creating an entry for the file system in the`/etc/fstab` file

### Using mount to Mount a Cached File System

The following command mounts a file system in a cache.

    mount -t cachefs back_file_system mount_point

The cache directory is automatically created when mounting a cached file system.

For example, the following command makes the file system`merlin:/docs` available as a cached file system named`/docs`:

    mount -t cachefs -merlin:/docs /docs

#### Mounting a Cached File System That Is Already Mounted

Use the `backpath` argument when the file system you want to cache has already been mounted. `Backpath` specifies the mount point of the mounted file system. When the `backpath` argument is used, the back file system must be already mounted as read-only. If you want to write to the back file system, you must unmount it before mounting it as a cached file system.

For example, if the file system `merlin:/doc` is already NFS-mounted on `/nfsdocs,` you can cache that file system by giving that pathname as the argument to `backpath`, as shown in the following example:

    mount -t cachefs -o \ backfstype=nfs,cachedir=/local/cache1,backpath=/nfsdocs \ merlin:/doc /doc

| Note: There is no performance gain in caching a local EFS disk file system.

#### Mounting a CD-ROM as a Cached File System

So far, examples have illustrated back file systems that are NFS-mounted, and the device argument to the `mount` command has taken the form server:file_system. If the back file system is an ISO9660 file system, the device argument is the CD-ROM device in the `/CDROM` directory. The file system type is `iso9660`.

The following example illustrates caching an ISO9660 back file system on the device `/CDROM` as `/doc` in the cache`/local/cache1`:

    mount -t cachefs -o backfstype=iso9660,cachedir=/local/cache1,\ ro,backpath=/CDROM /CDROM /doc

Because you cannot write to the CD-ROM, the `ro` argument is specified to make the cached file system read-only. The arguments to the`-o` option are explained in “/etc/fstab and Other Mount Files”.

You must specify the `backpath` argument because the CD-ROM is automatically mounted when it is inserted. The mount point is in the `/CDROM` directory and is determined by the name of the CD-ROM. The special device to mount is the same as the value for the `backpath` argument.

| Note: When a CD-ROM is changed, the CacheFS file system must be unmounted and remounted.

Prev | Table of Contents | Next
Chapter 3. Using Automatic Mounter Map Options |  | Chapter 5. Maintaining ONC3/NFS