C H A P T E R 7

Using the Sun SAM-Remote Software

The Sun SAM-Remote client and the Sun SAM-Remote server form a client/server implementation that enables libraries and other removable media devices to be shared between Sun StorEdge SAM-FS host systems. Sun SAM-Remote enables you to configure multiple storage clients that archive and stage files from a centralized tape library or magneto-optical library. For example, if you have host systems on a network that spans a large geographical area, files created in one city can be archived to cartridges in a library located miles away.

This chapter includes the following sections:

- Sun SAM-Remote Software Overview

- Configuring the Sun SAM-Remote Software

- Recycling With the Sun SAM-Remote Software

##

Sun SAM-Remote Software Overview

The following topics are covered in this overview:

- Features

- Requirements

- Limitations

- Client and Server Interactions

### Features

FIGURE 7-1 shows an environment configured with two Sun SAM-Remote host system servers. Each has two clients.

FIGURE 7-1 Sun SAM-Remote Servers and Clients

Sun SAM-Remote software provides the following advantages:

- Enables you to configure remote sharing of an expensive removable media resource, such as a library, between two or more Sun SAM-Remote clients.

- Enables clients to migrate data to a server.

- Enables multiple Sun StorEdge SAM-FS servers to be hosts to one another. In a Sun SAM-Remote environment, the server is the host system that is configured with an equipment type of `ss` in the `mcf` file.

You can configure the Sun SAM-Remote server and clients to provide multiple archive copies between two or more Sun Solaris host systems. For example, you can configure two Solaris systems running Sun StorEdge SAM-FS software as both a Sun SAM-Remote server and a Sun SAM-Remote client to each other. Benefits of this configuration include the ability to create local copies for each server with an additional archive copy of data on the other server. File systems can be shared between servers using standard NFS. In the event of a loss of access to the local library, Sun SAM-Remote software would automatically retrieve file data from the archive copy. Users of both servers would have uninterrupted access to their data, even if their primary storage library were unavailable.

### Requirements

Before attempting to configure a Sun SAM-Remote environment, make sure that your environment includes the following software and hardware:

- SPARC or x64 systems with licensed, installed, and operable Sun StorEdge SAM-FS 4U0 or later storage and archive management software packages.

- Host systems with identical Sun StorEdge SAM-FS software revision levels and identical patch collections installed. If some host systems have to be upgraded, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.

- One host system to act as the Sun SAM-Remote server with at least one SAM-QFS file system installed upon it.

- A network connection running a TCP/IP connection between the clients and the server upon which the Sun StorEdge SAM-FS software is installed.

### Limitations

The storage and archive manager treats cartridges in a remote library no differently from the way it treats cartridges in a local library. The following information, however, indicates the limits of Sun SAM-Remote software:

- You can recycle media using Sun SAM-Remote, but you should attempt this only after thoroughly testing your environment. For more information, see Recycling With the Sun SAM-Remote Software.

- Only one daemon on a Sun SAM-Remote client can communicate to the Sun SAM-Remote server.

- Sun StorEdge SAM-FS software, and therefore SAM-Remote, cannot operate on Sun StorEdge QFS clients in a shared Sun StorEdge QFS file system. When running on a server that is a metadata server for some Sun StorEdge QFS file systems and a client for other Sun StorEdge QFS file systems, Sun StorEdge SAM-FS software and SAM-Remote operate only on the file systems for which that server is a metadata server.

### Client and Server Interactions

The Sun SAM-Remote clients interact with the Sun SAM-Remote server using a TCP/IP connection. The network between the Sun SAM-Remote clients can be any network type supported by the Sun Solaris operating environment, such as Ethernet, Fast Ethernet, or Fibre Channel.

FIGURE 7-2 shows Sun SAM-Remote client and Sun SAM-Remote server interactions.

FIGURE 7-2 Sun SAM-Remote Server and Client Interactions

#### Sun SAM-Remote Server Overview

The Sun SAM-Remote server consists of a full-capability Sun StorEdge SAM-FS storage management host and a Sun SAM-Remote server daemon that defines libraries to be shared among the clients. At least one SAM-QFS file system must be configured on the Sun SAM-Remote server.

You define a host system as a Sun SAM-Remote server by adding a line in the server system's `/etc/opt/SUNWsamfs/mcf` file with an equipment type of `ss`. You must provide a unique family set name for each server. Up to ten clients can be configured per daemon. To configure more than ten clients, add an additional remote server entry in the `mcf` file for each ten clients that you want to configure. For more information about the server daemon, see the `sam-remote`(7) man page.

#### Sun SAM-Remote Client Overview

The Sun SAM-Remote client is a Sun StorEdge SAM-FS host system that establishes a Sun SAM-Remote client daemon containing a number of pseudo-devices.

You define a host system as a Sun SAM-Remote client by adding a line in the client system's `/etc/opt/SUNWsamfs/mcf` file with an equipment type of `sc`. For more information about the client daemon, see the `sam-remote`(7) man page.

A pseudo-device defines a network connection to an actual removable media device on the Sun SAM-Remote server. Pseudo-devices have an equipment type of `rd`, which is a mnemonic for remote device. You define the pseudo-devices in the Sun SAM-Remote client's `/etc/opt/SUNWsamfs/mcf` file. The Sun SAM-Remote daemon and pseudo-devices are associated with one particular server.

The Sun SAM-Remote daemon supports an unlimited number of pseudo-devices for each client. The actual number of pseudo-devices to be used by the client is configurable. When determining how many pseudo-devices should be configured per client, think of these devices as the number of simultaneous data transfers that can occur between the client and the server. As more pseudo-devices are defined, the possibility of increasing the total network traffic load increases. It is up to you, the system administrator, to determine the actual number of pseudo-devices needed for the system.

#### Interaction Between the Sun SAM-Remote Server and the Sun SAM-Remote Client

The Sun SAM-Remote server daemon, `sam-serverd`, listens for the clients on port 1000. You can configure a different port in the Sun Solaris `/etc/services` directory with a service name of `rmtsam`. When a Sun SAM-Remote client connects to the Sun SAM-Remote server, the `sam-serverd` daemon establishes a connection on another port and communicates this port number to that client, using the defined port. The socket size is passed to the client. The socket size is configurable and is described in more detail in the Configuring the Sun SAM-Remote Software.

#### Library Catalogs

The Sun SAM-Remote library catalog is a subset of the catalog located on the Sun SAM-Remote server. The client catalog is updated in real time. The slots allotted to a Sun SAM-Remote client catalog are controlled only by the Sun SAM-Remote server.

Upon initialization, the system builds a client catalog and passes it to the Sun SAM-Remote client based on information from the Sun SAM-Remote server catalog file. After the connection between the host and client is established, media available to the client is flagged as available. If the connection between the client and server is lost, the media on the client side is flagged as unavailable. You can view the media availability through the `samu`(1M) `v` display. The information that appears in the `samu`(1M) `v` display on the client is a subset of that which appears in the `v` display on the server. It is therefore a good idea to access the media catalog through the `samu`(1M) `v` display on Sun SAM-Remote server. For more information about the Sun SAM-Remote server client file, see Configuring the Sun SAM-Remote Software. For information on using the `samu`(1M) operator utility, see the Sun StorEdge QFS Configuration and Administration Guide.

Changes to the catalog are passed between hosts as necessary. Any changes in the server catalog that involve a media type associated with a client are passed to the client, and the client catalog is updated.

#### Archiving

Sun SAM-Remote archive processing is the same as Sun StorEdge SAM-FS archive processing. The Sun SAM-Remote client makes a mount request to be added to the server's mount request table. The client then waits for the server to respond with a message indicating that the media is mounted. Archiving begins when the media is available.

##

Configuring the Sun SAM-Remote Software

This section explains how to perform an initial configuration of the Sun SAM-Remote server and client software. It includes the following sections:

- Example Configuration

- Configuring the Software

### Example Configuration

FIGURE 7-3 depicts the sample configuration used in this chapter's procedures. The examples in this chapter show how to configure a Sun SAM-Remote server called `chicago`.

FIGURE 7-3 Example Sun SAM-Remote Configuration

The Sun StorEdge SAM-FS file systems on `portland` and `sacramento` use `chicago` as their Sun SAM-Remote server.

### Configuring the Software

The following procedures explain how to configure the Sun SAM-Remote software on a Sun SAM-Remote server and on one or more Sun SAM-Remote clients. These procedures must be performed in the order described in the following sections:

1. To Log In to the Potential Server and Client Hosts

2. To Verify Client and Server Configurations

