| Sun StorEdge SAM-FS Storage and Archive Management Guide
|
   
|
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 topics:
Sun SAM-Remote Software Overview
The following topics are covered in this overview:
Features
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 one 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.
FIGURE 7-1shows an environment configured with two Sun SAM-Remote host system servers. Each has two clients.
FIGURE 7-1 Sun SAM-Remote Servers and Clients 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, you can find information about that topic in 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 and SAM-Remote only operate on the file systems for which that server is a metadata server.
Technical Overview
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 Fiber 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 10 clients can be configured per daemon. To configure more than 10 clients, add an additional remote server entry in the mcf file for each 10 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. You should typically 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
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.
In the examples in this chapter, the Sun StorEdge SAM-FS file systems write some of their archive copies to cartridges controlled by chicago.
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 shown, which is as follows:
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
In the following steps, you log in to the host systems, verify existing software revision levels, and upgrade the software as needed.
|
 To Log In to the Potential Server and Client Hosts
|
You must log in to all potential server and client hosts as the superuser.
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 client(s) 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
|
The following steps ensure that you have the required software levels installed on the systems to be configured as part of a Sun SAM-Remote environment.
1. Issue the pkginfo(1M) command with its -l option on all hosts to be configured as a Sun SAM-Remote client or server.
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. For example:
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#
|
2. Examine the output from the pkginfo(1) command.
Using 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.
It is assumed that the Sun StorEdge SAM-FS environments are properly configured and operational.
3. Issue the showrev(1M) command with its -p option on all hosts to be configured as a Sun SAM-Remote client or server.
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. For example:
CODE EXAMPLE 7-2 Using showrev (1M)
portland# showrev -p | grep SUNWsamfs
Patch: 113546-07 Obsoletes: Requires: Incompatibles: Packages: SUNWsamfs
portland#
|
4. Examine the output from the showrev(1M) command.
Using 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.
5. Repeat Step 1, Step 2, Step 3, and Step 4 for each system to be configured in the environment.
6. (Optional) Upgrade the software as necessary.
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 perform this step.
If some systems to be configured as part of a Sun SAM-Remote environment are running earlier versions of the software or patches, 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 the removable media drives under the control of the Sun StorEdge SAM-FS software.
For example:
|
Argument
|
Definition
|
|
eq
|
The equipment ordinal of the removable media drive being addressed, as defined in the mcf file.
|
Issue a samcmd(1M) command for each removable media drive in the environment. 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-initd daemon and its child processes.
The samd(1M) command is installed in /opt/SUNWsamfs/sbin.
2. On a 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.
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 on 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. The fields are as follows:
- The Equipment Identifier field is the path name to the client configuration file, which is created later in To Define a Sun SAM-Remote Client. In this example, the configuration file is named /etc/opt/SUNWsamfs/rmt200.
- The Equipment Ordinal field contains a unique number such that 1 < equipment_ordinal < 65535. This equipment ordinal is 200.
- The Equipment Type field contains a two-letter mnemonic, sc, which identifies a Sun SAM-Remote client.
- The Family Set field, chicagoss, is the same as the family set name of the server. This is the family set name of the daemon to use on this particular server. A Sun SAM-Remote server can have one server daemon per client.
- The Device State field specifies on.
- The Additional Parameters field is optional. As shown, a path to the catalog file can be specified here.
The last two entries in this mcf file define the Sun SAM-Remote pseudo-devices. A pseudo-device defines a network connection to an actual device on the Sun SAM-Remote server. These entries are as follows:
- The Equipment Identifier field is the path name to the /dev/samrd/rd* entry to be used by the pseudo-device. These entries are created when the system is rebooted. You can define an unlimited number of pseudo-devices.
- The Equipment Type field is the two-letter mnemonic rd for pseudo-devices.
- The Family Set field, chicagoss, is the same as the family set name of the client entry.
3. (Optional) On additional clients, use vi(1) or another editor to edit the existing Sun StorEdge SAM-FS /etc/opt/SUNWsamfs/mcf file.
If you have additional clients, you must complete this step for each additional Sun SAM-Remote client. Follow the same procedure outlined in Step 2.
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.
|
To Define a Sun SAM-Remote Client
|
The Sun SAM-Remote client's configuration file contains a single-line entry: 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 the 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.
The result of this step is a one-line file.
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
|
3. Repeat Step 1 and Step 2 for each Sun SAM-Remote client.
If you have more than one client, create a client file on each client.
|
To Define a Sun SAM-Remote Server in the Server's mcf File
|
This step defines a Sun SAM-Remote server in the server's mcf file.
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 to define the system as a Sun SAM-Remote server.
In this step's example, the mcf file on server chicago is edited. The resulting mcf 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
|
These entries follow the syntax as defined in mcf(4), and in this example file, they are as follows:
- The Equipment Identifier field is the path name to the server configuration file, which you configure in the following procedure. In this example, the file is named /etc/opt/SUNWsamfs/rmt200.
- The Equipment Ordinal field contains a unique number such that 1
equipment_ordinal 65535. In this example, the equipment ordinal is 50.
- The Equipment Type field contains a two-letter mnemonic, ss, that identifies the Sun SAM-Remote Server.
- The Family Set field, chicagoss, matches the family set name used in the mcf file of the client(s). Note that a Sun SAM-Remote server can have more than one server daemon defined.
- The Device State field, which is optional, specifies on in this example.
- The Additional Parameters field is optional.
|
Note - You must have at least one Sun StorEdge SAM-FS file system configured in the mcf file for the Sun SAM-Remote server.
|
|
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-6 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:
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. Note that the generic media type specifications that are valid in the mcf file are not valid for the media_type specification. The specification must be for a specific media type (lt, for example). 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.
|
|
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.
You can specify more than one media definition line for each media_type, which gives you flexibility in defining media. For example, the following is a valid media type definition:
media
100 lt (VSN1)
100 lt (VSN2)
endmedia
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 client(s).
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:
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 client(s).
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 follows:
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 to ensure that the catalog is available on the client(s).
For each client, you should be able to view the Sun SAM-Remote catalog that is available for that client by using the samu(1M) utility's v display to show VSNs. From samu(1M), enter the following:
The eq must be 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. This display was obtained by specifying :v 200 on chicago. It shows the volumes that portland can access from chicago.
CODE EXAMPLE 7-12 Volumes Available 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 the client(s), 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. You can do this by using the archiver(1M) command and its -A option. This option enables a listing to be written from the archiver, and this listing includes 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 for information about how to troubleshoot the archiver.
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 in this chapter. The restrictions on recycling that are described in this chapter must be followed exactly, or data loss can result. No enforcement of these restrictions exists in the Sun StorEdge SAM-FS software.
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.
|
Caution - Using the recycler in a Sun SAM-Remote environment requires 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.
It is very important that recycling activities on the Sun SAM-Remote server and the Sun SAM-Remote client not overlap. The result could be accidental relabeling of cartridges and irreversible loss of data.
You cannot 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. The server and the client each must have exclusive use of a certain set of cartridges. Each must never use the other's cartridges. You can prevent accidental recycling of VSNs used by Sun SAM-Remote clients by creating a no_recyclelist in the Sun SAM-Remote server's /etc/opt/SUNWsamfs/recycler.cmdfile. Be careful of using the chmed(1M) command's +coption on volumes in a no_recyclelist, however. When you use this command to set the recycling flag (+c) on a volume, that action overrides the no_recyclelist in the /etc/opt/SUNWsamfs/recycler.cmd
file.
Do 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 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 using Sun SAM-Remote, recycling must be performed by archive set, not by library.
This chapter describes 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
The procedures in this section describe one method for enabling recycling in a Sun SAM-Remote environment. Throughout this section, the example environment is one in which the server is named sky and the client is named zeke. This procedure shows how to configure Sun SAM-Remote to create archive copies of files on cartridges in two different libraries. Archive copy 1 will be written using a StorageTek library that is local to zeke. Archive copy 2 will be written remotely, using an ADIC library attached to sky. Pertinent files for these two systems are shown in the following sections.
|
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 see that correct recycling is taking place.
|
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 following procedure shows how to configure the recycling process. This procedure 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 Recycling.
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 perform as follows:
- 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 limit the amount of work needed to regain space. That is, this directive is set high to ensure efficiency.
- The -recycle_vsncount 1 directive prevents recycling from overwhelming the system. This directive specifies that the recycler drain one VSN at a time. When the first VSN is drained, a second is selected to begin draining. So at any moment in time, there is one VSN in the queue to be relabeled and one VSN in the queue to be drained.
4. Edit the recycler.cmd file on the client and specify a log file to receive recycling log output.
The following recycler.cmd file on client zeke 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.
Use an editor to 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.
The following recycler.cmd file on server sky 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 it is running on 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:
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 test the recycler.
Make sure that the recycler is not recycling any VSNs reserved for the Sun SAM-Remote client.
For example:
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 ===========
|
When selecting VSNs to recycle, examine the last part of the recycler log file that shows columnar data. The left-most column is the one headed by Status. In the preceding recycler log file, the Status column indicates several VSNs with a no_recycle status. These VSNs are those used by the client.
The best candidates for recycling are those with a 0 value in the Count, Bytes, and Use columns. The last VSN in the list shows its status as partially full. This VSN, with Count, Bytes, and Use statistics of 12, 88.3k, and 0, respectively, is not a good candidate for recycling.
10. Analyze the client and server recycler.log files.
This step explains how to choose VSNs that are candidates for recycling.
Examine the recycler.log file from the client. Toward the end of the file is a Status column. VSNs with the following types of status entries are candidates for recycling:
|
To Recycle no-data VSNs
|
The no-data VSNs are the easiest VSNs to recycle. For these, the Count, Bytes, and Use fields are all 0 (zero).
1. Examine the recycler.log file from the client to see if there are any no-data VSNs.
Using the example in this chapter, VSNs 000029 and 000026 from the client, zeke, can be considered for recycling because they are no-data VSNs. This can be determined from CODE EXAMPLE 7-23, which shows the client recycler.log file on zeke.
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 are trying to affirm 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. VSNs 000029 and 000026 were selected for recycling from the previous step, and 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
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
|
3. (Optional) Use the tplabel(1M) or odlabel(1M) command to relabel the VSN.
If no active data from the server is archived on that VSN, you can relabel the VSN.
|
Note - This destroys all data on the VSN and reclaims space.
|
For example, for tape VSN 000029, use the following command:
server# 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.
4. Devise a recycling schedule.
In a Sun StorEdge SAM-FS environment in which Sun SAM-Remote software is not enabled, you can create a cron(1) job so recycling is performed automatically. If Sun SAM-Remote software is enabled, however, do not automate the recycler.
|
Caution - It is very important that recycling activities not be undertaken on the Sun SAM-Remote client at the same time that recycling is occurring on the Sun SAM-Remote server. You should manually recycle on a time-interval basis that meets the needs of your site. Recycling in this manner takes more effort. However, this is the only way to ensure that data is well protected against relabeling cartridges incorrectly.
|
|
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.
Using the example in this chapter, you can consider VSN 000025 from the client, zeke, for recycling because its status is partially full. You can determine this from CODE EXAMPLE 7-25, which shows the client recycler.log file on zeke.
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.
For example, look at the data for VSN 000025 in CODE EXAMPLE 7-26 that was selected for recycling from the previous step. 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 the server cannot report that the percent occupied is divided into 6 percent in-use archive images and 88 percent obsolete images. The server 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
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
|
3. Use the chmed(1M) command with the +c option on the VSN.
For the example in this procedure, the command is as follows:
server# chmed +c at.000025
|
This command indicates to the recycler that you want to rearchive the active files on this VSN. The files to be rearchived constitute the 6 percent as reported by the client's recycler.log file in the Use column. For more information about the chmed(1M) command, see the chmed(1M) man page.
4. Use the sam-recycler(1M) command to run the recycler again.
For the example in this procedure, the command is as follows:
client# sam-recycler -dvx
|
This marks each active file to be rearchived and indicates to the archiver that each active file should be rearchived to another VSN.
5. Start the archiver.
You can do this by either letting the archiver run normally, or by typing :arrun from the samu(1M) utility on the client to start the archiver. 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.
This ensures that all active files have been rearchived.
For the example in this procedure, the command is as follows:
client# sam-recycler -dvx
|
7. (Optional) Use the tplabel(1M) or odlabel(1M) command to relabel the VSN from the server.
If the Count, Bytes, and Use fields are all 0 (zero), you can relabel the VSN from the server.
For the example in this procedure, you can use the following command to relabel the tape VSN:
server# tplabel -vsn 000025 -old 000025 at.000025
|
The preceding command relabels the VSN and destroys all data on the VSN. 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.
8. Devise a recycling schedule.
In a Sun StorEdge SAM-FS environment in which Sun SAM-Remote software is not enabled, you can create a cron(1) job so recycling is performed automatically. If Sun SAM-Remote software is enabled, however, do not automate the recycler.
|
Caution - It is very important that recycling activities not be undertaken on the Sun SAM-Remote client at the same time that recycling is occurring on the Sun SAM-Remote server. You should manually recycle on a time-interval basis that meets the needs of your site. Recycling in this manner takes more effort. However, this is the only way to ensure that data is well protected against relabeling cartridges incorrectly.
|
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 see that correct recycling is taking place.
|
|
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
|
You can determine this by analyzing the recycler log file.
2. On the Sun SAM-Remote server, issue the chmed(1M) command to set the recycle flag on the chosen VSNs.
For example:
server# chmed +c at.00025
|
3. On the Sun SAM-Remote client, issue the sam-recycler(1M) command to recycle the chosen VSNs on the Sun SAM-Remote client.
For example:
client# sam-recycler -dvx
|
4. Wait until the VSNs being recycled are drained completely of archive images.
The archiver on the client side does this.
5. On the Sun SAM-Remote server, issue the tplabel(1M) or odlabel(1M) command to relabel the volumes after they are completely drained of archive images.
6. On the Sun SAM-Remote server, clear any flags that prevent the volumes from being used for archiving on the Sun SAM-Remote client (such as R or c).
Again, it is very important that these recycling activities not be undertaken on the Sun SAM-Remote client at the same time that you are recycling volumes on the Sun SAM-Remote server.
| Sun StorEdge SAM-FS Storage and Archive Management Guide
|
819-2755-10
|
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.