C H A P T E R 5

Sun StorEdge QFS Shared File System

A Sun StorEdge QFS shared file system is a distributed file system that can be mounted on multiple Solaris operating system (OS) host systems. In a Sun StorEdge QFS shared file system environment, one Solaris OS host acts as the metadata server for the file system, and additional hosts can be configured as clients. You can configure more than one host as a potential metadata server, but only one host can be the metadata server at any one time. There is no limit to the number of Sun StorEdge QFS shared file system mount points.

The advantage of the Sun StorEdge QFS shared file system is that file data passes directly from the Fibre Channel disks to the hosts. Data travels via local path I/O (also known as direct access I/O). This is in contrast to the Network File System (NFS), which transfers data over the network.

This chapter describes how to configure and maintain the Sun StorEdge QFS shared file system. This chapter contains the following sections:

- Overview

- Configuring the Sun StorEdge QFS Shared File System

- Converting an Unshared File System to a Shared File System

- Converting a Shared File System to an Unshared File System

- Mounting and Unmounting Sun StorEdge QFS Shared File Systems

- Adding and Removing a Client Host

- Changing the Metadata Server in a Sun StorEdge QFS Environment

- Daemons

- Mount Options in a Sun StorEdge QFS Shared File System

- Mount Semantics in a Sun StorEdge QFS Shared File System

- File Locking in a Sun StorEdge QFS Shared File System

- Troubleshooting a Failed or Hung sammkfs(1M) or mount(1M) Command

##

Overview

In a Sun StorEdge QFS shared file system environment, no archiving or staging occurs, so no network connection to archive media is necessary. If you are operating a Sun StorEdge QFS shared file system environment, ignore the information about archive media in this chapter.

In a Sun SAM-QFS shared file system environment, each host that can become the metadata server needs to be connected to the same archive media repository, which can be one of the following:

- A library with removable media devices (tape or magneto-optical drives).

- Disk space in one or more file systems.

You must specify the archive media in the `mcf` file or in the `diskvols.conf` file on each host that can become a metadata server.

In a Sun SAM-QFS shared file system environment, the active metadata server is the only host upon which the staging (`sam-stagerd`) and archiving (`sam-archiverd`) daemons are active. The metadata server is designated as the server from which all file requests are staged.

You cannot configure a Sun SAM-QFS shared file system in a Sun Cluster environment.

This chapter describes how to maintain a Sun StorEdge QFS shared file system. It assumes that you have installed the Sun StorEdge QFS or Sun SAM-QFS software on the host systems according to the instructions in the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.

Note - The Sun StorEdge QFS shared file system cannot be configured in a Sun StorEdge SAM-FS (an `ms` file system) environment.

##

Configuring the Sun StorEdge QFS Shared File System

To perform initial installation and configuration for a Sun StorEdge QFS shared file system, follow the instructions in the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide. Many examples in this chapter use host names and configuration information that were introduced in that guide.

##

Converting an Unshared File System to a Shared File System

To convert an unshared Sun StorEdge QFS file system to a Sun StorEdge QFS shared file system, perform the following procedures in the order shown.

### To Convert an Unshared File System to Shared on the Server

1. As superuser, log in to the system to be used as the primary metadata server.

You must have `root` permission to complete the steps in this procedure.

2. Back up all site-customized system files and configuration files.

Depending on your software, these files can include `mcf`, `archiver.cmd`, `defaults.conf`, `samfs.cmd`,`inquiry.conf`, and so on. Back up these files for all file systems. Also make sure that you have backup copies of files in the `/etc/opt/SUNWsamfs` directory, files in the `/var/opt/SUNWsamfs` directory, library catalogs, the historian, and any parameter files for network-attached automated libraries.

In Sun SAM-QFS environments, if you do not know the names and locations of your catalog files, look for the automated libraries in the Additional Parameters field of the `mcf` file. If the Additional Parameters field is blank, however, the system uses the default path of `/var/opt/SUNWsamfs/catalog/`catalog_name. For more information about catalog file locations, see the `mcf`(4) man page.

3. Ensure that each file system to be modified is backed up. (Optional)

If you want to move files from an existing Sun StorEdge QFS or Sun SAM-QFS file system into a new Sun StorEdge QFS shared file system, make sure that your file systems are backed up. The file systems should be backed up regularly according to your site's policies. This is described as the last step in the installation procedure. If you are comfortable with the backup files that already exist for your file systems, there is no need to back them up again now.

4. Use the `umount`(1M) command to unmount the file system.

5. Use the `sammkfs`(1M) `-F -S` fsname`` command to convert the file system to a Sun StorEdge QFS shared file system`.`

For fsname, specify the Family Set Name of the file system that you are converting to a new Sun StorEdge QFS shared file system. For example:

    # sammkfs -S -F sharefs1

6. Edit the `/etc/opt/SUNWsamfs/mcf` file to add the `shared` keyword in the file system's Additional Parameters field.

For example:

CODE EXAMPLE 5-1 `mcf` File for Shared File System, `sharefs1`
    # Equipment                      Eq  Eq   Family   Dev   Add
    # Identifier                     Ord Type Set      State Params
    # ----------                     --- ---- ------   ----- ------
    sharefs1                         10  ma   sharefs1 on    shared
    /dev/dsk/c2t50020F23000065EEd0s6 11  mm   sharefs1 on
    /dev/dsk/c7t50020F2300005D22d0s6 12  mr   sharefs1 on
    /dev/dsk/c7t50020F2300006099d0s6 13  mr   sharefs1 on
    /dev/dsk/c7t50020F230000651Cd0s6 14  mr   sharefs1 on

7. Edit the `/etc/vfstab` file to add the `shared` keyword in the file system's Mount Parameters field.

For example:

CODE EXAMPLE 5-2 `/etc/vfstab` File Example
    # File /etc/vfstab
    # FS name   FS to fsck    Mnt pt    FS type   fsck pass   Mt@boot   Mt params
    sharefs1    -             /sharefs1 samfs     -            no         shared

8. Create the `/etc/opt/SUNWsamfs/hosts.`fsname hosts configuration file.

For example:

CODE EXAMPLE 5-3 Sun StorEdge QFS Shared File System Hosts File Example
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    host1     172.16.0.129,titan.xyzco.com      1        -    server
    host2     172.16.0.130,tethys.xyzco.com     2        -

9. Run the `samsharefs`(1M) `-u -R` fsname command to initialize the file system and the host configuration.

For example:

    # samsharefs -u -R sharefs1

10. Run the `samd`(1M) `config` command.

This informs the `sam-fsd` daemon of the configuration changes. For example:

    # samd config

11. Issue the `mount`(1M) command to mount the file system.

### To Convert an Unshared File System to Shared on Each Client

1. Use the `mkdir`(1) command to create the mount point for the file system.

For example:

    # mkdir /sharefs1

2. Create an `/etc/opt/SUNWsamfs/hosts.`fsname`.local` local hosts configuration file. (Optional)

CODE EXAMPLE 5-4 File `hosts.sharefs1.local`
    # This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local
    # Host Name    Host Interfaces
    # ---------    ---------------
    titan          172.16.0.129
    tethys         172.16.0.130

3. Ensure that each file system to be modified is backed up. (Optional)

If you want to move files from an existing Sun StorEdge QFS or Sun SAM-QFS file system into a new Sun StorEdge QFS shared file system, make sure that your file systems are backed up. The file systems should be backed up regularly according to your site's policies. This is described as the last step in the installation procedure. If you are comfortable with the backup files that already exist for your file systems, there is no need to back them up again now.

4. Use the `umount`(1M) command to unmount the file system.

5. Edit the `/etc/vfstab` file to add the `shared` keyword in the file system's Mount Parameters field.

For example:

CODE EXAMPLE 5-5 `/etc/vfstab` File Example
    # File /etc/vfstab
    # FS name   FS to fsck    Mnt pt    FS type   fsck pass   Mt@boot   Mt params
    sharefs1    -             /sharefs1 samfs     -            no         shared

6. Create the `/etc/opt/SUNWsamfs/hosts.`fsname hosts configuration file.

For example:

CODE EXAMPLE 5-6 Sun StorEdge QFS Shared File System Hosts File Example
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    host1     172.16.0.129,titan.xyzco.com      1        -    server
    host2     172.16.0.130,tethys.xyzco.com     2        -

##

Converting a Shared File System to an Unshared File System

To convert a Sun StorEdge QFS shared file system to an unshared Sun StorEdge QFS file system, perform the following procedures in the order shown.

### To Convert a Shared File System to Unshared on Each Client

1. Use the`umount`(1M) command to unmount the file system.

2. Delete the file system's entry from the `/etc/opt/SUNWsamfs/mcf` file.

3. Delete the file system's entry from the `/etc/vfstab` file.

4. Run the `samd`(1M) `config` command.

This informs the `sam-fsd` daemon of the configuration changes. For example:

    # samd config

5. Delete the mount point for the file system.

### To Convert a Shared File System to Unshared on the Server

1. As superuser, log in to the metadata server system.

You must have `root` permission to complete the steps in this procedure.

2. Back up all site-customized system files and configuration files.

Depending on your software, these files can include `mcf`, `archiver.cmd`, `defaults.conf`, `samfs.cmd`,`inquiry.conf`, and so on. Back up these files for all file systems. Also make sure that you have backup copies of files in the `/etc/opt/SUNWsamfs` directory, files in the `/var/opt/SUNWsamfs` directory, library catalogs, the historian, and any parameter files for network-attached automated libraries.