3. To Edit the mcf Files

4. To Define a Sun SAM-Remote Client

5. To Define a Sun SAM-Remote Server in the Server's mcf File

6. To Create the Sun SAM-Remote Server Configuration File

7. To Enable Archiving

To Log In to the Potential Server and Client Hosts

Follow these steps for the potential server and all potential client hosts.

1. Log in to the Sun SAM-Remote server as the superuser.

You must have superuser access to the server system on which the Sun Sun SAM-Remote software is to be installed.

2. Log in to the Sun SAM-Remote clients as the superuser.

You must have superuser access to the client system or systems on which the Sun SAM-Remote software is to be installed.

To Verify Client and Server Configurations

To ensure that you have the required software levels installed, follow these steps on each system to be configured as part of a Sun SAM-Remote environment.

1. Issue the `pkginfo`(1M) command with its `-l` option, and examine the output.

CODE EXAMPLE 7-1 shows sample output from the `pkginfo`(1M) command.

CODE EXAMPLE 7-1 Using `pkginfo` (1)
    portland# pkginfo -l SUNWsamfs
       PKGINST:  SUNWsamfs
          NAME:  Sun SAM-FS and Sun SAM-QFS software Solaris 2.8
      CATEGORY:  system
          ARCH:  sparc
       VERSION:  4.0.5,REV=5.8.2003.01.12
        VENDOR:  Sun Microsystems, Inc.
        PSTAMP:  boomerang-20020712183351
      INSTDATE:  Jan 20 2003 07:30
       HOTLINE:  Please contact your local service provider
        STATUS:  completely installed
         FILES:    489 installed pathnames
                    12 shared pathnames
                     1 linked files
                    51 directories
                   179 executables
                 35813 blocks used (approx)
    portland#

You must have the same release and revision level of Sun StorEdge SAM-FS software level installed on all client and server hosts to be configured as part of a Sun SAM-Remote environment.

In the example output shown in CODE EXAMPLE 7-1, you can see that the server is running software version 4U0.5, and any systems included in an environment with this server would also have to be running 4U0.5.

2. Issue the `showrev`(1M) command with its `-p` option, and examine the output.

CODE EXAMPLE 7-2 shows sample output from the `showrev`(1M) command.

CODE EXAMPLE 7-2 Using `showrev` (1M)
    portland# showrev -p | grep SUNWsamfs
    Patch: 113546-07 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWsamfs
    portland#

You must have the same patch collection installed on all client and server hosts to be configured as part of the Sun SAM-Remote environment.

In the example output shown in CODE EXAMPLE 7-2, you can see that the server is running patch 113546-07, and any systems included in an environment with this server would also have to be running patch 113546-07.

If the information from the `pkginfo`(1) command reveals that all systems to be included in the Sun SAM-Remote environment are running the same software release level and same patch level, you do not need to do anything.

In contrast, some systems are running earlier versions of the software or patches, you must upgrade all systems to the latest software levels. Using CODE EXAMPLE 7-1 as an example, if you are running a Sun StorEdge SAM-FS version earlier than version 4U0.5 on any system, you must upgrade to at least 4U0.5.

For information about performing software upgrades, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.

To Edit the `mcf` Files

1. From the Sun SAM-Remote server, stop the Sun StorEdge SAM-FS functions.

a. Issue the `samcmd`(1M) command with its `idle` eq option to idle each removable media drive under the control of the Sun StorEdge SAM-FS software.

    # samcmd idle eq

For eq, specify the equipment ordinal of the removable media drive being addressed, as defined in the `mcf` file.

For more information about the `samcmd`(1M) command, see the `samcmd`(1M) man page.

Alternatively, you can also idle the drives by using the `samu`(1M) operator utility. For information on using the `samu`(1M) operator utility, see the Sun StorEdge QFS Configuration and Administration Guide.

Note - The drives in your Sun StorEdge SAM-FS environment should be idled before you issue the `samd stop` command. This enables the archiver, stager, and other processes to complete current tasks. This also enables the cartridges to be unloaded and put into their storage slots.

b. Issue the `samd`(1M) command with its `stop` option to stop the `sam-amld` daemon and its child processes.

    # samd stop

The `samd`(1M) command is installed in `/opt/SUNWsamfs/sbin`.

2. On each client, use `vi`(1) or another editor to edit the existing Sun StorEdge SAM-FS `/etc/opt/SUNWsamfs/mcf` file.

The goal of this step is to define the host as a Sun SAM-Remote client. CODE EXAMPLE 7-3 shows the edited `mcf` file on client `portland`. The `mcf` file defines a file system and shows the Sun SAM-Remote client `portland` being defined to the Sun SAM-Remote server `chicago`.

In this chapter's example, the same configuration process must be completed for client `sacramento`. For this system, edit the `mcf` file and copy the last set of lines from `portland`'s `mcf` file to `sacramento`'s `mcf` file. These are the lines that define the host to `chicago` as a Sun SAM-Remote client.

CODE EXAMPLE 7-3 `mcf` File on `portland`
    # mcf file on portland
    #
    # Sun StorEdge QFS file system
    #
    # Equipment             Eq   Eq  Family    Dev  Additional
    # Identifier            Ord  Ty  Set        St  Parameters
    # ==========            ===  ==  ======     ==  ==========
    samfs1                    1  ms  samfs1     on
    /dev/dsk/c1t1d0s0        10  md  samfs1     on  /dev/rdsk/c1t1d0s0
    /dev/dsk/c1t2d0s0        12  md  samfs1     on  /dev/rdsk/c1t2d0s0
    #
    # Define Sun SAM-Remote Client portland to Sun SAM-Remote server chicago
    #
    /etc/opt/SUNWsamfs/rmt200 200  sc chicagoss on /var/opt/SUNWsamfs/catalog/tcat
    /dev/samrd/rd0            201  rd chicagoss on
    /dev/samrd/rd1            202  rd chicagoss on

The `mcf` entry on the client consists of a single-line entry for the Sun SAM-Remote client and a pseudo-device entry for each device you want to configure. These entries follow the syntax as defined in the `mcf`(4) man page.

The first set of entries defines a Sun StorEdge QFS file system.

The second set of entries defines the Sun SAM-Remote client, `portland`, to the Sun SAM-Remote server, `chicago`. The first line defines the Sun SAM-Remote server itself, as described below.

- Equipment identifier, consisting of the path name of the client configuration file, which is created later in To Define a Sun SAM-Remote Client.

- Equipment ordinal, consisting of a unique number from 1 through 65535.

- Equipment type, consisting of a two-letter mnemonic that identifies a Sun SAM-Remote client.

- Family set, consisting of the family set name of the daemon to be used on this particular server. A Sun SAM-Remote server can have one server daemon per client.

- Device state, either on or off.

- Additional parameters, an optional field consisting here of the path to the catalog file.

The last two entries in this `mcf` file define the Sun SAM-Remote pseudo-devices, as indicated by the `rd` equipment type. A pseudo-device defines a network connection to an actual device on the Sun SAM-Remote server. Pseudo-device entries are created when the system is rebooted. You can define an unlimited number of pseudo-devices.

To Define a Sun SAM-Remote Client

The Sun SAM-Remote client's configuration file contains a single-line entry consisting of the name of the Sun SAM-Remote server. As shown in To Edit the mcf Files in Step 2, the full path name of this client configuration file is specified in the client's `mcf` file.

1. On each client, use `vi`(1) or another editor to open a file to be known as the Sun SAM-Remote client configuration file.

For example:

    portland# vi /etc/opt/SUNWsamfs/rmt200

2. Edit the file and include only the name of the Sun SAM-Remote server.

CODE EXAMPLE 7-4 shows the client configuration file on `portland` after you have edited it. It points to the Sun SAM-Remote server called `chicago`.

CODE EXAMPLE 7-4 Client Configuration File
    portland# cat /etc/opt/SUNWsamfs/rmt200
    chicago

To Define a Sun SAM-Remote Server in the Server's `mcf` File

Note - You must have at least one Sun StorEdge SAM-FS file system configured in the `mcf` file for the Sun SAM-Remote server.

On the Sun SAM-Remote server, use `vi`(1) or another editor to edit the existing Sun StorEdge SAM-FS `/etc/opt/SUNWsamfs/mcf` file.

Suppose you edit the `mcf` file on server `chicago`. The resulting file defines a Sun StorEdge QFS file system and also defines `chicago` as a Sun SAM-Remote server.

CODE EXAMPLE 7-5 shows the `mcf` file on `chicago`.

CODE EXAMPLE 7-5 `mcf` File on `chicago`
    # mcf file on Sun SAM-Remote server chicago:
    # Eq Identifier Eq Ord  Eq Typ Fam Set Dev St  Addl Params
    #
    samfs1               1   ms    samfs1  on
    /dev/dsk/c2t6d0s0   11   md    samfs1  on  /dev/rdsk/c2t6d0s0
    /dev/dsk/c2t6d0s1   12   md    samfs1  on  /dev/rdsk/c2t6d0s1
    #
    # define a tape library that client portland can use:
    /dev/samst/c0t3u0  100   rb    rb100   on  /var/opt/SUNWsamfs/catalog/rb100.cat
    /dev/rmt/0cbn      101   tp    rb100   on
    /dev/rmt/1cbn      102   tp    rb100   on
    # Define Sun SAM-Remote server chicago
    #
    /etc/opt/SUNWsamfs/rmt200 50  ss      chicagoss  on

The syntax of entries is described in To Edit the mcf Files.

To Create the Sun SAM-Remote Server Configuration File

The Sun SAM-Remote server configuration file defines the disk buffer characteristics and media to be used for each client. Ten clients can be configured per server daemon. If you want to support more clients, you must configure another Sun SAM-Remote server daemon as described previously in To Edit the mcf Files (Step 2) and in To Define a Sun SAM-Remote Client.

1. On the server, use `vi`(1) or another editor to open a file to be known as the Sun SAM-Remote server configuration file.

2. Write the server configuration file.

CODE EXAMPLE 7-6 shows an example server configuration file, `/etc/opt/SUNWsamfs/rmt200`, which resides on Sun SAM-Remote server `chicago`. This file defines clients `portland` and `sacramento`.

CODE EXAMPLE 7-6 Server Configuration File `rmt200`
    #
    # Sun SAM-Remote server config file /etc/opt/SUNWsamfs/rmt200
    #
    portland
         media
         100  at  (000031|000032|000034|000035|000037|000038)
         endmedia
    #
    sacramento
         media
         100 at  (000131|000132|000134|000135|000137|000138)
         endmedia

As CODE EXAMPLE 7-7 shows, a server configuration file consists of multiline entries for each client. A pound character (`#`) indicates a comment line. Anything to the right of a comment line is ignored.

CODE EXAMPLE 7-7 shows the format for a Sun SAM-Remote server configuration file.

CODE EXAMPLE 7-7 Server Configuration File Format
    client_name
         [ parameter1 ]
         media
              eq media_type regex
              [ eq media_type regex ]
              [. . .]
         endmedia

The following steps show how to write the server configuration file.

a. Write the client_name field.

The client_name defines the network name for each client to be served by this invocation of the Sun SAM-Remote daemon. The first character in the client_name must be the first character in the line. The client_name can be specified as either the network name, an IP address, or a fully qualified domain name.

The parameter (if specified) and media specifications following a client_name, and up to the next client definition, are specific to this client. The parameter and media definitions must be indented with white space or tab characters.

b. (Optional) Write the parameter field.

The parameter line is expressed in a keyword `=` value pair. You can use the parameter field to specify the network block size. The `net_block_size` parameter specifies the network block size to be used by this client's socket, in kilobytes. The format for this parameter is as follows:

    net_blk_size=size

For size, specify an integer from 4 size 64. The default is 4, which specifies 4096 bytes.

The parameter line must be indented with white space or tab characters

c. Write the `media` and `endmedia` keyword fields.

The `media` and `endmedia` keywords are required in the server configuration file. They define the media archive volumes that a client can use. These media associations are specified as follows:

CODE EXAMPLE 7-8 The Media Specification in the Server Configuration File
         media
              eq media_type (regex)
              [ eq media_type (regex) ]
              [. . .]
         endmedia

The `media` and `endmedia` keywords delimit the media definition area of the Sun SAM-Remote server configuration file. The eq`` media_type`` regex lines are the media definition lines. The media definitions must be indented with white space or tab characters. The regex data must be enclosed by parentheses.

The elements of the media type specification are as follows:

Argument | Definition
--- | ---
eq | The equipment ordinal of a library. Network attached libraries with mixed media can have more than one eq`` media-type`` regex line, so specify a different eq`` media-type`` regex line for each media type.
media-type | The two-character specific media type, such as it. The generic media type specifications that are valid in the `mcf` file are not valid for the media_type specification. For information about valid media types, see the `mcf`(4) man page. Specify more than one media definition line if you have a network attached library with more than one media type. For example, the following is a valid media type definition: `media 100 lt (VSN1) 100 lt (VSN2) endmedia`
regex | The volume serial names (VSNs) of the cartridges to which the files will be archived. Each VSN specified must be expressed as an extended regular expression and the VSNs must be enclosed by parentheses. For information about extended regular expressions, see the `egrep`(1) man page. For information about regular expressions, see the `regcomp`(3C) man page.

Note - Do not allow the same physical media cartridges to be used by more than one client. In addition, if the Sun SAM-Remote server has its own file system outside of the Sun SAM-Remote environment, it is not recommended that a cartridge be used by both the client and the server.

To Enable Archiving

The following steps enable archiving and complete the configuration process.

1. Verify the `archiver.cmd` file on the client.

Depending on your configuration, you might need to perform the following tasks:

- Make sure that the VSNs defined in the server configuration file are assigned to the correct archive sets in the `archiver.cmd` file.

- Remove the following directives from the `archiver.cmd` file on the Sun SAM-Remote client if these directives apply to archive sets to be archived to the library connected to the Sun SAM-Remote server:

- `-tapenonstop`

- `-offline_copy direct`

2. Issue the `samd`(1M) command with its `start` option to start the Sun StorEdge SAM-FS processes on the server and on the clients.

To ensure that the new configuration files on the server and clients are read, you must start or restart your Sun StorEdge SAM-FS software.

Enter the following command on the clients and the server:

    server# samd start

For more complete instructions about starting and restarting Sun StorEdge SAM-FS, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.

3. Invoke `samu`(1M) on the server and the clients.

The goal of this step is to verify the connection between hosts. Use the `samu`(1M) utility's `s` and `R` displays to show the status of Sun SAM-Remote connections. For more information on `samu`(1M), see the `samu`(1M) man page or see the Sun StorEdge QFS Configuration and Administration Guide.

CODE EXAMPLE 7-9 shows the `samu`(1M) status `s` display on the Sun SAM-Remote client `portland`. Note the device type `sc`, which represents the Sun SAM-Remote client. The message below that line indicates that a connection with the server `chicago` has been established.

CODE EXAMPLE 7-9 Client `samu` (1M) `s` Display
    Device status                 samu   4.0.5 Wed May 02 14:44:44
    License: License never expires.
    ty     eq state   device_name                        fs status   pos
    ms      1 on      samfs1                              1 m---------
    md     10 on      /dev/dsk/c1t1d0s0                   1 ----------
    md     12 on      /dev/dsk/c1t2d0s0                   1 ----------
    s9     35 on      /dev/samst/c0t5u0                  35 m--------r
            move complete
    lt     36 on      /dev/rmt/0cbn                      35 ---------p
            empty
    lt     37 on      /dev/rmt/1cbn                      35 ---------p
            empty
    lt     38 on      /dev/rmt/2cbn                      35 --l------r
            idle
    lt     39 on      /dev/rmt/3cbn                      35 --l------r
            idle
    sc    200 on      /etc/opt/SUNWsamfs/rmt200         200 ---------r
            server chicago connected
    rd    201 on      /dev/samrd/rd0                    200 ---------r
    rd    202 on      /dev/samrd/rd1                    200 ---------r
    hy    203 on      historian                         203 ----------

CODE EXAMPLE 7-10 shows the `samu`(1M) status `s` display on the Sun SAM-Remote server `chicago`. Note the device type `ss`, which represents the Sun SAM-Remote server. This display indicates that this system is a Sun SAM-Remote server.

CODE EXAMPLE 7-10 Server `samu` (1M) `s` Display on `chicago`
    Device status                    samu   4.0.5 Tue Apr 24 14:49:43
    License: License never expires.
    ty     eq state   device_name                        fs status   pos
    ms      1 on      samfs1                              1 m---------
    md     11 on      /dev/dsk/c2t6d0s0                   1 ----------
    md     12 on      /dev/dsk/c2t6d0s1                   1 ----------
    ss     50 on      /etc/opt/SUNWsamfs/rmt200          50 ---------r
    sl    100 on      /dev/samst/c0t3u0                 100 m--------r
    at    101 on      /dev/rmt/0cbn                     100 ---------p
            initializing
    at    102 on      /dev/rmt/1cbn                     100 ---------p
            initializing
    hy    103 on      historian                         103 ----------