In Sun SAM-QFS environments, if you do not know the names and locations of your catalog files, examine the `mcf` file with `vi`(1) or another viewing command and find the entries for the automated libraries. The path to each library's catalog files is in the Additional Parameters field. If the Additional Parameters field is blank, however, the system uses the default path of `/var/opt/SUNWsamfs/catalog/`catalog_name. For more information about catalog file locations, see the `mcf`(4) man page.

3. Ensure that each file system to be modified is backed up. (Optional)

If you want to move files from an existing Sun StorEdge QFS shared or Sun SAM-QFS shared file system into a new Sun StorEdge QFS file system, make sure that your file systems are backed up. The file systems should be backed up regularly according to your site's policies. This is described as the last step in the installation procedure. If you are comfortable with the backup files that already exist for your file systems, there is no need to back them up again now.

4. Use the`umount`(1M) command to unmount the file system.

5. Run the `sammkfs`(1M)`-F -U` fsname to convert the Sun StorEdge QFS shared file system to an unshared file system.``

For fsname, specify the Family Set Name of the Sun StorEdge QFS shared file system that you are converting to a new unshared file system. For example:

    # sammkfs -F -U samfs1

6. Edit the `/etc/opt/SUNWsamfs/mcf` file to remove the `shared` keyword from the file system's Addtional Parameters field.

For example:

CODE EXAMPLE 5-7 `mcf` File for File System, `samfs1`
    # Equipment                      Eq  Eq   Family   Dev   Add
    # Identifier                     Ord Type Set      State Params
    # ----------                     --- ---- ------   ----- ------
    samfs1                           10  ma   samfs1   on
    /dev/dsk/c2t50020F23000065EEd0s6 11  mm   samfs1   on
    /dev/dsk/c7t50020F2300005D22d0s6 12  mr   samfs1   on
    /dev/dsk/c7t50020F2300006099d0s6 13  mr   samfs1   on
    /dev/dsk/c7t50020F230000651Cd0s6 14  mr   samfs1   on

7. Edit the `/etc/vfstab` file to remove the `shared` keyword from the file system's Mount Parameters field.

For example:

CODE EXAMPLE 5-8 `/etc/vfstab` File Example
    # File /etc/vfstab
    # FS name   FS to fsck    Mnt pt    FS type   fsck pass   Mt@boot   Mt params
    samfs1    -             /samfs1      samfs     -            no

8. Delete the `/etc/opt/SUNWsamfs/hosts.`fsname configuration file.

9. Run the `samd`(1M) `config` command.

This informs the `sam-fsd` daemon of the configuration changes. For example:

    # samd config

10. Use the `mount`(1M) command to mount the file system.

##

Mounting and Unmounting Sun StorEdge QFS Shared File Systems

When mounting or unmounting a Sun StorEdge QFS shared file system, the order in which the Solaris OS is mounted or unmounted is important.

For failover purposes, the mount options should be the same on the metadata server and all potential metadata servers. For example, you can create a `samfs.cmd`(4) file containing mount options and copy it to all the hosts.

For more information about mounting Sun StorEdge QFS shared file systems, see Mount Options in a Sun StorEdge QFS Shared File System or see the `mount_samfs`(1M) man page. For more information about mounting and unmounting file systems, see File System Operations.

### To Mount a Sun StorEdge QFS Shared File System

The `mount`(1M) command mounts a Sun StorEdge QFS shared file system in a Solaris OS. For more information about the `mount`(1M) command, see the `mount`(1M) man page.

1. Become superuser on the metadata server and on all the client hosts.

2. Use the `mount`(1M) command to mount the metadata server.

Mount the file system on the metadata server prior to mounting it on any client hosts.

3. Use the `mount`(1M) command to mount the client hosts.

You can mount the file system on the client hosts in any order.

### To Unmount a Sun StorEdge QFS Shared File System

Follow the instructions in To Unmount Sun StorEdge QFS and Sun SAM-QFS Shared File Systems.

##

Adding and Removing a Client Host

The following sections describe adding and removing client host systems:

- To Add a Client Host

- To Remove a Client Host

### To Add a Client Host

You can add a client host to a Sun StorEdge QFS shared file system after you have configured and mounted the file system on all participants. If you are adding a client host that is a node in a Sun Cluster environment, you must add the node to the cluster's existing resource group. For more information, see the Sun Cluster System Administration Guide for Solaris OS.

Follow these steps for each client host.

1. Become superuser on the metadata server.

2. Use the `samsharefs`(1M) command to retrieve the current Sun StorEdge QFS shared file system information and write it to an editable file.

- If the Sun StorEdge QFS shared file system is mounted, issue the `samsharefs`(1M) command on the current metadata server. For example:

    # samsharefs sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1

- If the Sun StorEdge QFS shared file system is unmounted, issue the `samsharefs`(1M) command with its `-R` option from the metadata server or from any of the potential metadata servers. For example:

    # samsharefs -R sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1

You can issue the `samsharefs`(1M) command only on the active metadata server or on client hosts configured as potential metadata servers. For more information, see the `samsharefs`(1M) man page.

Note - You can change the hosts information on any potential metadata server when the file system is unmounted. Sun Microsystems recommends that you always retrieve the hosts information to ensure that the hosts information is current.

3. Use `vi`(1) or another editor to open the Sun StorEdge QFS shared file system information file.

CODE EXAMPLE 5-9 shows this step.

CODE EXAMPLE 5-9 `hosts.sharefs1` Prior to Editing
    # vi /etc/opt/SUNWsamfs/hosts.sharefs1
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    titan    172.16.0.129,titan.xyzco.com      1        -    server
    tethys   172.16.0.130,tethys.xyzco.com     2        -
    mimas    mimas.xyzco.com                   -        -
    dione    dione.xyzco.com                   -        -

4. Use the editor to add a line for the new client host.

CODE EXAMPLE 5-10 shows the file after adding the line for `helene` as the last line.

CODE EXAMPLE 5-10 `hosts.sharefs1` After Editing
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    titan    172.16.0.129,titan.xyzco.com      1        -    server
    tethys   172.16.0.130,tethys.xyzco.com     2        -
    mimas    mimas.xyzco.com                   -        -
    dione    dione.xyzco.com                   -        -
    helene   helene.xyzco.com                  -        -

5. Use the `samsharefs`(1M) command to update the current information in the binary file.

The options to use on this command, and the system from which it is issued, differ depending on whether or not the Sun StorEdge QFS shared file system is mounted, as follows:

- If the Sun StorEdge QFS shared file system is mounted, issue the `samsharefs`(1M) `-u` command from the current metadata server. For example:

    # samsharefs -u sharefs1

- If the Sun StorEdge QFS shared file system is unmounted, issue the `samsharefs`(1M) `-R` `-u` command from the active metadata server or from any of the potential metadata servers. For example:

    # samsharefs -R -u sharefs1

The client host `helene` is now recognized.

6. As superuser, log in to one of the client hosts.

7. Use the `format`(1M) command to verify the presence of client host disks.

8. Update the `mcf` file on the client host.

Before a host system can access or mount a shared file system, it must have that file system defined in its `mcf` file.

Use `vi`(1) or another editor to edit the `mcf` file on one of the client host systems. The `mcf` file must be updated on all client hosts to be included in the Sun StorEdge QFS shared file system. The file system and disk declaration information must have the same data for the Family Set Name, Equipment Ordinal, and Equipment Type as the configuration on the metadata server. The `mcf` files on the client hosts must also include the shared keyword. The device names, however, can change as controller assignments can change from host to host.

The `samfsconfig`(1M) command generates configuration information that can help you to identify the devices included in the Sun StorEdge QFS shared file system. Enter a separate `samfsconfig`(1M) command on each client host. Note that the controller number might not be the same controller number as on the metadata server because the controller numbers are assigned by each client host.

Example 1. CODE EXAMPLE 5-11 shows how the `samfsconfig`(1M) command is used to retrieve device information for family set `sharefs1` on client `tethys`. Note that `tethys` is a potential metadata server, so it is connected to the same metadata disks as `titan`.

CODE EXAMPLE 5-11 `samfsconfig` (1M) Command Example on `tethys`
    tethys# samfsconfig /dev/dsk/*
    #
    # Family Set 'sharefs1' Created Wed Jun 27 19:33:50 2003
    #
    sharefs1                         10 ma sharefs1 on shared
    /dev/dsk/c2t50020F23000065EEd0s6 11 mm sharefs1 on
    /dev/dsk/c7t50020F2300005D22d0s6 12 mr sharefs1 on
    /dev/dsk/c7t50020F2300006099d0s6 13 mr sharefs1 on
    /dev/dsk/c7t50020F230000651Cd0s6 14 mr sharefs1 on

Edit the `mcf` file on client host `tethys` by copying the last five lines of output from the `samfsconfig`(1M) command into the `mcf` file on client host `tethys`. Verify the following:

- Each Device State field is set to `on`.

- The `shared` keyword appears in the Additional Parameters field for the file system name.

CODE EXAMPLE 5-12 shows the resulting `mcf` file.

CODE EXAMPLE 5-12 `mcf` File for `sharefs1` Client Host `tethys`
    # Equipment                      Eq  Eq   Family   Dev   Add
    # Identifier                     Ord Type Set      State Params
    # ----------                     --- ---- ------   ----- ------
    sharefs1                         10  ma   sharefs1 on    shared
    /dev/dsk/c2t50020F23000065EEd0s6 11  mm   sharefs1 on
    /dev/dsk/c7t50020F2300005D22d0s6 12  mr   sharefs1 on
    /dev/dsk/c7t50020F2300006099d0s6 13  mr   sharefs1 on
    /dev/dsk/c7t50020F230000651Cd0s6 14  mr   sharefs1 on

In CODE EXAMPLE 5-12, note that the Equipment Ordinal numbers match those of the example `mcf` file for metadata server `titan`. These Equipment Ordinal numbers must not already be in use on client host `tethys` or any other client host.