CODE EXAMPLE 7-11 shows the `samu`(1M) Sun SAM-Remote `R` display from the Sun SAM-Remote server `chicago`.

CODE EXAMPLE 7-11 Server `samu` (1M) `R` Display on `chicago`
    Remote server eq: 50             addr: 00001ca0 4.0.5 Wed May 02 14:55:37
    message:
    Client: portland
    client index - 0
    network block size - 4096
    max file size - 0                       flags  - c0000000
    min file size - 8

If you have multiple Sun SAM-Remote clients, you can scroll through the clients by pressing the `CONTROL-f` key sequence.

In CODE EXAMPLE 7-11, the connected client is named `portland`. The `client index` field indicates that this client is the zero of a possible 0 through 9 clients defined for this server daemon. The maximum file size, minimum file size, and network block size are listed in bytes. Flags indicate the state of the connection, as shown in TABLE 7-1:

TABLE 7-1 The `samu` (1M) `R` Display Flags
Flag | Meaning
--- | ---
`0x00000000` | No connection.
`0xc0000000` | A connection has been established.

4. From the server, use the `samu`(1M) utility's v display to ensure that the catalog is available on the clients.

For each client, you should be able to view the available Sun SAM-Remote catalog. From `samu`(1M), enter the following:

    :v eq

For eq, specify the equipment ordinal of the Sun SAM-Remote client daemon as defined in the `mcf` file.

CODE EXAMPLE 7-12 shows a `samu`(1M) display from `chicago` indicating the volumes that `portland` can access.

CODE EXAMPLE 7-12 Available Volumes As Viewed From `chicago`
    Robot VSN catalog by slot : eq 200 samu 4.0.5 Wed May 02 15:24:13
    count 32
    slot     access      time  count use flags         ty vsn
       1     2003/01/02  10:40    0   0% -il-o-b-R-U-  at 000032
       2     2003/01/02  11:41    0   0% -il-o-b-R---  at 000034
       3     2003/01/02  12:42  170  91% -il-o-b-----  at 000035
       4     2003/01/02  13:43   20   7% -il-o-b-----  at 000037
       5     2003/01/02  14:44    0   0% -il-o-b-----  at 000038
       6     2003/01/02  13:41    0   0% -il-o-b-----  at 000031

5. From each client, issue the `archiver`(1M) command and its `-A` option.

In this step, you verify that archiving is taking place from the client to the server. This command enables a listing to be written from the archiver, including the VSNs from the server. For information about this command, see the `archiver`(1M) man page.

If files are not archiving, see the Sun StorEdge SAM-FS Troubleshooting Guide.

##

Recycling With the Sun SAM-Remote Software

This section contains information about recycling with Sun SAM-Remote. Sun Microsystems recommends recycling in a Sun SAM-Remote environment only under the very specific circumstances described here.

Because the recycling process involves freeing space on cartridges for more data, it is possible for the recycler to destroy important data on archive cartridges if the recycling process is not configured properly.

Note - These restrictions are not enforced by the Sun StorEdge SAM-FS software.

To avoid data loss, it is essential that you adhere to the following restrictions:

- Before using the recycler in a Sun SAM-Remote environment you must have a complete understanding of each step of the recycler. Executing commands in the wrong order, or on the wrong system, can result in an irreversible loss of data. Make sure you have analyzed a command's actions before executing any command, such as `tplabel`(1M), that can delete data on the Sun SAM-Remote client or the Sun SAM-Remote server.

- Recycling activities on the Sun SAM-Remote server and the Sun SAM-Remote client must not overlap. The result could be accidental relabeling of cartridges and irreversible loss of data.

- You must not recycle cartridges that contain removable media files.

- In a Sun SAM-Remote client and server environment, the client and server are unaware of each other's file systems, data files, and inode files. Therefore, the server and the client each must have exclusive use of a certain set of cartridges. Neither should ever use the other's cartridges.

You can prevent accidental recycling of VSNs used by Sun SAM-Remote clients by creating a `no_recycle` list in the Sun SAM-Remote server's `/etc/opt/SUNWsamfs/``recycler.cmd` file. However, be careful of using the `chmed`(1M) command's `+c` option on volumes in a `no_recycle` list. When you use this command to set the recycling flag (`+c`) on a volume, that action overrides the `no_recycle` list in the `/etc/opt/SUNWsamfs/recycler.cmd` file.

- You must not attempt to recycle volumes on the Sun SAM-Remote server and Sun SAM-Remote client on the same day.

Recycling in a Sun SAM-Remote environment should occur only if the following conditions are present:

- Each VSN in the system is used by one client system or by the server. There cannot be files from multiple systems on any VSN.

- No Sun SAM-Remote client has catalog entries for any VSNs other than those VSNs containing that client's archive images. The regex values in the server configuration file's media definition lines (the eq`` media-type`` regex lines) must agree with the volumes specified in the client catalog. In addition, the regex specifications in the client catalogs cannot specify the same volumes.

- The archiving is performed on an archive set basis. When you are using Sun SAM-Remote, recycling must be performed by archive set, not by library.

The following subsections describe two methods for enabling recycling using a Sun SAM-Remote client and server. The methods are as follows:

- Recycling in a Sun SAM-Remote Environment--Method 1

- Recycling in a Sun SAM-Remote Environment--Method 2

### Recycling in a Sun SAM-Remote Environment--Method 1

The procedures in this section describe one method for enabling recycling in a Sun SAM-Remote environment in which the server is named `sky` and the client is named `zeke`.

| Caution - Use the recycler in a Sun SAM-Remote environment only after following the steps in this procedure completely and only after testing your configuration to verify that recycling is taking place correctly.

#### Configuration Files for Server `sky`

The server must have Sun SAM-Remote configuration information in its `mcf` file and in its server configuration file. The following code examples show these files.

CODE EXAMPLE 7-13 shows the `mcf` file on server `sky`.

CODE EXAMPLE 7-13 The `mcf` File on Server `sky`
    # This is the mcf file for the server (sky).
    # The server parameters file (rmt1000) points
    #    back to the correct automated library's equipment number
    #    (70) for the ADIC Scalar 1000.
    #
    samfs1               100   ma   samfs1   on
    /dev/dsk/c0t0d0s5    110   mm   samfs1   on   /dev/rdsk/c0t0d0s5
    /dev/dsk/c3t2d0s3    120   mr   samfs1   on   /dev/rdsk/c3t2d0s3
    /dev/dsk/c3t2d0s4    121   mr   samfs1   on   /dev/rdsk/c3t2d0s4
    samfs2               139   ma   samfs2   on
    /dev/dsk/c3t4d0s3    140   mm   samfs2   on   /dev/rdsk/c3t4d0s3
    /dev/dsk/c3t4d0s4    141   mr   samfs2   on   /dev/rdsk/c3t4d0s4
    # ADIC Scalar 1000
    /dev/samst/c0t0u0 70 rb adic1 - /var/opt/SUNWsamfs/catalog/adic1
    /dev/rmt/0bn         71    at   adic1    on
    /dev/rmt/1bn         72    at   adic1    on
    /dev/rmt/2bn         73    at   adic1    on
    /dev/rmt/3bn         74    at   adic1    on
    /dev/rmt/4bn         75    at   adic1    on
    /dev/rmt/5bn         76    at   adic1    on
    /dev/rmt/11bn        77    at   adic1    on
    /dev/rmt/10bn        78    at   adic1    on
    /dev/rmt/9bn         79    at   adic1    on
    /dev/rmt/8bn         80    at   adic1    on
    /dev/rmt/7bn         81    at   adic1    on
    /dev/rmt/6bn         82    at   adic1    on
    # Define Sun SAM-Remote server skyrs
    /etc/opt/SUNWsamfs/rmt1000   1000   ss   skyrs   on

CODE EXAMPLE 7-14 shows the server configuration file on server `sky`.

CODE EXAMPLE 7-14 The Server Configuration File on Server `sky`
    # Server configuration file /etc/opt/SUNWsamfs/rmt1000 on sky.
    # The eq of the automated library MUST match the eq of the
    #   automated library that you want to use in the mcf file.
    zeke
       media
       70 at 00002[0-9]
       endmedia

#### Configuration Files for Client `zeke`

The client must have Sun SAM-Remote configuration information in its `mcf` file and in its client configuration file. The following code examples show these files.

CODE EXAMPLE 7-15 shows the `mcf` file on client `zeke`.

CODE EXAMPLE 7-15 The `mcf` File on Client `zeke`
    # mcf file for client (zeke)
    #
    samfs1                  10  ms  samfs1   on
    /dev/dsk/c1t3d0s0       11  md  samfs1   on   /dev/rdsk/c1t3d0s0
    /dev/dsk/c1t3d0s1       12  md  samfs1   on   /dev/rdsk/c1t3d0s1
    /dev/dsk/c1t3d0s3       13  md  samfs1   on   /dev/rdsk/c1t3d0s3
    # Define a StorageTek L20 with 1 drive and 20 slots (including cap)
    /dev/samst/c0t2u0       50  rb  stk_l20  on /var/opt/SUNWsamfs/catalog/L20_cat
    /dev/rmt/0hbn           51  lt  stk_l20  on
    # Define zeke as a Sun SAM-Remote client using sky as the server
    /etc/opt/SUNWsamfs/sky 200  sc  skyrs    on  /var/opt/SUNWsamfs/catalog/sky_cat
    /dev/samrd/rd0         201  rd  skyrs    on
    /dev/samrd/rd1         202  rd  skyrs    on
    /dev/samrd/rd2         203  rd  skyrs    on
    /dev/samrd/rd3         204  rd  skyrs    on

CODE EXAMPLE 7-16 shows the client configuration file on client `zeke`.

CODE EXAMPLE 7-16 The Client Configuration File on Client `zeke`
    # cat /etc/opt/SUNWsamfs/sky
    # File /etc/opt/SUNWsamfs/sky on Sun SAM-Remote client zeke:
    sky

To Configure Recycling--Method 1

The procedure for configuring the recycling process includes a test for archiving and recycling. Because of the testing period, this procedure can take a day or two to complete, depending on how frequently files are archived and recycled.

Note - Do not use the `chmed`(1M) command on the server to set the recycling flag (`+c`) for a client VSN. That action overrides the `no_recycle` list in the `/etc/opt/SUNWsamfs/recycler.cmd` file on the server.

1. Read about the recycler in Chapter 6.

Using the recycler in a Sun SAM-Remote environment requires a complete understanding of the steps in the recycling process. If you have not already familiarized yourself with the recycling process, take time now.

2. Make sure that the Sun SAM-Remote client and server are configured properly and that archiving is occurring.

For more information on configuring and verifying your Sun SAM-Remote environment, see Configuring the Sun SAM-Remote Software, which contains detailed information about configuring the Sun SAM-Remote client and server. That procedure includes steps for ensuring that archiving is taking place.

3. Edit the `archiver.cmd` file on the client system and add recycling directives.

In this example, the recycling is performed by archive set, not by library. The directives specifying that recycling be done by archive set must appear in the `archiver.cmd` file.

CODE EXAMPLE 7-17 shows the `archiver.cmd` file on client `zeke`. This file has been edited to communicate with the recycler.

CODE EXAMPLE 7-17 The `archiver.cmd` File on Client `zeke`
    # This is file /etc/opt/SUNWsamfs/archiver.cmd
    #   on Sun SAM-Remote client zeke.
    #
    # wait
    logfile = /var/opt/SUNWsamfs/archiver/archiver.log
    trace = /var/opt/SUNWsamfs/trace/archiver all
    interval = 1m
    no_archive tmp
    no_archive .
    archmax = lt 2G
    archmax = at 5G
    drives = skyrs 4 # use up to four drives for remote archiving.
    fs = samfs1
         1 4h
    archiveset testdir0
         1 1m
         2 1m
    defaultset .
         1 1m
         2 1m
    params
    # Start with mingain high to reduce workload.
    # If you need more recycling, reduce mingain.
    # If too much recycling, increase High Water Mark.
    archiveset.1 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    archiveset.1 -recycle_ignore
    defaultset.1 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    defaultset.1 -recycle_ignore
    # Remote directives.
    # Use up to three drives per archive set.
    # Load will split to two drives at 100m, to three drives at 150m.
    archiveset.2 -drives 3 -drivemin 50m
    defaultset.2 -drives 3 -drivemin 50m
    # Remote directives.
    # Start with mingain high to reduce workload.
    # If you need more recycling, reduce mingain.
    # If too much recycling, increase High Water Mark.
    archiveset.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    archiveset.2 -recycle_ignore
    defaultset.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    defaultset.2 -recycle_ignore
    endparams
    vsns
    samfs1.1     lt 000173      # local copy.
    archiveset.1 lt ^CEL        # local copy.
    archiveset.2 at 00002[0-4]  # remote copy, sky ait-2
                                # tapes 20 through 24.
    defaultset.1 lt ^CSM        # local copy.
    defaultset.2 at 00002[5-9]  # remote copy, sky ait-2
                                # tapes 25 through 29.
    endvsns

The directives shown in CODE EXAMPLE 7-17 do the following:

- The `-recycle_hwm` directive sets the library's high water mark for the archive set. When the utilization of the VSNs exceeds this percentage, recycling of the archive set begins.

- The `-recycle_ignore` directive is inserted only temporarily. This directive prevents recycling from occurring until you have configured and tested your environment. You can remove this directive in a later step.

- The `-recycle_mingain` directive is set high to ensure efficiency by limiting the amount of work needed to regain space.

- The `-recycle_vsncount` `1` directive specifies that the recycler drain one VSN at a time. When the first VSN is drained, a second is selected to begin draining. At any given moment, there is one VSN in the queue to be relabeled and one VSN in the queue to be drained. As a result, recycling does not overwhelm the system.

4. Edit the `recycler.cmd` file on the client and specify a log file to receive recycling log output.

CODE EXAMPLE 7-18 shows the `recycler.cmd` file on client `zeke`, which has been edited to specify a recycler log file.

CODE EXAMPLE 7-18 The `recycler.cmd` File on Client `zeke`
    #
    # This is the /etc/opt/SUNWsamfs/recycler.cmd file
    # on client zeke.
    #
    logfile = /var/opt/SUNWsamfs/log/recycler

5. Verify that the `archiver.cmd` file on the server is written to specify recycling by archive set.

When using Sun SAM-Remote, you must specify that recycling be performed on an archive set basis, not by library. The directives specifying that recycling be done by archive set must appear in the `archiver.cmd` file.

CODE EXAMPLE 7-19 shows the `archiver.cmd` file on server `sky`. This file specifies archiving by archive set.

CODE EXAMPLE 7-19 The `archiver.cmd` File on Server `sky`
    # This is the archiver.cmd for the server (sky).
    #
    # Number of drives: 10
    # Number of Mounted Filesystems: 1
    # Number of Tests per Filesystem: 1
    # Number of Archive Copies per Test: 2
    #wait
    #trace = /var/opt/SUNWsamfs/trace/archiver all
    logfile = /var/opt/SUNWsamfs/log/archiver
    interval = 1m
    no_archive .
    archmax = at 5G
    drives = adic1 6
    fs = samfs1
         1 4h
    testset testdir0
         1 1m
         2 1m
    allsam1   .
         1 1m
         2 1m
    params
    allsam1.1 -drives 4 -drivemin 50m
    allsam1.1 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    allsam1.1 -recycle_ignore
    allsam1.2 -drives 4 -drivemin 50m
    allsam1.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    allsam1.2 -recycle_ignore
    testset.1 -drives 4 -drivemin 50m
    testset.1 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    testset.1 -recycle_ignore
    testset.2 -drives 4 -drivemin 50m
    testset.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    testset.2 -recycle_ignore
    endparams
    vsns
    samfs1.1 at 000000
    allsam1.1 at 00000[1-5]    # vsns 1 through 5.
    allsam1.2 at 00000[6-9]    # vsns 6 through 9.
    testset.1 at 00001[0,4]    # vsns 10 and 14.
    testset.2 at 00001[5,9]    # vsns 15 and 19.
    endvsns

6. Edit the `recycler.cmd` file on the server.

Modify the file to specify the following items:

- A recycler log file to receive output from the recycler.

- A `no_recycle` directive for the Sun SAM-Remote client's VSNs. The Sun SAM-Remote client is configured to write its copy 2 archive copies to cartridges in the Sun SAM-Remote server's library. The `no_recycle` directive is necessary to prevent the VSNs being used by the Sun SAM-Remote client for archiving from being recycled by the Sun SAM-Remote server.

CODE EXAMPLE 7-20 shows the `recycler.cmd` file on server `sky`, which has been edited to specify a recycler log file.