Example 2. CODE EXAMPLE 5-13 shows how the `samfsconfig`(1M) command is used to retrieve device information for family set `sharefs1` on client host `mimas`. Note that `mimas` can never become a metadata server, and it is not connected to the metadata disks.

CODE EXAMPLE 5-13 `samfsconfig` (1M) Command Example on `mimas`
    mimas# samfsconfig /dev/dsk/*
    #
    # Family Set 'sharefs1' Created Wed Jun 27 19:33:50 2001
    #
    # Missing slices
    # Ordinal 0
    # /dev/dsk/c1t50020F2300005D22d0s6   12    mr   sharefs1   on
    # /dev/dsk/c1t50020F2300006099d0s6   13    mr   sharefs1   on
    # /dev/dsk/c1t50020F230000651Cd0s6   14    mr   sharefs1   on

In the output from the `samfsconfig`(1M) command on `mimas`, note that `Ordinal` 0, which is the metadata disk, is not present. Because devices are missing, the `samfsconfig`(1M) command comments out the elements of the file system and omits the file system Family Set declaration line. Make the following types of edits to the `mcf` file:

- Create a file system Family Set declaration line, beginning with `sharefs1`, in the `mcf` file for client host `mimas`. Enter the `shared` keyword in the Additional Parameters field of the file system Family Set declaration line.

- Create one or more `nodev` lines for each missing Equipment Ordinal. For these lines, the keyword `nodev` must appear in the Equipment Identifier field for each inaccessible device. In this example, you create a device entry in the `mcf` file named `nodev` to represent the missing metadata disk.

- Ensure that each Device State field is set to `on`.

- Uncomment the device lines.

CODE EXAMPLE 5-14 shows the resulting `mcf` file for `mimas`.

CODE EXAMPLE 5-14 `mcf` File for Client Host `mimas`
    # The mcf File For mimas
    # Equipment                      Eq  Eq   Family   Device Addl
    # Identifier                     Ord Type Set      State  Params
    ------------                     --- ---- ---      -----  ------
    sharefs1                         10  ma   sharefs1 on     shared
    nodev                            11  mm   sharefs1 on
    /dev/dsk/c1t50020F2300005D22d0s6 12  mr   sharefs1 on
    /dev/dsk/c1t50020F2300006099d0s6 13  mr   sharefs1 on
    /dev/dsk/c1t50020F230000651Cd0s6 14  mr   sharefs1 on

Note - If you update a metadata server's `mcf` file after the Sun SAM-QFS shared file system is mounted, be sure to update the `mcf` files on all hosts that can access that shared file system.

9. Issue the `samd`(1M) `config` command on the metadata server host.

This informs the `sam-fsd` daemon of the configuration changes. For example:

    # samd config

10. Create the local hosts configuration file on the client host. (Optional)

You might want to perform this step if your Sun StorEdge QFS shared host systems have multiple host interfaces. The local hosts configuration file defines the host interfaces that the metadata server and the client hosts can use when accessing the file sysem. You use this file to specify how file system traffic should flow over public and private networks in your environment.

The local hosts configuration file must reside in the following location:

    /etc/opt/SUNWsamfs/hosts.fsname.local

For fsname, specify the Family Set Name of the Sun StorEdge QFS shared file system.

Comments are permitted in the local hosts configuration file. Comment lines must begin with a pound character (`#`). Characters to the right of the pound character are ignored.

TABLE 5-1 shows the fields in the local hosts configuration file.

TABLE 5-1 Local Hosts Configuration File Fields
Field Number | Content
--- | ---
1 | The Host Name field. This field must contain the alphanumeric name of a metadata server or potential metadata server that is part of the Sun StorEdge QFS shared file system.
2 | The Host Interfaces field. This field must contain a comma-separated list of host interface addresses. This field can be created by using the output received from the `ifconfig`(1M) `-a` command. The individual interfaces can be specified in one of the following ways: Dotted-decimal IP address form IP version 6 hexadecimal address form As a symbolic name that the local domain name service (DNS) can resolve to a particular host interface Each host uses this field to determine whether a host will try to connect to the specified host interface. The system evaluates the addresses from left to right, and the connection is made using the first responding address in the list that is also included in the shared hosts file.

In a Sun StorEdge QFS shared file system, each client host obtains the list of metadata server IP addresses from the metadata server host.

The metadata server and the client hosts use both the `/etc/opt/SUNWsamfs`/`hosts.`fs_name file on the metadata server and the `hosts.`fsname`.local` file on each client host (if it exists) to determine the host interface to use when accessing the file system. This process is as follows (note that client, as in network client, is used to refer to both client hosts and the metadata server host in the following process):

1. The client obtains the list of metadata server host IP interfaces from the file system's on-disk host file. To examine this file, issue the `samsharefs`(1M) command from the metadata server or from a potential metadata server.

2. The client searches its files for a `hosts.`fsname`.local` file. Depending on the outcome of the search, one of the following courses of action is taken:

- If a `hosts.`fsname`.local` file does not exist, the client attempts to connect, in turn, to each address in the system hosts configuration file until it succeeds in connecting.

- If the `hosts.`fsname`.local` file exists, the client performs the following tasks:

i. It compares the list of addresses for the metadata server from both the `/etc/opt/SUNWsamfs`/`hosts.`fsname file on the metadata server and the `hosts.`fsname`.local` file.

ii. It builds a list of addresses that are present in both places, and then it attempts to connect to each of these addresses, in turn, until it succeeds in connecting to the server. If the order of the addresses differs in these files, the client uses the ordering in the `hosts.`fsname`.local` file.

Example. This example expands on the example that was introduced in the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide. CODE EXAMPLE 5-15 is an example hosts file that shows four hosts.

CODE EXAMPLE 5-15 Sun StorEdge QFS Shared File System Hosts File Example
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    titan    172.16.0.129,titan.xyzco.com      1        -    server
    tethys   172.16.0.130,tethys.xyzco.com     2        -
    mimas    mimas.xyzco.com                   -        -
    dione    dione.xyzco.com                   -        -

FIGURE 5-1 shows the interfaces to these systems.

FIGURE 5-1 Network Interfaces
[ D ]

Systems `titan` and `tethys` share a private network connection with interfaces `172.16.0.129` and `172.16.0.130`. To guarantee that `titan` and `tethys` always communicate over their private network connection, the system administrator has created identical copies of `/etc/opt/SUNWsamfs/hosts.sharefs1.local` on each system. CODE EXAMPLE 5-16 shows the information in these files.

CODE EXAMPLE 5-16 File `hosts.sharefs1.local` on Both `titan` and `tethys`
    # This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local
    # Host Name    Host Interfaces
    # ---------    ---------------
    titan          172.16.0.129
    tethys         172.16.0.130

Systems `mimas` and `dione` are not on the private network. To guarantee that they connect to `titan` and `tethys` through `titan`'s and `tethys`'s public interfaces, and never attempt to connect to `titan`'s or `tethys`'s unreachable private interfaces, the system administrator has created identical copies of `/etc/opt/SUNWsamfs/hosts.sharefs1.local` on `mimas` and `dione`. CODE EXAMPLE 5-17 shows the information in these files.

CODE EXAMPLE 5-17 File `hosts.sharefs1.local` on Both `mimas` and `dione`
    # This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local
    # Host Name    Host Interfaces
    # ----------   --------------
    titan          titan.xyzco.com
    tethys         tethys.xyzco.com

11. Issue the `samd`(1M) `config` command on the client host.

This informs the `sam-fsd` daemon of the configuration changes. For example:

    # samd config

12. Verify that the `sam-sharefsd` daemon is running for this file system.

To acomplish this, use the `ps`(1) and `grep`(1) commands as shown in CODE EXAMPLE 5-18.

CODE EXAMPLE 5-18 Output from the `ps` (1) Command
    # ps -ef | grep sam-sharefsd
    root 26167 26158  0 18:35:20 ?        0:00 sam-sharefsd sharefs1
    root 27808 27018  0 10:48:46 pts/21   0:00 grep sam-sharefsd

CODE EXAMPLE 5-18 shows that the `sam-sharefsd` daemon is active for the `sharefs1` file system. If this is the case for your system, you can proceed to the next step in this procedure. If, however, the output returned on your system does not show that the `sam-sharefsd` daemon is active for your Sun StorEdge QFS shared file system, perform the diagnostic procedures described in Recovering a Hung mount(1M) Command.

13. If your mount point does not exist, make the mount point for the new Sun StorEdge QFS shared file system.

Use the `mkdir`(1) command to make the directory for the mount point. For example:

    # mkdir /sharefs1

14. Issue the `chmod`(1M) command to give the mount point the `755` set of permissions.

For example:

    # chmod 755 /sharefs1

The permissions must be the same on all participant hosts. `755` is suggested as the initial permission set because users must have execute permission on the mount point in order to be able to use the file system after it has been mounted. After you mount the file systems, the `root` directory's permissions override this setting.

15. Modify the `/etc/vfstab` file.

You must have an entry in the `/etc/vfstab` file for the Sun StorEdge QFS shared file system. Specify `shared` in the Mount Parameters field.

If you want the Sun StorEdge QFS shared file system to automatically mount at boot, make the following changes in the `/etc/vfstab` file:

- Type yes in the `Mt@boot` field.

- Add the `bg` mount option in the `Mt params` field. The `bg` mount option mounts the file system in the background if the metadata server is not responding.

If you do not want to mount this file system automatically at boot time, type `no` in the `Mt@boot` field. In either case, as CODE EXAMPLE 5-19 shows, `shared` is a required entry in the `Mt params` field.