CODE EXAMPLE 7-20 The `recycler.cmd` File on Server `sky`
    #
    # This is the /etc/opt/SUNWsamfs/recycler.cmd file
    # on Sun SAM-Remote server sky.
    #
    logfile = /var/opt/SUNWsamfs/recycler/recycler.log
    adic1 -ignore
    no_recycle at 00002[0-9] # Prevents VSNs assigned to zeke from
                             # being recycled.

7. Use the `sam-recycler`(1M) command to test the recycler on the Sun SAM-Remote client.

Run the recycler on the Sun SAM-Remote client system. This is a test to see if the recycler properly acknowledges the devices and VSNs specified in the configuration files.

This testing is important, because if the recycler detects that the system on which it is running has no archive images on a particular VSN listed in any of that system's catalogs (including the historian catalog), the `recycler.sh` script can call for the cartridge to be labeled. Labeling a cartridge destroys all data on the cartridge. There is no communication between the Sun SAM-Remote client and the Sun StorEdge SAM-FS servers to inform each side of the presence of archive copies. All such information is provided locally from local Sun StorEdge SAM-FS file systems.

For example, you can use the following command to perform the initial test of the recycler:

    zeke# sam-recycler -dvx

The recycler runs and logs its activity to the recycler log file. The recycler log file is defined in the `recycler.cmd` file. For more information about the `sam-recycler`(1M) command, see the `sam-recycler`(1M) man page.

8. Examine the recycler log file.

You are looking for the following message:

    Recycling is ignored on this archive set.

CODE EXAMPLE 7-21 shows a sample log file.

CODE EXAMPLE 7-21 Recycler Log File on Client `zeke`
    # recycler.log from client zeke.
    ========== Recycler begins at Mon Jun  4 09:49:41 2001 ===========
    Initial 7 catalogs:
    0  Family: stk_l20              Path: /var/opt/SUNWsamfs/catalog/L20_cat
       Vendor: STK                  Product: L20
       SLOT                  ty    capacity         space vsn
          0                  lt        33.0G        33.0G 000173
          1                  lt        32.8G        44.1M CEL170
          2                  lt        33.0G        33.0G CEL139
          4                  lt        32.8G        16.8G CFC504
          5                  lt        33.0G        33.0G CFC503
          6                  lt        32.9G         0    CSM689
          7                  lt        32.9G        19.6G CSM690
          8                  lt        33.0G        33.0G CSM691
          9                  lt        33.0G        33.0G CSM692
         10                  lt        10.0G        10.0G CLN018
         11                  lt        33.0G        33.0G 000766
       Total Capacity:  339.2G bytes, Total Space Available: 244.3G bytes
       Volume utilization 27%, high 95% VSN_min 50%
       Recycling is ignored on this robot.
    1  Family: skyrs                Path: /var/opt/SUNWsamfs/catalog/sky_cat
       Vendor: (NULL)               Product: (NULL)
       SLOT                  ty    capacity         space vsn
          0                  at        48.5G        23.3G 000020
          1                  at        23.8G        23.8G 000021
          2                  at        48.5G        48.5G 000022
          3                  at        48.5G        48.5G 000023
          4                  at        48.5G        48.5G 000024
          5                  at        48.5G         2.6G 000025
          6                  at        48.5G       361.4k 000026
          7                  at        48.5G        48.5G 000027
          8                  at        48.5G        48.5G 000028
          9                  at        48.5G         0    000029
       Total Capacity:  460.8G bytes, Total Space Available: 292.5G bytes
       Volume utilization 36%, high 95% VSN_min 50%
       Recycling is ignored on this robot.
    2  Family: hy                   Path: /var/opt/SUNWsamfs/catalog/historian
       Vendor: Sun SAM-FS               Product: Historian
       SLOT                  ty    capacity         space vsn
          (no VSNs in this media changer)
       Total Capacity:  0    bytes, Total Space Available: 0    bytes
       Volume utilization 0%, high 95% VSN_min 50%
       Recycling is ignored on this robot.
    3  Family: defaultset.1         Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  lt        33.0G        33.0G 000766
          1                  lt        33.0G        33.0G 000173
          2                  lt        32.9G         0    CSM689
          3                  lt        32.9G        19.6G CSM690
          4                  lt        33.0G        33.0G CSM691
          5                  lt        33.0G        33.0G CSM692
       Total Capacity:  197.6G bytes, Total Space Available: 151.5G bytes
       Volume utilization 23%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    4  Family: defaultset.2         Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  lt        32.9G         0    CSM689
          1                  at        48.5G        23.3G 000020
          2                  at        23.8G        23.8G 000021
          3                  at        48.5G         2.6G 000025
          4                  at        48.5G       361.4k 000026
          5                  at        48.5G        48.5G 000027
          6                  at        48.5G        48.5G 000028
          7                  at        48.5G         0    000029
       Total Capacity:  348.0G bytes, Total Space Available: 146.8G bytes
       Volume utilization 57%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    5  Family: archiveset.1         Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  lt        32.8G        44.1M CEL170
          1                  lt        32.8G        16.8G CFC504
          2                  lt        33.0G        33.0G CFC503
       Total Capacity:  98.6G bytes, Total Space Available: 49.8G bytes
       Volume utilization 49%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    6  Family: archiveset.2         Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  at        48.5G        23.3G 000020
          1                  at        23.8G        23.8G 000021
          2                  at        48.5G        48.5G 000022
          3                  at        48.5G        48.5G 000023
          4                  at        48.5G        48.5G 000024
       Total Capacity:  218.0G bytes, Total Space Available: 192.8G bytes
       Volume utilization 11%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    21 VSNs:
                        ---Archives---   -----Percent-----   defaultset.1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    in multiple sets       0      0        0   100      0 stk_l20:lt:CSM689
    partially full       111      2.8G     8    31     61 stk_l20:lt:CSM690
    empty VSN              0      0        0     0    100 stk_l20:lt:000173
    empty VSN              0      0        0     0    100 stk_l20:lt:CSM691
    empty VSN              0      0        0     0    100 stk_l20:lt:CSM692
    empty VSN              0      0        0     0    100 stk_l20:lt:000766
                        ---Archives---   -----Percent-----   defaultset.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   skyrs:at:000029
    no-data VSN            0      0        0    99      1   skyrs:at:000026
    partially full       111      2.8G     6    88      6   skyrs:at:000025
    empty VSN              0      0        0     0    100   skyrs:at:000028
    empty VSN              0      0        0     0    100   skyrs:at:000027
                        ---Archives---   -----Percent-----   archiveset.1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0    99      1 stk_l20:lt:CEL170
    partially full       677      2.3G     8    40     52 stk_l20:lt:CFC504
    empty VSN              0      0        0     0    100 stk_l20:lt:CFC503
                        ---Archives---   -----Percent-----   archiveset.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    in multiple sets       0      0        0    51     49   skyrs:at:000020
    empty VSN              0      0        0     0    100   skyrs:at:000022
    empty VSN              0      0        0     0    100   skyrs:at:000023
    empty VSN              0      0        0     0    100   skyrs:at:000024
    in multiple sets       0      0        0     0    100   skyrs:at:000021
                        ---Archives---   -----Percent-----   stk_l20
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    empty VSN              0      0        0     0    100 stk_l20:lt:CLN018
    partially full        13     80.3k     0     0    100 stk_l20:lt:CEL139
    Recycler finished.
    ========== Recycler ends at Mon Jun  4 09:49:53 2001 ===========

9. Issue the `sam-recycler`(1M) command from the Sun SAM-Remote server to verify that the recycler is not recycling any VSNs reserved for the Sun SAM-Remote client.

For example:

    zeke# sam-recycler -dvx

The preceding command runs the recycler and writes its activity to the recycler log file. For more information about the `sam-recycler`(1M) command, see the `sam-recycler`(1M) man page.

CODE EXAMPLE 7-22 shows a sample recycler log file.