CODE EXAMPLE 5-19 `/etc/vfstab` File Example
    # File /etc/vfstab
    # FS name  FS to fsck  Mnt pt   FS type  fsck  Mt@boot  Mt params
    #                                        pass
    sharefs1   -           /sharefs1 samfs   -     yes      shared,bg

16. Issue the `df`(1M) command on the metadata server to verify that the file system is mounted on the metadata server.

For example:

    # df -k

17. From the client host, issue the `mount`(1M) command to mount the Sun StorEdge QFS shared file system on the client host.

For failover purposes, the mount options should be the same on the metadata server and all potential metadata servers. For example, you can create a `samfs.cmd`(4) file containing mount options and copy it to all the hosts.

For more information about mounting Sun StorEdge QFS shared file systems, see Mount Options in a Sun StorEdge QFS Shared File System, or see the `mount_samfs`(1M) man page.

For example:

    # mount /sharefs1

### To Remove a Client Host

1. Become superuser on the metadata server and on all the client hosts.

Tip - You can use the `samsharefs`(1M) command to verify that you are, indeed, logged into the metadata server or a client host.

2. Use the `umount`(1M) command to unmount the Sun StorEdge QFS shared file system on the first client host.

Repeat this step for all client hosts that have the Sun StorEdge QFS shared file system mounted.

For example:

    client# umount sharefs1

3. Use the `umount`(1M) command to unmount the Sun StorEdge QFS shared file system on the metadata server.

For example:

    metaserver# umount sharefs1

4. If you have not already done so, log in as superuser to the metadata server for the Sun StorEdge QFS shared file system.

5. Use the `samsharefs`(1M) command to obtain the current configuration information.

The following example command writes current configuration information to file `/etc/opt/SUNWsamfs/hosts.sharefs1`:

    # samsharefs -R sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1

6. Use `vi`(1) or another editor to open the Sun StorEdge QFS shared file system information file.

CODE EXAMPLE 5-20 shows the file prior to deleting the client host.

CODE EXAMPLE 5-20 `hosts.sharefs1` Prior to Deleting a Client Host
    # vi /etc/opt/SUNWsamfs/hosts.sharefs1
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    titan    172.16.0.129,titan.xyzco.com      1        -    server
    tethys   172.16.0.130,tethys.xyzco.com     2        -
    mimas    mimas.xyzco.com                   -        -
    dione    dione.xyzco.com                   -        -
    helene   helene.xyzco.com                  -        -

7. Use the editor to delete the client host or hosts that are no longer to be supported.

CODE EXAMPLE 5-21 shows the file after the line for `helene` has been deleted.

CODE EXAMPLE 5-21 `hosts.sharefs1` After Deleting a Client Host
    # File /etc/opt/SUNWsamfs/hosts.sharefs1
    # Host   Host IP                           Server   Not  Server
    # Name   Addresses                         Priority Used Host
    # ----   --------------------------------- -------- ---- -----
    titan    172.16.0.129,titan.xyzco.com      1        -    server
    tethys   172.16.0.130,tethys.xyzco.com     2        -
    mimas    mimas.xyzco.com                   -        -
    dione    dione.xyzco.com                   -        -

8. Use the `samsharefs`(1M) `-R -u` command to update the current hosts information.

For example:

    # samsharefs -R -u sharefs1

The host `helene` has been removed.

9. Use the `samsharefs`(1M) `-R` command to display the current configuration.

For example:

    # samsharefs -R sharefs1

10. Use the `mount`(1M) command to mount the Sun StorEdge QFS shared file system on the metadata server.

For information about the `mount`(1M) command, see the `mount_samfs`(1M) man page.

11. Use the `mount`(1M) command to mount the Sun StorEdge QFS shared file system on the client hosts.

For information about the `mount`(1M) command, see the `mount_samfs`(1M) man page.

##

Changing the Metadata Server in a Sun StorEdge QFS Environment

The procedures in the following sections describe how to change which host is acting as the metadata server in a Sun StorEdge QFS shared file system without using the automatic Membership Services feature of a software package such as Sun Cluster.

You can change the metadata server system manually under the following circumstances:

- If the metadata server becomes unavailable

- If you want to change the metadata server or the potential metadata servers

For changing the metadata server to succeed, the mount options of the existing metadata server and all potential metadata servers must be the same.

Note - Contact the Sun Microsystems Professional Services Group if you need assistance in changing the metadata server in a Sun SAM-QFS environment.

Choose one of the following procedures depending on whether the existing metadata server is available at the time the change is being performed:

- To Change the Metadata Server When the Metadata Server Is Available

- To Change the Metadata Server When the Metadata Server Is Unavailable

### To Change the Metadata Server When the Metadata Server Is Available

This procedure shows how to change the metadata server of a Sun StorEdge QFS shared file system in a Sun StorEdge QFS environment when the metadata server is available.

On the existing metadata server, issue the `samsharefs`(1M) `-s` command to declare the new metadata server.

For example:

    titan# samsharefs -s tethys sharefs1

### To Change the Metadata Server When the Metadata Server Is Unavailable

This procedure shows how to change the metadata server of a Sun StorEdge QFS shared file system in a Sun StorEdge QFS environment when the existing metadata server is unavailable.

1. Ensure that the existing metadata server cannot restart without being rebooted.

Specifically, ensure that the server is powered down, rebooted, halted, or disconnected from the metadata disks. Your goal is to bring down the old metadata server and flush or destroy all buffers (or otherwise ensure that they cannot be rewritten).

CODE EXAMPLE 5-22 shows the key sequence to use from the `kadb` prompt.

CODE EXAMPLE 5-22 Key Sequence for Ensuring that the Metadata Server Cannot Restart from the `kadb` Prompt
    kadb[1]: :c       # Forces a dump
    kadb[1]: $q       # Exits the debugger for prom

CODE EXAMPLE 5-23 shows the key sequence to use from the PROM prompt.

CODE EXAMPLE 5-23 Key Sequence for Ensuring that the Metadata Server Cannot Restart from the PROM Prompt
    {0} > sync         # Forces the buffers out
    {0} > boot args     # Discards buffers

For args, specify arguments for the `boot`(1M) command, such as `-r` or `-v`. For information, see the `boot`(1M) man page.

| Caution - If the metadata server of a shared file system crashes, it is safe to change the metadata server only after rebooting the metadata server or otherwise ensuring that the server cannot issue any I/O prior to being rebooted. Do not use any of the following methods to stop the server because these are likely to corrupt the file system: - Issuing an L1-A key sequence - Performing an involuntary failover to another host - Issuing a go (continue), requesting a dump file, or issuing a `sync` command to the old, down metadata server Similarly, if the metadata server panics and drops into kernel `adb`(1), do not change the metadata server and then issue `:c` (continue) on the server. This action causes the old metadata server to push stale buffers out to the now active file system.

2. From the new (potential) metadata server, wait for at least the period of the maximum lease time, and then issue the `samsharefs`(1M) command.

The wait is necessary because you must ensure that all client leases expire before you issue the `samsharefs`(1M) command. From the new metadata server, issue a command such as the following:

    # samsharefs -R -s tethys sharefs1

If you are uncertain as to whether or not the lease time has expired, bring up the `samu`(1M) `N` display. For information about `samu`(1M), see Using the samu(1M) Operator Utility. For information about leases and their durations, see Using Leases in a Sun StorEdge QFS Shared File System: the rdlease=n, wrlease=n, and aplease=n Options.

| Caution - If you use the `-R` option to the `samsharefs`(1M) command on a mounted file system to change the metadata server host, you must first stop, disable, and disconnect the active metadata server. Failure to do so can cause file system corruption.

3. Unmount the file system. (Optional)

Perform this step only if you want to perform a file system check.

Use the procedure in To Unmount a Sun StorEdge QFS Shared File System.

4. Issue the `samfsck`(1M) command to perform a file system check. (Optional)

Perform this step only if you want to perform a file system check at this time.

If the metadata server of a Sun StorEdge QFS or Sun SAM-QFS shared file system crashes, the server should be rebooted and the file system should be unmounted on all clients before a `samfsck`(1M) is run. The server and clients preallocate blocks before changing the length of files. The `samfsck`(1M) command cleans up files that have extra blocks allocated, and these extra blocks might contain data. If such a cleaned-up file is awaiting a size update from the client, the file will be missing those blocks when the client continues. As a result, the file will be missing data, and the missed data will read as zeroes.

##

Daemons

In a Sun StorEdge QFS shared file system, a `sam-fsd` daemon is always active. In addition, one `sam-sharefsd` daemon is active for each mount point configured in the Sun StorEdge QFS shared file system.

When a `sam-fsd` daemon recognizes a Sun StorEdge QFS shared file system, it starts a shared file system daemon (`sam-sharefsd`). TCP sockets are used to communicate between the server and client hosts. All clients that connect to the metadata server are validated against the hosts file.

One Sun StorEdge QFS shared file system daemon is started for each Sun StorEdge QFS shared file system shared mount point on each client host. This daemon establishes a connection to the metadata server. The `sam-sharedfsd` daemon on the metadata server opens a listener socket on the port named `sam-qfs`. At Sun StorEdge QFS installation time, the `sam-qfs` entry is added to `/etc/services` automatically, and this entry should not be removed. The shared file system port is defined in the `/etc/inet/services` file. The port number installed in the `/etc/inet/services` file is 7105. Verify that this port does not conflict with another service.

Note - Prior to the Sun StorEdge QFS 4.2 release, one port per file system was required. You can remove these entries from your file.

All metadata operations, block allocation and deallocation, and record locking are performed on the metadata server. The `sam-sharefsd` daemon does not keep any information. Hence, it can be killed and restarted without causing any consistency problems for the file system.

##

Mount Options in a Sun StorEdge QFS Shared File System

The Sun StorEdge QFS shared file system can be mounted with several mount options. This chapter describes many options within the context of their roles. Other options, however, are useful only in certain situations. This section describes the mount options that can be used for special purposes.

You can specify most mount options by using the `mount`(1M) command, by entering them in the `/etc/vfstab` file, or by entering them in the `samfs.cmd`(4) file. For example, the following `/etc/vfstab` file includes `mount`(1M) options for a Sun StorEdge QFS shared file system:

    sharefs1 - /sfs samfs - no shared,mh_write

You can change some mount options dynamically by using the `samu`(1M) operator utility. For more information about these options, see Using the samu(1M) Operator Utility.

The following sections summarize the mount options available to you in a Sun StorEdge QFS shared file system. For more information about any of these mount options, see the `mount_samfs`(1M) man page or see the cross-references mentioned in their descriptions.

### Mounting in the Background: the `bg` Option

The `bg` mount option specifies that if the first mount operation fails, subsequent attempts at mounting should occur in the background. By default, `bg` is not in effect, and mount attempts continue in the foreground.

Note - Do not use this option if you are mounting a Sun StorEdge QFS shared file system on a Sun Cluster node.

### Reattempting a File System Mount: the `retry` Option

The `retry` mount option specifies the number of times that the system should attempt to mount a file system. The default is 10000.

### Declaring a Sun StorEdge QFS Shared File System: the `shared` Option

The `shared` mount option declares a file system to be a Sun StorEdge QFS shared file system. This option must be specified in the `/etc/vfstab` file in order for the file system to be mounted as a Sun StorEdge QFS shared file system. The presence of this option in a `samfs.cmd`(4) file or on the `mount`(1M) command does not cause an error condition, but it does not mount the file system as a Sun StorEdge QFS shared file system.

### Tuning Allocation Sizes: the `minallocsz=`n and `maxallocsz=`n Options

The `-o minallocsz=`n and `-o maxallocsz=`n options to the `mount`(1M) command specify an amount of space, in kilobytes. This is the minimum block allocation size. If a file is growing, the metadata server allocates blocks when an append lease is granted. You can use the `-o minallocsz=`n option to specify the initial size of this allocation. The metadata server can increase the size of the block allocation depending on the application's access patterns up to, but not exceeding, the `-o maxallocsz=`n option's setting.

You can specify these `mount`(1M) options on the `mount`(1M) command line, in the `/etc/vfstab` file, or in the `samfs.cmd` file.

### Using Leases in a Sun StorEdge QFS Shared File System: the `rdlease=`n, `wrlease=`n, and `aplease=`n Options

A lease grants a shared host permission to perform an operation on a file for as long as the lease is valid. The metadata server issues leases to each shared host, including itself. The leases are renewed as necessary to permit continued file operations. The possible file operations are as follows:

- A read lease enables existing file data to be read.

- A write lease enables existing file data to be overwritten.

- An append lease enables a file's size to be extended and enables newly allocated blocks to be written.

A shared host can continue to update leases for as long as necessary. The lease is tranparent to the end user. TABLE 5-2 shows the mount options that enable you to specify the duration of each lease type.

TABLE 5-2 Lease-Related `mount` (1M) Options
Option | Action
--- | ---
`-o rdlease=`n | This option specifies the maximum amount of time, in seconds, for the read lease.
`-o wrlease=`n | This option specifies the maximum amount of time, in seconds, for the write lease.
`-o aplease=`n | This option specifies the maximum amount of time, in seconds, for the append lease.

All three leases enable you to specify an n such that 15 n 600. The default time for each lease is 30 seconds. A file cannot be truncated if a lease is in effect. For more information about setting these leases, see the `mount_samfs`(1M) man page.

If you change the metadata server because the current metadata server is down, you must add the lease time to the change over time because all leases must expire before an alternate metadata server can assume control.

Setting a short lease time causes more traffic between the client hosts and the metadata server because the lease must be renewed after it has expired. For information on lease times in a Sun Cluster environment, see the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.

### Enabling Multiple Host Reads and Writes: the `mh_write` Option

By default, in a Sun StorEdge QFS shared file system, multiple hosts can read the same file at the same time, and if no host is writing to that file, I/O can be paged on all hosts. Only one host can append or write to a file at any one time.

The `mh_write` option controls write access to the same file from multiple hosts. If `mh_write` is specified as a mount option on the metadata server host, the Sun StorEdge QFS shared file system enables simultaneous reads and writes to the same file from multiple hosts. If `mh_write` is not specified on the metadata server host, only one host can write to a file at any one time.

By default, `mh_write` is disabled, and only one host has write access to a file at any one time. The length of that time period is determined by the duration of the `wrlease` mount option. If the Sun StorEdge QFS shared file system is mounted on the metadata server with the `mh_write` option enabled, simultaneous reads and writes to the same file can occur from multiple hosts.

TABLE 5-3 describes how file access from multiple hosts is affected depending on whether the `mh_write` option is enabled on the metadata server.

TABLE 5-3 File Access Based on the `mh_write` Option
`mh_write` Not Enabled on the Metadata Server | `mh_write` Enabled on the Metadata Server
--- | ---
Multiple reader hosts allowed. Can use paged I/O. | Multiple reader hosts allowed. Can use paged I/O.
Only one writer host is allowed. Can use paged I/O. All other hosts wait. | Multiple reader and/or writer hosts allowed. If any writer hosts exist, all I/O is direct.
Only one append host. All other hosts wait. | Only one append host is allowed. All other hosts can read and/or write. If any writer hosts exist, all I/O is direct.

The `mh_write` option does not change locking behavior. File locks behave the same whether `mh_write` is in effect or not. The `mh_write` option's effect is as follows:

- When `mh_write` is in effect, all hosts can read from and write to the same file simultaneously.

- When `mh_write` is not in effect, only one host can write to a given file during a given time interval, and no hosts can read from the file during that time interval.

Sun StorEdge QFS shared file system maintains consistency between hosts. The first time that a host executes a read or write system call, it gets a lease, which allows it to read or write the file for some period of time. The existence of that lease prevents other hosts without `mh_write` from accessing the file. In particular, the lease can last longer than the duration of the system call that caused its acquisition.

When `mh_write` is not in effect, the Sun StorEdge QFS shared file system should provide near-POSIX behavior for data reads and writes. For metadata, however, access time changes might not be seen immediately on other hosts. Changes to a file are pushed to disk at the end of a write lease, and when a read lease is acquired, the system invalidates any stale cache pages so that the newly written data can be seen.

When `mh_write` is in effect, behavior might be less consistent. When there are simultaneous readers and writers, the Sun StorEdge QFS shared file system switches all hosts accessing the file into direct I/O mode. This means that page-aligned I/O should be visible immediately to other hosts. However, non-page-aligned I/O can result in stale data being visible, or even written to the file, because the normal lease mechanism that prevents this has been disabled.

You should specify the `mh_write` option only when multiple hosts need to write to the same file simultaneously and when applications perform page-aligned I/O. In other cases, there is some risk of data inconsistency because even using `flock`() (which works with `mh_write`) to coordinate between hosts does not guarantee consistency.

For more information about `mh_write`, see the `mount_samfs`(1M) man page.

### Setting the Number of Concurrent Threads: the `nstreams=`n Option

The `nstreams=`n mount option sets the number of concurrent threads for the Sun StorEdge QFS shared file system. By default, `nstreams=256`. This means, for example, that under default settings, up to 256 operations can be processed simultaneously, and the 257th operation commences only after an operation has finished. You can adjust the `nstreams=`n mount option based on the Sun StorEdge QFS shared file system's activity. For n, specify a value such that 76 n 1024.

### Retaining Cached Attributes: the `meta_timeo=`n Option

The `meta_timeo=`n mount option determines how long the system waits between checks on the metadata information. By default, the system refreshes metadata information every 15 seconds. This means, for example, that an `ls`(1) command entered in a Sun StorEdge QFS shared file system with several newly created files might not return information about all the files until 15 seconds had passed. For n, specify a value such that 0 n 60.

### Specifying Striped Allocation: the `stripe` Option

By default, data files in the Sun StorEdge QFS shared file system are allocated using the round-robin file allocation method. To specify that file data be striped across disks, you can specify the `stripe` mount option on the metadata host and all potential metadata hosts. Note that by default, unshared file systems allocate file data using the striped method.

In a round-robin allocation, files are created in a round-robin fashion on each slice or striped group. This causes the maximum performance for one file to be the speed of a slice or striped group. For more information about file allocation methods, see File System Design.

### Specifying the Frequency With Which Metadata is Written: the `sync_meta=`n Option

You can set the `sync_meta=`n option to `sync_meta=1` or `sync_meta=0`.

By default, `sync_meta=1` and a Sun StorEdge QFS shared file system writes file metadata to disk every time the metadata changes. This slows data performance, but it ensures data consistency. This is the setting that must be in effect if you want to change the metadata server.

If you set `sync_meta=0`, the Sun StorEdge QFS shared file system writes the metadata to a buffer before writing it to disk. This delayed write delivers higher performance, but it decreases data consistency after an unscheduled machine interruption.

##

Mount Semantics in a Sun StorEdge QFS Shared File System

The behavior of the Sun StorEdge QFS shared file system is that of an interruptible hard connection. Each client tries repeatedly to communicate with the metadata server, even if the server is unavailable. If the metadata server is not responding, a user can terminate any pending, blocked I/O transmission by pressing Ctrl-C. If the I/O attempt is interrupted, the client persists until the I/O completes.

The system generates the following messages to describe status conditions:

    SAM-FS: Shared server is not responding.