CODE EXAMPLE 7-22 The Recycler Log File
    # recycler.log file from server sky.
    ========== Recycler begins at Mon Jun  4 09:50:44 2001 ===========
    Initial 6 catalogs:
    0  Family: adic1            Path: /var/opt/SUNWsamfs/catalog/adic1
       Vendor: ADIC                 Product: Scalar 1000
       SLOT                  ty    capacity         space vsn
          0                  at         1.3G         1.2G 000001
          1                  at         1.3G         1.3G 000002
          2                  at         1.3G         1.3G 000004
          3                  at        48.5G         0    000010
          4                  at        48.5G         0    000011
          5                  at        48.5G        43.5G 000018
          6                  at        48.5G         0    000019
          7                  at        48.5G        23.3G 000020
          8                  at        23.8G        23.8G 000021
          9                  at        48.5G        48.5G 000022
         10                  at        48.5G        48.5G 000023
         11                  at        48.5G        48.5G 000024
         12                  at        48.5G         2.6G 000025
         13                  at        48.5G       361.4k 000026
         14                  at        48.5G        48.5G 000027
         15                  at        48.5G        48.5G 000028
         16                  at        48.5G         0    000029
         17                  at         1.3G         1.3G 000005
         18                  at        48.5G        48.5G 000016
         19                  at        23.8G        23.8G CLN001
         20                  at        23.8G        23.8G CLN002
         21                  at        23.8G        23.8G CLN004
         22                  at        23.8G        23.8G CLN003
         23                  at        48.5G       421.6M 000015
         24                  at         1.3G         1.3G 000000
         25                  at        48.5G         0    000013
         26                  at         1.3G         1.3G 000003
         27                  at        48.5G        43.6G 000007
         28                  at        48.5G        41.8G 000008
         29                  at        48.5G        46.9G 000006
         30                  at        48.5G        48.3G 000009
         31                  at        48.5G         0    000014
         32                  at        48.5G         0    000012
         33                  at        48.5G        40.1G 000017
       Total Capacity:  1.2T bytes, Total Space Available: 708.7G bytes
       Volume utilization 43%, high 95% VSN_min 50%
       Recycling is ignored on this robot.
    1  Family: hy                   Path: /var/opt/SUNWsamfs/catalog/historian
       Vendor: Sun SAM-FS               Product: Historian
       SLOT                  ty    capacity         space vsn
          (no VSNs in this media changer)
       Total Capacity:  0    bytes, Total Space Available: 0    bytes
       Volume utilization 0%, high 95% VSN_min 50%
       Recycling is ignored on this robot.
    2  Family: testset.1            Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  at        48.5G         0    000010
          1                  at        48.5G         0    000014
       Total Capacity:  97.1G bytes, Total Space Available: 0    bytes
       Volume utilization 100%, high 60% VSN_min 90%: *** Needs recycling ***
       Recycling is ignored on this archive set.
    3  Family: testset.2            Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
    SLOT                  ty    capacity         space vsn
          0                  at        48.5G         0    000019
          1                  at        48.5G       421.6M 000015
       Total Capacity:  97.1G bytes, Total Space Available: 421.6M bytes
       Volume utilization 99%, high 60% VSN_min 90%: *** Needs recycling ***
       Recycling is ignored on this archive set.
    4  Family: allsam1.1            Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  at         1.3G         1.2G 000001
          1                  at         1.3G         1.3G 000002
          2                  at         1.3G         1.3G 000004
          3                  at         1.3G         1.3G 000005
          4                  at         1.3G         1.3G 000003
       Total Capacity:  6.5G bytes, Total Space Available: 6.3G bytes
       Volume utilization 3%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    5  Family: allsam1.2            Path: /etc/opt/SUNWsamfs/archiver.cmd
       Vendor: Sun SAM-FS               Product: Archive set
       SLOT                  ty    capacity         space vsn
          0                  at        48.5G        43.6G 000007
          1                  at        48.5G        41.8G 000008
          2                  at        48.5G        46.9G 000006
          3                  at        48.5G        48.3G 000009
       Total Capacity:  194.2G bytes, Total Space Available: 180.6G bytes
       Volume utilization 6%, high 60% VSN_min 90%
       Recycling is ignored on this archive set.
    Need to select candidate for media changer testset.1 to free up 39.8G bytes.
    Quantity of data to move limited to (no limit) bytes and 1 VSNs.
    Checking 000010.  Need to free 39.8G, quantity limit: (no limit), VSN count: 1.
       VSN is in correct media changer... good.
       VSN is not already recycling... good.
       VSN has no request files... good.
       VSN has no `archive -n' files...good.
       VSN was not specified as "no_recycle" in recycler.cmd file... good.
       VSN does not exceed VSN count limit... good.
       VSN does not exceed data quantity limit... good.
       VSN meets minimum gain requirement.
       Recycling is ignored on this media changer - VSN not marked for recycling.
    Checking 000014.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN is in correct media changer... good.
       VSN is not already recycling... good.
       VSN has no request files... good.
       VSN has no `archive -n' files...good.
       VSN was not specified as "no_recycle" in recycler.cmd file... good.
       VSN exceeds VSN count limit - skipped.
    Checking 000019.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000015.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000001.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000003.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000004.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000005.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000002.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000008.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000007.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000006.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000009.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000011.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000029.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000013.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000012.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000026.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000025.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000020.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000017.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000018.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN003.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000021.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000022.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000027.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000028.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000023.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000024.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000016.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN001.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN002.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN004.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000000.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    No candidate was found in this media changer.
    Need to select candidate for media changer testset.2 to free up 38.8G bytes.
    Quantity of data to move limited to (no limit) bytes and 1 VSNs.
    Checking 000010.  Need to free 38.8G, quantity limit: (no limit), VSN count: 1.
       VSN not in correct media changer.
    Checking 000014.  Need to free 38.8G, quantity limit: (no limit), VSN count: 1.
       VSN not in correct media changer.
    Checking 000019.  Need to free 38.8G, quantity limit: (no limit), VSN count: 1.
       VSN is in correct media changer... good.
       VSN is not already recycling... good.
       VSN has no request files... good.
       VSN has no `archive -n' files...good.
       VSN was not specified as "no_recycle" in recycler.cmd file... good.
       VSN does not exceed VSN count limit... good.
       VSN does not exceed data quantity limit... good.
       VSN meets minimum gain requirement.
       Recycling is ignored on this media changer - VSN not marked for recycling.
    Checking 000015.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN is in correct media changer... good.
       VSN is not already recycling... good.
       VSN has no request files... good.
       VSN has no `archive -n' files...good.
       VSN was not specified as "no_recycle" in recycler.cmd file... good.
       VSN exceeds VSN count limit - skipped.
    Checking 000001.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000003.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000004.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000005.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000002.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000008.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000007.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000006.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000009.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000011.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000029.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000013.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000012.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000026.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000025.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000020.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000017.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000018.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN003.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000021.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000022.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000027.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000028.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000023.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000024.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000016.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN001.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN002.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking CLN004.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    Checking 000000.  Need to free 0E, quantity limit: (no limit), VSN count: 0.
       VSN not in correct media changer.
    No candidate was found in this media changer.
    34 VSNs:
                        ---Archives---   -----Percent-----   testset.1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   adic1:at:000010
    no-data VSN            0      0        0   100      0   adic1:at:000014
                        ---Archives---   -----Percent-----   testset.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   adic1:at:000019
    partially full       677      2.3G     5    93      2   adic1:at:000015
                        ---Archives---   -----Percent-----   allsam1.1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    partially full        97    173.8M     1     9     90   adic1:at:000001
    no-data VSN            0      0        0     2     98   adic1:at:000003
    no-data VSN            0      0        0     2     98   adic1:at:000004
    empty VSN              0      0        0     0    100   adic1:at:000005
    empty VSN              0      0        0     0    100   adic1:at:000002
                        ---Archives---   -----Percent-----   allsam1.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0    13     87   adic1:at:000008
    partially full        98      1.6G     3     7     90   adic1:at:000007
    no-data VSN            0      0        0     3     97   adic1:at:000006
    empty VSN              0      0        0     0    100   adic1:at:000009
                        ---Archives---   -----Percent-----   adic1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   adic1:at:000011
    no_recycle VSN         0      0        0   100      0   adic1:at:000029
    no-data VSN            0      0        0   100      0   adic1:at:000013
    no-data VSN            0      0        0   100      0   adic1:at:000012
    no_recycle VSN         0      0        0    99      1   adic1:at:000026
    no_recycle VSN         0      0        0    94      6   adic1:at:000025
    no_recycle VSN         0      0        0    51     49   adic1:at:000020
    no-data VSN            0      0        0    17     83   adic1:at:000017
    no-data VSN            0      0        0    10     90   adic1:at:000018
    empty VSN              0      0        0     0    100   adic1:at:CLN003
    no_recycle VSN         0      0        0     0    100   adic1:at:000021
    no_recycle VSN         0      0        0     0    100   adic1:at:000022
    no_recycle VSN         0      0        0     0    100   adic1:at:000027
    no_recycle VSN         0      0        0     0    100   adic1:at:000028
    no_recycle VSN         0      0        0     0    100   adic1:at:000023
    no_recycle VSN         0      0        0     0    100   adic1:at:000024
    empty VSN              0      0        0     0    100   adic1:at:000016
    empty VSN              0      0        0     0    100   adic1:at:CLN001
    empty VSN              0      0        0     0    100   adic1:at:CLN002
    empty VSN              0      0        0     0    100   adic1:at:CLN004
    partially full        12     88.3k     0     0    100   adic1:at:000000
    Recycler finished.
    ========== Recycler ends at Mon Jun  4 09:51:05 2001 ===========