This message is also generated if the client `sam-sharefsd` daemon is not active or if the server `sam-sharefsd` daemon is not active. When the server responds, it generates the following message:

    SAM-FS: Shared server is responding.

If the file system is not mounted on the metadata server, but it is mounted on the client, the system generates the following message:

    SAM-FS: Shared server is not mounted.

When the Sun StorEdge QFS shared file system mounts on the server, it generates the following message:

    SAM-FS: Shared server is mounted.

##

File Locking in a Sun StorEdge QFS Shared File System

Mandatory locks are not supported. An EACCES error is returned if the mandatory lock is set. Advisory locks are supported. For more information about advisory locks, see the `fcntl`(2) system call.

##

Performance Considerations

Because the metadata server looks up file names on behalf of all clients, performance can improve if you increase the size of the Solaris directory name lookup cache (DNLC) on the metadata server. This can increase performance when clients are frequently opening a large number of files. Doubling or tripling the size of this cache from its default can be appropriate.

This procedure is documented in the Solaris Tunable Parameters Reference Manual. The parameter that controls the size of the directory name lookup cache is `ncsize`.

##

Troubleshooting a Failed or Hung `sammkfs`(1M) or `mount`(1M) Command

The following sections describe what to do when a `sammkfs`(1M) or `mount`(1M) command fails or when a `mount`(1M) command hangs.

The procedures in this section can be performed on client hosts and can also be performed on the server. Commands that can be executed only on the metadata server are preceded with a `server#` prompt.

### Recovering a Failed `sammkfs`(1M) Command

If the `sammkfs`(1M) command returns an error or messages indicating that an unexpected set of devices are to be initialized, you need to perform this procedure. It includes steps for verifying the `mcf`(4) file and for propagating `mcf`(4) file changes to the system.

To Verify the `mcf`(4) File and Propagate `mcf`(4) File Changes to the System

1. Use the `sam-fsd`(1M) command to verify the `mcf`(4) file.

For example:

    # sam-fsd

Examine the output from the `sam-fsd`(1M) command and determine if there are errors that you need to fix.

2. Edit the `mcf`(4) file to resolve any diagnostic issues. (Optional)

Perform this step if the output from the `sam-fsd`(1M) command indicates that there are errors in the `/etc/opt/SUNWsamfs/mcf` file.

3. Issue the `sam-fsd`(1M) command again to verify the `mcf`(4) file.

Repeat Step 1, Step 2, and Step 3 of this process until the output from the `sam-fsd`(1M) command indicates that the `mcf`(4) file is correct.

4. Issue the `samd`(1M) `config` command.

This is needed to propagate `mcf`(4) file changes by informing the `sam-fsd` daemon of the configuration change.

For example:

    # samd config

### Recovering a Failed `mount`(1M) Command

A `mount`(1M) command can fail for several reasons. This section describes some actions you can take to remedy a mount problem. If the `mount`(1M) command hangs, rather than fails, see Recovering a Hung mount(1M) Command.

Some failed `mount`(1M) behaviors and their remedies are as follows:

- If the mount(1M) command fails with a `Shared server is not mounted` message generated on a client, determine the server host and mount the file system on the metadata server.

- If the mount command fails with a message indicating that there is a mismatch between the file system and the `mcf`(4) file, ensure the following:

- That the `mcf`(4) file is syntactically valid. For more information, see To Verify the mcf(4) File and Propagate mcf(4) File Changes to the System.

- That recent changes to the `mcf`(4) file are valid and have been enacted. For more information, see To Verify the mcf(4) File and Propagate mcf(4) File Changes to the System.

- That the `mcf`(4) file matches the server's `mcf`(4) file with device names or controller numbers adjusted for any differences on the client. You can use the `samfsconfig`(1M) command to diagnose some of these problems. For more information about using the `samfsconfig`(1M) command, see To Use the samfsconfig(1M) Command.

- If the `mount`(1M) command fails for other reasons, use the procedures described in the following sections to verify the system characteristics that must be in place in order for the `mount`(1M) command to be successful. These procedures are as follows:

- To Verify that the File System can be Mounted

- To Use the samfsinfo(1M) and samsharefs(1M) Commands

- To Use the samfsconfig(1M) Command

To Verify that the File System can be Mounted

If this procedure does not expose errors, perform To Use the samfsinfo(1M) and samsharefs(1M) Commands, which can help you verify that the file system has been created and that the shared hosts file is correctly initialized.

The following procedure shows you what to verify if the `mount`(1M) command fails.

1. Ensure that the mount point directory is present.

There are multiple ways to accomplish this. For example, you can issue the `ls`(1) command in the following format:

    ls -ld mountpoint

For mountpoint, specify the name of the Sun StorEdge QFS shared file system's mount point.

When you examine the `ls`(1) command's output, make sure that the output shows a directory with access mode 755. In other words, the codes should read `drwxr-xr-x`. CODE EXAMPLE 5-24 shows example output.

CODE EXAMPLE 5-24 Access Mode Values
    # ls -ld /sharefs1
    drwxr-xr-x   2 root     sys          512 Mar 19 10:46 /sharefs1

If the access is not at this level, enter the following `chmod`(1) command:

    # chmod 755 mountpoint

For mountpoint, specify the name of the Sun StorEdge QFS shared file system's mount point.

2. Ensure that there is an entry for the file system in the `/etc/vfstab` file.

CODE EXAMPLE 5-25 shows an entry for the shared file system named `sharefs1`.

CODE EXAMPLE 5-25 Example `/etc/vfstab` File
    # File /etc/vfstab
    # FS name  FS to fsck  Mnt pt FS type  fsck pass  Mt@boot  Mt params
    sharefs1    -         /sharefs1 samfs -         yes     shared,bg

Ensure that the `shared` flag is present in the Mount Parameters field of the shared file system's entry in the `/etc/vfstab` file.

3. Ensure that the mount point directory is not shared out for NFS use.

If the mount point is shared, use the `unshare`(1M) command to unshare it. For example:

    # unshare mountpoint

For mountpoint, specify the name of the Sun SAM-QFS shared file system's mount point.

To Use the `samfsinfo`(1M) and `samsharefs`(1M) Commands

This procedure shows how to analyze the output from these commands.

1. Enter the `samfsinfo`(1M) command on the server.

Use this command in the following format:

    samfsinfo filesystem

For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the `mcf`(4) file. CODE EXAMPLE 5-26 shows the `samfsinfo`(1M) command and output.

CODE EXAMPLE 5-26 `samfsinfo` (1M) Command Example
    titan-server# samfsinfo sharefs1
    samfsinfo: filesystem sharefs1 is mounted.
    name:     sharefs1       version:     2    shared
    time:     Mon Apr 29 15:12:18 2002
    count:    3
    capacity:      10d84000          DAU:         64
    space:         10180400
    meta capacity: 009fe200          meta DAU:    16
    meta space:    009f6c60
    ord  eq   capacity      space   device
    1    11   086c0000   080c39b0   /dev/dsk/c1t2100002037E9C296d0s6
    2    12   086c4000   080bca50   /dev/dsk/c3t50020F2300005D22d0s6
    3    13   086c4000   080a9650   /dev/dsk/c3t50020F2300006099d0s6
    4    14   086c4000   08600000   /dev/dsk/c3t50020F230000651Cd0s6

The output from CODE EXAMPLE 5-26 shows a `shared` keyword in the following line:

    name:     sharefs1       version:     2    shared

Note the list of file system devices, ordinals, and equipment numbers that appear after the following line:

    ord  eq   capacity      space   device

Make sure that these numbers correspond to the devices in the file system's `mcf`(4) entry.

2. Enter the `samsharefs`(1M) command on the server.

Use this command in the following format:

    samsharefs -R filesystem

For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the `mcf`(4) file. CODE EXAMPLE 5-27 shows the `samsharefs`(1M) command and output.

CODE EXAMPLE 5-27 `samsharefs` (1M) Command Example
    titan-server# samsharefs -R sharefs1
    #
    # Host file for family set 'sharefs1'
    #
    # Version: 3    Generation: 50    Count: 4
    # Server = host 0/titan, length = 216
    #
    titan 173.26.2.129,titan.foo.com 1 - server
    tethys 173.26.2.130,tethys.foo.com 2 -
    dione dione.foo.com 0 -
    mimas mimas.foo.com 0 -

The following information pertains to the diagnostic output from the `samfsinfo`(1M) or `samsharefs`(1M) commands.

- If either command issues diagnostics or error messages, resolve them. Ensure that the output from the `samfsinfo`(1M) command includes the `shared` keyword.

- You can execute these commands on alternate server hosts and on client hosts that have no `nodev` devices in the host's `mcf` entry for the file system.

If the `samfsinfo`(1M) and `samsharefs`(1M) commands do not expose irregularities, perform To Use the samfsconfig(1M) Command.

To Use the `samfsconfig`(1M) Command

On clients with `nodev` device entries in the `mcf` file for the file system, the entire file system might not be accessible, and the shared hosts file might not be directly accessible. You can use the `samfsconfig`(1M) command to determine whether the shared file system's data partitions are accessible.

Issue the `samfsconfig`(1M) command.

Use this command in the following format:

    samfsconfig list_of_devices

For list_of_devices, specify the list of devices from the file system entry in the `mcf`(4) file. Use a space to separate multiple devices in the list.

Example 1. CODE EXAMPLE 5-28 shows the `samfsconfig`(1M) command issued on a host that does not have a `nodev` entry in its `mcf` file. CODE EXAMPLE 5-28 shows the `mcf` file for the host `tethys`.

CODE EXAMPLE 5-28 `samfsconfig` (1M) Command Example Without `nodev` Entries
    tethys# cat /etc/opt/SUNWsamfs/mcf
    sharefs1                         10  ma   sharefs1    on  shared
    /dev/dsk/c1t2100002037E9C296d0s6 11  mm   sharefs1    -
    /dev/dsk/c3t50020F2300005D22d0s6 12  mr   sharefs1    -
    /dev/dsk/c3t50020F2300006099d0s6 13  mr   sharefs1    -
    /dev/dsk/c3t50020F230000651Cd0s6 14  mr   sharefs1    -
    tethys# samfsconfig /dev/dsk/c1t2100002037E9C296d0s6 /dev/dsk/c3t50020F2300005D22d0s6 /dev/dsk/c3t50020F2300006099d0s6 /dev/dsk/c3t50020F230000651Cd0s6
    #
    # Family Set 'sharefs1' Created Mon Apr 29 15:12:18 2002
    #
    sharefs1                           10    ma   sharefs1  - shared
    /dev/dsk/c1t2100002037E9C296d0s6   11    mm   sharefs1  -
    /dev/dsk/c3t50020F2300005D22d0s6   12    mr   sharefs1  -
    /dev/dsk/c3t50020F2300006099d0s6   13    mr   sharefs1  -
    /dev/dsk/c3t50020F230000651Cd0s6   14    mr   sharefs1  -

Example 2. CODE EXAMPLE 5-29 shows the `samfsconfig`(1M) command being used on a host that has a `nodev` entry in its `mcf` file.

CODE EXAMPLE 5-29 `samfsconfig` (1M) Command Example With `nodev` Entries
    dione# cat /etc/opt/SUNWsamfs/mcf
    sharefs1                             10    ma   sharefs1  on  shared
    nodev                              11    mm   sharefs1  -
    /dev/dsk/c4t50020F23000055A8d0s3   12    mr   sharefs1  -
    /dev/dsk/c4t50020F23000055A8d0s4   13    mr   sharefs1  -
    /dev/dsk/c4t50020F23000055A8d0s5   14    mr   sharefs1  -
    dione# samfsconfig /dev/dsk/c4t50020F23000055A8d0s3 /dev/dsk/c4t50020F23000055A8d0s4 /dev/dsk/c4t50020F23000055A8d0s5
    #
    # Family Set 'sharefs1' Created Mon Apr 29 15:12:18 2002
    #
    # Missing slices
    # Ordinal 1
    # /dev/dsk/c4t50020F23000055A8d0s3    12    mr   sharefs1  -
    # /dev/dsk/c4t50020F23000055A8d0s4    13    mr   sharefs1  -
    # /dev/dsk/c4t50020F23000055A8d0s5    14    mr   sharefs1  -

For examples 1 and 2, verify that the output lists all slices from the file system, other than the metadata (`mm`) devices, as belonging to the file system. This is the case for example 2.

### Recovering a Hung `mount`(1M) Command

If the `mount`(1M) command hangs, follow the procedure in this section. You have a hung `mount`(1M) command if, for example, the `mount`(1M) command fails with a connection error or with a `Server not responding` message that does not resolve itself within 30 seconds.

The most typical remedy for a hung `mount`(1M) command is presented first. If that does not work, perform the subsequent procedures.

To Verify Network Connections

The `netstat`(1M) command verifies that the `sam-sharefsd` daemon's network connections are correctly configured.

1. Become superuser on the metadata server.

2. Type the `samu`(1M) command to invoke the `samu`(1M) operator utility.

For example:

    # samu

3. Press `P` to access the `Active Services` display.

CODE EXAMPLE 5-30 shows a `P` display.

CODE EXAMPLE 5-30 `P` Display on the Metadata Server
    Active Services                        samu   4.2 09:02:22 Sept 22 2004
    Registered services for host 'titan':
        sharedfs.sharefs1
      1 service(s) registered.

Examine the output. In CODE EXAMPLE 5-30, look for a line that contains `sharedfs.`filesystem-name. In this example, the line must contain `sharedfs.sharefs1`.

If no such line appears, you need to verify that both the `sam-fsd` and `sam-sharefsd` daemons have started. Perform the following steps:

a. Enable daemon tracing in the `defaults.conf` file.

For information about how to enable tracing, see `defaults.conf`(4) or see Step 2 in To Examine the sam-sharefsd Trace Log (Optional).

b. Examine your configuration files, especially `/etc/opt/SUNWsamfs/mcf`.

c. After you have checked your configuration files and verified that the daemons are active, begin this procedure again.

4. Enter the `samsharefs`(1M) command to check the hosts file.

CODE EXAMPLE 5-34 shows the `samsharefs`(1M) command and correct output.

CODE EXAMPLE 5-31 `samsharefs` (1M) `-R` Command
    titan-server# samsharefs -R sharefs1
    #
    # Host file for family set 'sharefs1'
    #
    # Version: 3    Generation: 50    Count: 4
    # Server = host 0/titan, length = 216
    #
    titan 173.26.2.129,titan.foo.com 1 - server
    tethys 173.26.2.130,tethys.foo.com 2 -
    dione dione.foo.com 0 -
    mimas mimas.foo.com 0 -

In the output on your system, verify the following:

- That the host name is present in column 1 of the output and that it is designated as the server.

- That the host IP address is present in column 2. If there are multiple IP addresses, make sure that they are all valid.

5. Enter the `netstat`(1M) command on the server.

CODE EXAMPLE 5-32 shows the `netstat`(1M) command entered on server `titan`.

CODE EXAMPLE 5-32 `netstat` (1M) Example on the Server
    titan-server# netstat -a | grep sam-qfs
          *.sam-qfs *.*            0     0 24576  0 LISTEN
          *.sam-qfs *.*            0     0 24576  0 LISTEN
    titan.32834  titan.sam-qfs 32768     0 32768  0 ESTABLISHED
    titan.sam-qfs  titan.32891 32768     0 32768  0 ESTABLISHED
    titan.sam-qfs tethys.32884 24820     0 24820  0 ESTABLISHED
    titan.sam-qfs  dione.35299 24820     0 24820  0 ESTABLISHED
         *.sam-qfs *.*             0     0 24576  0 LISTEN

Verify that the output from the `netstat`(1M) command on the server contains the following:

- Three `LISTEN` entries.

- Two `ESTABLISHED` entries for the host.

- One `ESTABLISHED` entry for each client that is configured and running the `sam-fsd` daemon. This example shows `ESTABLISHED` entries for `tethys` and `dione`. There should be one `ESTABLISHED` entry for each client that is configured and running whether or not it is mounted.

6. Enter the `netstat`(1M) command on the client.

CODE EXAMPLE 5-33 shows the `netstat`(1M) command entered on client `dione`.

CODE EXAMPLE 5-33 `netstat` (1M) Command on the Client
    dione-client# netstat -a | grep sam-qfs
         *.sam-qfs     *.*            0    0 24576      0 LISTEN
         *.sam-qfs     *.*            0    0 24576      0 LISTEN
    dione.32831    titan.sam-qfs  24820    0 24820      0 ESTABLISHED
         *.sam-qfs     *.*            0    0 24576      0 LISTEN

Verify that the output contains the following:

- Three `LISTEN` entries. All entries are for the `sam-fsd` daemon.

- One `ESTABLISHED` entry.

If these lines are present, then the network connection is established.

If an `ESTABLISHED` connection is not reported, go to Step 7.

7. Perform one or more of the following procedures:

- To Verify that the Client Can Reach the Server (Optional)

- To Verify that the Server Can Reach the Client (Optional)

- To Examine the sam-sharefsd Trace Log (Optional)

To Verify that the Client Can Reach the Server (Optional)

Perform these steps if using the procedure described in To Verify Network Connections did not show an `ESTABLISHED` connection.

1. Use the `samsharefs`(1M) command to verify the hosts file on the server.

You can issue the `samsharefs`(1M) command on alternate server hosts and client hosts that have no `nodev` devices listed in the host's `mcf`(4) entry for the file system. For this step, use this command in the following format:

    samsharefs -R filesystem

For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the `mcf`(4) file. CODE EXAMPLE 5-34 shows the `samsharefs`(1M) `-R` command.

CODE EXAMPLE 5-34 `samsharefs` (1M) `-R` Command
    titan-server# samsharefs -R sharefs1
    #
    # Host file for family set 'sharefs1'
    #
    # Version: 3    Generation: 50    Count: 4
    # Server = host 0/titan, length = 216
    #
    titan 173.26.2.129,titan.xyzco.com 1 - server
    tethys 173.26.2.130,tethys.xyzco.com 2 -
    dione dione.foo.com 0 -
    mimas mimas.foo.com 0 -

2. Save this output.

If the steps in this procedure fail, you need this output for use in subsequent procedures.

3. Verify that the output matches expectations.

If the command fails, verify that the file system was created. In this case it is likely that one of the following has occurred:

- The `mcf` file was not created properly. You can use the `samfsconfig`(1M) command to verify the correctness of the `mcf` file.

- The file system was never created.

- The initial hosts configuration files have not been created. For information about configuring these files, see the procedures earlier in this chapter. The configuration process involves editing the existing `mcf`(4) file, propagating the `mcf`(4) file changes to the rest of the system, and configuring the hosts files.

4. Find the row containing the server's name in the first column.

5. From the client, use the `ping`(1M) command on each entry from the second column of `samsharefs`(1M) output to verify that the server can be reached.

Use this command in the following format:

    ping servername

For servername, specify the name of the server as shown in the second column of the `samsharefs`(1M) command's output.

CODE EXAMPLE 5-35 shows output from `ping`(1M).