10. Analyze the server and client `recycler.log` files to choose VSNs that are candidates for recycling.

Toward the end of the `recycler.log` file is a `Status` column. VSNs with the following types of status entries in the client log file are candidates for recycling:

- `no-data VSN`. To recycle a `no-data` VSN, see To Recycle no-data VSNs.

- `partially full`. To recycle a `partially full` VSN, see To Recycle partially full VSNs.

In the server log file, the best candidates for recycling are those with a 0 value in the `Count`, `Bytes`, and `Use` columns.

To Recycle `no-data` VSNs

The `no-data` VSNs are the easiest VSNs to recycle. For these, the `Count`, `Bytes`, and `Use` field values are all 0 (zero).

1. Examine the `recycler.log` file from the client to see if there are any `no-data` VSNs.

VSNs 000029 and 000026 from the client `zeke` can be considered for recycling because they are `no-data` VSNs, as shown in CODE EXAMPLE 7-23.

CODE EXAMPLE 7-23 The `recycler.log` File on Client `zeke`
    # From the client zeke recycler.log file:
                        ---Archives---   -----Percent-----   defaultset.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   skyrs:at:000029
    no-data VSN            0      0        0    99      1   skyrs:at:000026
    partially full       111      2.8G     6    88      6   skyrs:at:000025
    empty VSN              0      0        0     0    100   skyrs:at:000028
    empty VSN              0      0        0     0    100   skyrs:at:000027

2. Examine the `recycler.log` file from the server and determine if the VSNs you selected from the previous step are represented identically in the server's recycler log file.

You want to verify that there is no active data from the server archived on those VSNs.

CODE EXAMPLE 7-24 shows the data for the `no_recycle` VSNs in the server's `recycler.log` file. For VSNs 000029 and 000026, the data in the server's `recycler.log` file is identical to that in the client's `recycler.log` file.

CODE EXAMPLE 7-24 The `recycler.log` File on Server `sky`
    # From the Server log file:
                        ---Archives---   -----Percent-----   adic1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   adic1:at:000011
    no_recycle VSN         0      0        0   100      0   adic1:at:000029zeke
    no-data VSN            0      0        0   100      0   adic1:at:000013
    no-data VSN            0      0        0   100      0   adic1:at:000012
    no_recycle VSN         0      0        0    99      1   adic1:at:000026
    no_recycle VSN         0      0        0    94      6   adic1:at:000025
    no_recycle VSN         0      0        0    51     49   adic1:at:000020
    no-data VSN            0      0        0    17     83   adic1:at:000017
    no-data VSN            0      0        0    10     90   adic1:at:000018
    empty VSN              0      0        0     0    100   adic1:at:CLN003
    .
    .
    .

3. If no active data from the server is archived on the selected VSNs, use the `tplabel`(1M) or `odlabel`(1M) command to relabel the VSNs.

Note - This destroys all data on the VSN and reclaims space.

For example, for tape VSN 000029, use the following command:

    sky# tplabel -vsn 000029 -old 000029 at.000029

When this VSN 000029 is relabeled, you regain 100 percent of the space on that VSN.

If the media had been a magneto-optical disk, you would have used the `odlabel`(1M) command. For more information on the `odlabel`(1M) command, see the `odlabel`(1M) man page.

To Recycle `partially full` VSNs

The VSNs for which a `partially full` status is reported can also be recycled.

1. Examine the `recycler.log` file from the client to see if there are any `partially full` VSNs.

You can consider VSN 000025 from the client, `zeke`, for recycling because its status is `partially full`, as shown in CODE EXAMPLE 7-25.

CODE EXAMPLE 7-25 The `recycler.log` File on Client `zeke`
    # From the client zeke recycler.log file:
                        ---Archives---   -----Percent-----   defaultset.2
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   skyrs:at:000029
    no-data VSN            0      0        0    99      1   skyrs:at:000026
    partially full       111      2.8G     6    88      6   skyrs:at:000025
    empty VSN              0      0        0     0    100   skyrs:at:000028
    empty VSN              0      0        0     0    100   skyrs:at:000027

VSN 000025 shows that 6 percent of its space is in use. These are active archive images that must be rearchived before this VSN can be recycled. The following steps in this process show how to ensure that these active archive images are rearchived to another VSN.

2. Examine the `recycler.log` file from the server side to ensure that no active data from the server is archived on that VSN.

The server's `recycler.log` file indicates that VSN 000025 is 6 percent free, which is the same percentage that was reported in the client's `recycler.log` file. The server is not aware of the client's archive images, so it reports that all of the remaining 94 percent is consumed by obsolete archive images.

CODE EXAMPLE 7-26 The `recycler.log` File on Server `sky`
    # From the Server log file:
                        ---Archives---   -----Percent-----   adic1
    -----Status-----    Count    Bytes   Use Obsolete Free   Library:Type:VSN
    no-data VSN            0      0        0   100      0   adic1:at:000011
    no_recycle VSN         0      0        0   100      0   adic1:at:000029
    no-data VSN            0      0        0   100      0   adic1:at:000013
    no-data VSN            0      0        0   100      0   adic1:at:000012
    no_recycle VSN         0      0        0    99      1   adic1:at:000026
    no_recycle VSN         0      0        0    94      6   adic1:at:000025
    no_recycle VSN         0      0        0    51     49   adic1:at:000020
    no-data VSN            0      0        0    17     83   adic1:at:000017
    .
    .
    .

3. On the server, use the `chmed`(1M) command with the +c option to rearchive the active files on the VSN.

    sky# chmed +c at.000025

For more information about the `chmed`(1M) command, see the `chmed`(1M) man page.

4. On the client, use the `sam-recycler`(1M) command to run the recycler again.

    zeke# sam-recycler -dvx

This marks each active file to be rearchived to another VSN.

5. Start the archiver.

You can do this either by letting the archiver run normally, or by typing `:arrun` from the `samu`(1M) utility on the client. For more information about the `:arrun` command, see the `samu`(1M) man page.

6. When archiving is complete, issue the `sam-recycler`(1M) command to rerun the recycler on the client.

    zeke# sam-recycler -dvx

This ensures that all active files have been rearchived.

7. If the Count, Bytes, and Use field values are all 0 (zero), use the `tplabel`(1M) or `odlabel`(1M) command to relabel the VSN from the server.

For example, for tape VSN 000025, use the following command:

    sky# tplabel -vsn 000025 -old 000025 at.000025

This command relabels the VSN and destroys all data on it. After this VSN is relabeled, you regain 88 percent of the space on this VSN.

If the media had been a magneto-optical disk, you would have used the `odlabel`(1M) command. For more information about the `odlabel`(1M) command, see the `odlabel`(1M) man page.

### Recycling in a Sun SAM-Remote Environment--Method 2

This section presents another way you can recycle volumes using Sun SAM-remote software.

| Caution - Use the recycler in a Sun SAM-Remote environment only after following the steps in this procedure completely and only after testing your configuration to verifying that recycling is taking place correctly.

To Configure Recycling--Method 2

1. On the Sun SAM-Remote client, issue the `sam-recycler`(1M) command to determine which volumes are the best candidates for recycling.

For example:

    client# sam-recycler -dvx

2. Analyze the recycler log file.

3. On the Sun SAM-Remote server, issue the `chmed`(1M) command to set the recycle flag on the selected VSNs.

For example:

    server# chmed +c at.00025

4. On the Sun SAM-Remote client, issue the `sam-recycler`(1M) command to recycle the selected VSNs on the Sun SAM-Remote client.

For example:

    client# sam-recycler -dvx

5. Wait until the VSNs being recycled are drained completely of archive images.

The archiver on the client side does this.

6. On the Sun SAM-Remote server, issue the `tplabel`(1M) or `odlabel`(1M) command, depending on the archive media, to relabel the volumes.

7. On the Sun SAM-Remote server, clear any flags, such as `R` or `c` that prevent the volumes from being used for archiving on the Sun SAM-Remote client.

Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.