CODE EXAMPLE 5-35 Using `ping` (1M) on Systems Named in `samsharefs` (1M) Output
    dione-client# ping 173.26.2.129
    ICMP Host Unreachable from gateway dione (131.116.7.218)
    for icmp from dione (131.116.7.218) to 173.26.2.129
    dione-client# ping titan.xyzco.com
    titan.foo.com is alive

6. From the client, examine the `hosts.`filesystem.`local` file. (Optional)

Perform this step if the `ping`(1M) command revealed unreachable hosts.

If there is more than one entry in the second column of `samsharefs`(1M) output, and if some of the entries are not reachable, ensure that only the reachable entries for the entries you want the shared file system to use are present. Also ensure that the necessary entries are present in the `/etc/opt/SUNWsamfs/hosts.`filesystem`.local` file entry on that host. Ensure that the unreachable hosts are not entered in these places.

If the `sam-sharefsd` daemon attempts to connect to unreachable server interfaces, there can be substantial delays in its connecting to the server after installation, rebooting, or file system host reconfiguration. This affects metadata server failover operations substantially.

CODE EXAMPLE 5-36 shows the `hosts.sharefs1.local` file.

CODE EXAMPLE 5-36 Examining the `hosts.` filesystem `.local` File
    dione-client# cat /etc/opt/SUNWsamfs/hosts.sharefs1.local
    titan       titan.xyzco.com            # no route to 173.26.2.129
    tethys      tethys.xyzco.com           # no route to 173.26.2.130

7. Enable the correct server interfaces. (Optional)

If the `ping`(1M) command revealed that there were no reachable server interfaces, then you need to either configure or initialize the server network interfaces for typical operations, or you must use the `samsharefs`(1M) command to update the interface names in the hosts file so they match the actual names.

To Verify that the Server Can Reach the Client (Optional)

Perform these steps if the procedure in To Verify Network Connections did not show an `ESTABLISHED` connection.

1. Obtain `samsharefs`(1M) output.

This can be the output generated in To Verify that the Client Can Reach the Server (Optional), or you can generate it again using the initial steps in that procedure.

2. Find the row containing the client's name in the first column.

3. On the client, run the `hostname`(1M) command and ensure that the output matches the name in the first column of `samsharefs`(1M) output.

CODE EXAMPLE 5-37 shows the `hostname`(1M) command and its output.

CODE EXAMPLE 5-37 `hostname` (1M) Output
    dione-client# hostname
    dione

4. Use the `ping`(1M) command on the server on each entry from the second column to verify that the client can be reached. (Optional)

Perform this step if the `hostname`(1M) command output matched the name in the second column of `samsharefs`(1M) output. CODE EXAMPLE 5-38 shows the `ping`(1M) command and its output.

CODE EXAMPLE 5-38 `ping` (1M) Output
    titan-server# ping dione.xyzco.com
    dione.xyzco.com is alive

It is not necessary that every entry in column two of CODE EXAMPLE 5-36 be reachable, but all interfaces that you wish any potential server to accept connections from must be present in the column. The server rejects connections from interfaces that are not declared in the shared hosts file.

5. Enable the correct client interfaces. (Optional)

If the `ping`(1M) command revealed that there were no reachable client interfaces, then either you need to configure or initialize the client network interfaces for typical operations, or you must use the `samsharefs`(1M) command to update the interface names in the hosts file so they match the actual names.

To Examine the `sam-sharefsd` Trace Log (Optional)

The trace log files keep information generated by the `sam-sharefsd`(1M) daemons during their operation. The trace log files include information about connections attempted, received, denied, refused, and so on, as well as other operations such as host file changes and metadata server changes.

Tracking problems in log files often involves reconciling the order of operations on different hosts by using the log files. If the hosts' clocks are synchronized, log file interpretation is greatly simplified. One of the installation steps directs you to enable the network time daemon, `xntpd`(1M). This synchronizes the clocks of the metadata server and all client hosts during Sun StorEdge QFS shared file system operations.

The trace logs are particularly useful when setting up an initial configuration. The client logs show outgoing connection attempts. The corresponding messages in the server log files are some of the most useful tools for diagnosing network and configuration problems with the Sun StorEdge QFS shared file system. The log files contain diagnostic information for resolving most common problems.

The following procedures can resolve `mount`(1M) problems:

- To Verify Network Connections

- To Verify that the Client Can Reach the Server (Optional)

- To Verify that the Server Can Reach the Client (Optional)

If none of the preceding procedures resolved the problem, perform the steps in this section. You can perform these steps on both the server and the client hosts.

1. Verify the presence of file `/var/opt/SUNWsamfs/trace/sam-sharefsd`.

If this file is not present, or if it shows no recent modifications, proceed to the next step.

If the file is present, use `tail`(1) or another command to examine the last few lines in the file. If it shows suspicious conditions, use one or more of the other procedures in this section to investigate the problem.

2. Edit file `/etc/opt/SUNWsamfs/defaults.conf` and add lines to enable `sam-sharefsd` tracing. (Optional)

Perform this step if Step 1 indicates that file `/var/opt/SUNWsamfs/trace/sam-sharefsd` does not exist or if the file shows no recent modifications.

a. Copy the example `defaults.conf` file from `/opt/SUNWsamfs/examples/defaults.conf` to `/etc/opt/SUNWsamfs`. (Optional)

Perform this step if a `defaults.conf` file does not reside in `/etc/opt/SUNWsamfs` at this time. CODE EXAMPLE 5-39 shows this.

CODE EXAMPLE 5-39 Copying the `defaults.conf` File
    # cd /etc/opt/SUNWsamfs
    # cp /opt/SUNWsamfs/examples/defaults.conf .

b. Use `vi`(1) or another editor to edit file `/opt/SUNWsamfs/examples/defaults.conf` and add lines to enable tracing.

CODE EXAMPLE 5-40 shows the lines to add to the `defaults.conf` file.

CODE EXAMPLE 5-40 Lines to Enable Tracing in `defaults.conf`
    trace
    sam-sharefsd = on
    sam-sharefsd.options = all
    endtrace

c. Issue the `samd`(1M) `config` command to reconfigure the `sam-fsd`(1M) daemon and cause it to recognize the new `defaults.conf`(4) file.

For example:

    # samd config

d. Issue the `sam-fsd`(1M) command to check the configuration files.

CODE EXAMPLE 5-41 shows the output from the `sam-fsd`(1M) command.

CODE EXAMPLE 5-41 Output From the `sam-fsd` (1M) Command
    # sam-fsd
    Trace file controls:
    sam-archiverd off
    sam-catserverd off
    sam-fsd       off
    sam-rftd      off
    sam-recycler  off
    sam-sharefsd  /var/opt/SUNWsamfs/trace/sam-sharefsd
                  cust err fatal misc proc date
                  size    0    age 0
    sam-stagerd   off
    Would stop sam-archiverd()
    Would stop sam-rftd()
    Would stop sam-stagealld()
    Would stop sam-stagerd()
    Would stop sam-initd()

e. Examine the log file in `/var/opt/SUNWsamfs/trace/sam-sharefsd` to check for errors.

    # more /var/opt/SUNWsamfs/trace/sam-sharefsd

3. Examine the last few dozen lines of the trace file for diagnostic information.

CODE EXAMPLE 5-42 shows a typical `sam-sharefsd` client log file. In this example, the server is `titan`, and the client is `dione`. This file contains normal log entries generated after a package installation, and it finishes with the daemon operating normally on a mounted file system.

CODE EXAMPLE 5-42 Client Trace File
    dione# tail -18 /var/opt/SUNWsamfs/trace/sam-sharefsd
    2004-03-23 16:13:11 shf-shsam2[13835:1]: FS shsam2: Shared file system daemon started - config only
    2004-03-23 16:13:11 shf-shsam2[13835:1]: FS shsam2: Host dione
    2004-03-23 16:13:11 shf-shsam2[13835:1]: FS shsam2: Filesystem isn't mounted
    2004-03-23 16:13:11 shf-shsam2[13837:1]: FS shsam2: Shared file system daemon started
    2004-03-23 16:13:11 shf-shsam2[13837:1]: FS shsam2: Host dione
    2004-03-23 16:13:11 shf-shsam2[13837:1]: FS shsam2: Filesystem isn't mounted
    2004-03-23 16:13:11 shf-shsam2[13837:1]: FS shsam2: Kill sam-sharefsd pid 13835
    2004-03-23 16:13:12 shf-shsam2[13837:1]: FS shsam2: Killed sam-sharefsd pid 13835
    2004-03-23 16:13:12 shf-shsam2[13837:1]: FS shsam2: Host dione; server = titan
    2004-03-23 16:13:12 shf-shsam2[13837:1]: FS shsam2: Wakened from AWAIT_WAKEUP
    2004-03-23 16:13:14 shf-shsam2[13837:5]: FS shsam2: Set Client (Server titan/3).
    2004-03-23 16:13:14 shf-shsam2[13837:5]: FS shsam2: SetClientSocket dione (flags=0)
    2004-03-23 16:13:14 shf-shsam2[13837:5]: FS shsam2: rdsock dione/0 (buf=6c000).
    2004-03-23 16:13:15 shf-shsam2[13837:1]: FS shsam2: Signal 1 received: Hangup
    2004-03-23 16:13:15 shf-shsam2[13837:1]: FS shsam2: Wakened from AWAIT_WAKEUP
    2004-03-23 16:13:15 shf-shsam2[13837:1]: FS shsam2: mount; flags=18889
    2004-03-23 16:18:55 shf-shsam2[13837:1]: FS shsam2: Signal 1 received: Hangup
    2004-03-23 16:18:55 shf-shsam2[13837:1]: FS shsam2: Wakened from AWAIT_WAKEUP

Copyright © 2004, Sun Microsystems, Inc. All rights reserved.