dell · emc diskxtender for unix/linux storage manager release 2.11 administration guide 3 preface...

ag.book Monday, August 4, 2008 11:21 AM

EMC® DiskXtender®

for UNIX/Linux Storage ManagerRelease 2.11

Administration GuideP/N 300-006-391

REV A01

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-9103

1-508-435-1000www.EMC.com

2


Copyright © 2002–2008 EMC Corporation. All rights reserved.

Published August, 2008

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date regulatory document for your product line, go to the Technical Documentation and Advisories section on EMC Powerlink.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Administration Guide

Contents


Preface

Chapter 1 IntroductionProduct definition ............................................................................. 16DXUL-SM and the UNIX file system comparison ....................... 18IEEE mass storage reference model ............................................... 21Hierarchical file storage system...................................................... 23Terminology....................................................................................... 26DXUL-SM servers ............................................................................. 29User access ......................................................................................... 31Coexistence of DXUL-SM and UNIX file systems ....................... 35Root point for DXUL-SM system tree ............................................ 36

Chapter 2 Files and DirectoriesMan pages .......................................................................................... 38Binary files ......................................................................................... 39

<DISKXTENDER>/bin............................................................. 40<DISKXTENDER>/adm/bin.................................................................................... 41

Configuration files ............................................................................ 48Log files .............................................................................................. 51Core files............................................................................................. 52

Chapter 3 Configuring DXUL-SMConfiguration files in <DISKXTENDER>/etc.............................. 54

<DISKXTENDER>/etc/DiskXtender.conf .............................54General configuration ...................................................................... 63

EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Administration Guide 3

Contents


general.save cores...................................................................... 63general.use nis............................................................................ 63general.use sticky bit.................................................................. 63general.pvrserver_timeout........................................................ 64general.wormfs .......................................................................... 64general.wormfs_allowmoves.................................................... 64

Migration server configuration....................................................... 65File migration ............................................................................. 65Multiple file instances................................................................ 67

Disk mover configuration................................................................ 69diskmover.MaxBufSize.............................................................. 69

Disk Server configuration................................................................ 70Purge parameters....................................................................... 70Purge parameter effects ............................................................. 72Tuning the purge parameters ................................................... 73Disk cache header ratio.............................................................. 75Related file staging .................................................................... 77NFS tunables .............................................................................. 78

Name Server configuration ............................................................. 80Trash cans ................................................................................... 80Trash can parameters................................................................. 82Name Server cache parameters ................................................ 84Name Server related file set parameters ................................. 84Name Server journal parameters ............................................. 84Tape mover configuration......................................................... 85Tape server configuration ......................................................... 85System sizing constraints .......................................................... 86Drive allocation.......................................................................... 87

Tape server tape map parameters .................................................. 90tapeserver.reset_tapemap_fam................................................. 90tapeserver.reset_tapemap_loc .................................................. 90tapeserver.reset_tapemap_cnum ............................................. 90tapeserver.reset_tapemap_usage ............................................. 90tape server parameters .............................................................. 90

Repack server configuration ........................................................... 92Repacking parameters ............................................................... 92Vault migration parameters...................................................... 93

Resource usage parameters ............................................................. 95Repack action .................................................................................... 97PVR Server configuration................................................................ 99

pvrserver.dismount_retry_time ............................................... 99pvrserver.mount_retry_time .................................................... 99pvrserver.IsDTS .......................................................................... 99

EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Administration Guide4

Contents


CML server configuration.............................................................. 100CML log file configuration ......................................................100

<DISKXTENDER>/etc/DiskXtender.net.................................... 102Format of DiskXtender.net ......................................................102

<DISKXTENDER>/etc/DiskXtender.path ................................. 104<DISKXTENDER>/etc/adduser .................................................. 105

Format of adduser.................................................................... 105<DISKXTENDER>/etc/cmf.......................................................... 107

Format of CMF ......................................................................... 107<DISKXTENDER>/etc/diskdevs................................................. 109<DISKXTENDER>/etc/exports ................................................... 110

Format of exports ..................................................................... 110<DISKXTENDER>/etc/family ..................................................... 111NFS compared with FTP ................................................................ 112

Format of a family file entry................................................... 112<DISKXTENDER>/etc/rc.diskxtender ....................................... 114<DISKXTENDER>/etc/rmtab...................................................... 115<DISKXTENDER>/etc/rootcap ................................................... 116<DISKXTENDER>/etc/PVRINFO .............................................. 117

Format of PVRINFO for 64-bit drive support.......................117Format of PVRINFO for 128-bit drive support.....................117Adding tape drives .................................................................. 118Removing tape drives ............................................................. 119

<DISKXTENDER>/etc/smf.......................................................... 120Format of the smf file .............................................................. 120

<DISKXTENDER>/etc/tddevs .................................................... 122Format of tddevs ...................................................................... 122

<DISKXTENDER>/etc/tpdevs .................................................... 123Format of tpdevs ...................................................................... 123

<DISKXTENDER>/etc/tpset........................................................ 125Format of tpset ......................................................................... 125

<DISKXTENDER>/etc/nsdevs .................................................... 126Format of nsdevs...................................................................... 126

<DISKXTENDER>/etc/xtab......................................................... 127FTP..................................................................................................... 128

uftpd Server configuration ......................................................129NFS............................................................................................. 129

Exports file ....................................................................................... 130Format of exports ..................................................................... 130

Root permissions ............................................................................. 131NFS access toggle ............................................................................ 132Dual NFS .......................................................................................... 133NFS mount options ......................................................................... 134

5EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Administration Guide

Contents


DXUL-SM NFS server data cache ................................................ 135ACacheSize............................................................................... 135ACacheTime ............................................................................. 136DCacheTableSize ..................................................................... 136BucketLifetime ......................................................................... 136BucketSize................................................................................. 136MaxMem................................................................................... 136

Tapeconf and Ioctlconf — Configuring tape devices ................ 137ioctlconf..................................................................................... 137tapeconf..................................................................................... 140

Dynamic migration using the media switch............................... 144Moving the system tree.................................................................. 145

DISKXTENDER_ROOT_PATH.............................................. 145System boot script ................................................................... 145/etc/inetd.conf ........................................................................ 145<DISKXTENDER>/etc/rc.diskxtender ................................ 145<DISKXTENDER>/etc/DiskXtender.path .......................... 146

Chapter 4 Routine Management ProceduresDXUL-SM startup and shutdown ................................................ 148

DXUL-SM persistence daemons............................................. 148Using daemons to start DXUL-SM ........................................ 149Shutting down DXUL-SM by using the DXUL-SM daemons..150

DXUL-SM servers ........................................................................... 151Manual startup of DXUL-SM.................................................. 151Shutdown of servers ............................................................... 152

User maintenance ........................................................................... 153User authentication file............................................................ 153Format of adduser ................................................................... 153Adding DXUL-SM users ........................................................ 155The nsau utility ........................................................................ 155Removing DXUL-SM users.................................................... 157

Monitoring use of the System ....................................................... 158Common message logger and other log files ....................... 158Monitoring token log .............................................................. 158Monitoring other log files....................................................... 159Disk cache usage...................................................................... 159Tape usage ................................................................................ 160Monitoring tape usage............................................................. 160

File migration and tape repacking ............................................... 162Migration from disk cache to tape ......................................... 162


Contents


Monitoring migration...............................................................162Migration and caching .............................................................163Tape repacking and vault migration......................................164Forcepack utility....................................................................... 165Monitoring repacking.............................................................. 169

Family files ....................................................................................... 170Monitoring families ................................................................. 170

Backup procedures.......................................................................... 172Name Server database............................................................. 172Disk Cache ................................................................................ 174Tape Server data structures .................................................... 176

Volumes (tapes) ............................................................................... 180Backing up the DXUL-SM system tree ................................. 180

Chapter 5 Adding and Removing DevicesStorage devices dedicated to the system ..................................... 183Name server database .................................................................... 184

Extending the Name Server database ....................................184Disk cache......................................................................................... 187

Disk cache contention minimization......................................187Adding disk partitions to the disk cache...............................187Removing disk partitions from the disk cache .....................189

Tape header disks............................................................................ 192Adding tape server header disk partitions ...........................192Adding tape drives .................................................................. 194Editing the tpdevs file ..............................................................195Editing the PVRINFO file ........................................................196Editing PVRINFO .................................................................... 197Restarting the tape server and the PVR Server ....................198Sharing tape drives .................................................................. 198Sharing robotic tape libraries ..................................................198Removing tape drives ..............................................................199Editing the tpdevs file ..............................................................200Editing the PVRINFO file ....................................................... 200Restarting the tape processes ..................................................201

Tape media ....................................................................................... 202Adding data volumes to the tape server’s map ...................202Removing data tapes ................................................................205Backup volumes ....................................................................... 205ACSLS server ............................................................................ 206

System sizing control...................................................................... 208


Contents


Chapter 6 Scheduled ActivitiesPerforming system backups.......................................................... 210Monitoring the CML log and other log files............................... 211Mounting requested tapes............................................................. 212Maintaining free volumes in the system ..................................... 213Core files .......................................................................................... 214Monitoring space in the DXUL-SM system tree......................... 215

Chapter 7 TroubleshootingDXUL-SM crashes at startup......................................................... 218

Privileges and permissions ..................................................... 218Individual server crashes at startup ............................................ 219

Configuration parameters ....................................................... 219Sockets....................................................................................... 219NFS ............................................................................................ 220Startup order of tape processes .............................................. 220

DXUL-SM system crashes after startup ...................................... 221File descriptors......................................................................... 221UNIX file system full .............................................................. 221Nohup ....................................................................................... 221

Individual server crashes after startup........................................ 222Log files..................................................................................... 222Disk processes and bad devices ............................................. 222

Performance..................................................................................... 223Communication ....................................................................... 223

FTP .................................................................................................... 224NFS.................................................................................................... 225Manually mounted volumes......................................................... 227

Chapter 8 Disaster RecoveryName Server database ................................................................... 230

Loss of a single Name Server partition ................................ 230Loss of a pair of Name Server partitions.............................. 231

Disk cache ........................................................................................ 234Tape server disks............................................................................. 236

Loss of a single tape server partition..................................... 236Loss of a pair of tape server partitions .................................. 237

Volumes............................................................................................ 243Loss of a volume with multiple file copies running........... 243Loss of a volume without multiple file copies running..... 243


Contents


Chapter 9 Disaster Recovery ManagerReplication manager ....................................................................... 246Install Replication Manager........................................................... 247Configure the primary DXUL-SM system for the remote RM . 250

Chapter 10 Volume Export and ImportVolume export and import utilities .............................................. 255Set the DXUL-SM environment .................................................... 256The export utility............................................................................. 257

Syntax ........................................................................................ 257Options ...................................................................................... 257How to create an interchange datafile .................................. 259Preparing a remap file ............................................................. 260

The import utility ............................................................................ 263New directories created during importing ...........................264Duplicate volume labels.......................................................... 264

The remove utility ........................................................................... 269Syntax ........................................................................................ 269

Appendix A Robotic Devices and the Volume ManagerOverview .......................................................................................... 272SCSI robotics and the SCSIINFO file ............................................ 273

Format of SCSIINFO................................................................ 273Adding a robotically-mounted SCSI tape drive ......................... 274STK robot and STKINFO file ......................................................... 275

Format of STKINFO................................................................. 275Configuring ssi.sh .................................................................... 277Configuring rc.diskxtender .....................................................277

SGEN driver..................................................................................... 279Upgrade from existing SST driver to SGEN driver .............279

The Volume Manager ..................................................................... 280requesttape and logicaltape directories .................................281

Appendix B Device BitmapsUnderstanding device bitmaps ..................................................... 284

tpdevs unit numbers................................................................ 284Significance of the device bitmap digits ............................... 284

The Hex Value of a drive................................................................ 286


Contents




Preface

As part of an effort to improve and enhance the performance and capabilities of its product lines, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, please contact your EMC representative.

Audience This document is part of the EMC DiskXtender UNIX/Linux Storage Manager release 2.11 documentation set, and is intended for use by system administrators.

Readers of this document are expected to be familiar with the following topics:

◆ Their organization’s data archiving strategy, in particular:

• Average archived file size.

• Anticipated total number of files and total bytes to be archived.

• File access norms: Frequency of access during creation, edit, and archive phases.

• Special file requirements, such as shorter access times, multiple fail-safe copies, and optimal file stub size.

• Backup strategies for data in the file systems.

◆ The network details of all computer systems and hardware devices to be used, including:


12

Preface


• IP addresses.

• TCP/IP routing information.

• Switch, router, firewall, and network-attached device configurations.

◆ The administration details of all involved storage devices.

Relateddocumentation

Related documents include:

◆ EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Installation Guide

◆ EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 System Environment Manager Guide

◆ EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 User Guide

◆ EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Release Notes

◆ EMC AutoStart Module for EMC DiskXtender UNIX/Linux Storage Manager

Conventions used inthis document

EMC uses the following conventions for special notices.

Note: A note presents information that is important, but not hazard-related.

CAUTION!A caution contains information essential to avoid data loss or damage to the system or equipment.

IMPORTANT!An important notice contains information essential to operation of the software.


Preface


Typographical conventionsEMC uses the following type style conventions in this document:

Normal Used in running (nonprocedural) text for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• Names of resources, attributes, pools, Boolean expressions, buttons, DQL

statements, keywords, clauses, environment variables, functions, utilities• URLs, pathnames, filenames, directory names, computer names, links, groups,

service keys, file systems, notifications

Bold Used in running (nonprocedural) text for:• Names of commands, daemons, options, programs, processes, services,

applications, utilities, kernels, notifications, system calls, man pages

Used in procedures for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• What user specifically selects, clicks, presses, or types

Italic Used in all text (including procedures) for:• Full titles of publications referenced in text• Emphasis (for example a new term)• Variables

Courier Used for:• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when shown outside of

running text

Courier bold Used for:• Specific user input (such as commands)

Courier italic Used in procedures for:• Variables on command line• User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{ } Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example


14

Preface


Where to get help EMC support, product, and licensing information can be obtained as follows.

Product information — For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:

http://Powerlink.EMC.com

Technical support — For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Your comments Comments and suggestions about our product documentation are always welcome.

To provide feedback:

1. Go to:


2. Click the Feedback link.





1

This chapter contains the following sections:

◆ Product definition .............................................................................. 16◆ DXUL-SM and the UNIX file system comparison ........................ 18◆ IEEE mass storage reference model................................................. 21◆ Hierarchical file storage system....................................................... 23◆ Terminology........................................................................................ 26◆ DXUL-SM servers .............................................................................. 29◆ User access .......................................................................................... 31◆ Coexistence of DXUL-SM and UNIX file systems ........................ 35◆ Root point for DXUL-SM system tree ............................................. 36

Introduction

Introduction 15

16

Introduction


Product definitionThe DiskXtender® for UNIX/Linux Storage Manager (DXUL-SM) is a scalable storage system that automatically manages data movement between various levels of a storage hierarchy. DXUL-SM is the most complete implementation of the IEEE Mass Storage System Reference Model, version 4.0. The system is implemented as a set of cooperative message passing processes, using the client/server model.


Introduction


Access to the system is provided through the TCP/IP protocols as shown in Figure 1 on page 17.

Figure 1 DiskXtender modules

Diskmover

Tapemover

File movers

FTPclientofNFSclient

FTPdaemonofNFSserver

LOCALSTORAGE

Diskserver

Migrationserver

Tapeserver

Repackserver

FILE CLIENTS File servers Storage server

Name serverStorage system manager

Name serverStorage system

manager

Physical volumerepository

Physicalvolume

repository

GEN-000876

Tapevault

Automated On-lineTapeFacility

Product definition 17

18

Introduction


DXUL-SM and the UNIX file system comparisonDXUL-SM is a file system similar to the UNIX file system, but with a number of functional extensions. The DXUL-SM files reside on magnetic disk-like files in a UNIX file system. However, the DXUL-SM files also reside on secondary media such as magnetic tape that can be distributed across the network, as shown in Figure 2 on page 18.

Figure 2 UNIX file system

Localdisk

NFS

Local (Client)

FTP

Localtape

Localdisk

NFS

Local (Client)

FTP

Localtape

Shareddisk

NFS

Remote (Server)

FTP

GEN-000877

Localtape


Introduction


Figure 3 DXUL-SM file system access

DXUL-SM automatically copies files between media types and provides unlimited file system size and cost-effective use of storage media. The UNIX file system does not have this capability. DXUL-SM automates the backup and archiving of data through the use of robotic devices.

Table 1 on page 20 compares UNIX and DXUL-SM file system features.

Shareddisk

GEN-000878

Shared roboticallycontrolled tape

Shared operatorcontrolled tape

Localdisk

NFS

Local (Client)

FTP

Localtape

Localdisk

NFS

Local (Client)

FTP

Localtape

NFS

Remote (Server)

FTP

DXUL-SM and the UNIX file system comparison 19

20

Introduction


Table 1 UNIX and DXUL-SM file system features

UNIX file system features DXUL-SM file system features

Provides FTP and NFS standard interfaces. Provides FTP and NFS standard interfaces.

File systems are limited to one disk. File systems span multiple volumes and media types.

Manual management of storage media. Automatic management (backup and archival) of storage media.

Limited storage capacity. Unlimited storage capacity.

Limited file system size. Unlimited file system size.

Limited number of files. No restrictions on number of files.

No physical hierarchy of storage devices. DXUL-SM is a hierarchical storage system.


Introduction


IEEE mass storage reference model DXUL-SM is based on the IEEE mass storage reference model version 4, an architecture for the design of distributed storage systems. The model and its identified interfaces allow and encourage vendors to develop mutually-compatible storage components that can be combined to form integrated storage systems and services.

Figure 4 IEEE mass storage system reference model 4

SS Requests

SS Replies

BITFILECLIENT

Client Requests

Bitfile Transfer

Move Command

Move Complete

Bitfile Transfer

Move Command

Move Complete

Client Replies

STORAGESERVER

BITFILEMOVER

GEN-000879

User NameFile ID Site MonitorSite Control PV RequestPV Reply

BITFILESERVER

NAMESERVER

STORAGESYSTEM

MANAGER

PHYSICALVOLUME

REPOSITORY

IEEE mass storage reference model 21

22

Introduction


DXUL-SM is modeled after the IEEE module.

Even though DXUL-SM is based on the IEEE model, it provides the following functionality:

◆ UNIX-like file system interface

◆ Repacking or storage reclamation facility

◆ Message logging facility

Table 2 IEEE and DXUL-SM module comparison

IEEE module DXUL-SM module

Bitfile Client DXUL-SM NFS Server and DXUL-SM FTP daemon

Bitfile Mover Disk Mover and Tape Mover

Bitfile Server Disk Server and Tape Server

Name Server Name Server

Physical Volume Repository

PVR Server

Storage Server Tape Server


Introduction


Hierarchical file storage systemDXUL-SM is a hierarchical storage system that provides automatic storage media management with unlimited data storage capacity. As a hierarchical storage system, DXUL-SM simultaneously manages different layers of storage media.

At the top of the DXUL-SM hierarchy is a layer of magnetic disk that consists of disk partitions dedicated at installation to DXUL-SM. DXUL-SM manages this layer as a cache. All files created in DXUL-SM reside first on the disk cache. When configured, the DXUL-SM files are migrated (copied without destroying the original) to a lower layer in the DXUL-SM hierarchy. DXUL-SM can make multiple copies (maximum 15) of migrated files, managed on separate volumes to protect against media failure. Multiple copies provide redundancy and greater safety than regular backups.

After files have migrated from the disk cache to a lower layer in the DXUL-SM hierarchy, they may be purged (removed) from the cache, as required, to make space available for the creation and manipulation of other files. Purging parameters are configurable by the system administrator. Files which have been purged still appear to the user as if they are on disk. Only when the data in the file is actually accessed will the user see a delay as the data is retrieved from secondary media.

It is important to understand that migration and purging are two different operations in DXUL-SM. Migration only copies files to a lower layer in the hierarchy. File will still reside on two layers simultaneously. However, purging is the separate act of removing files from the higher layer at some time after they have been migrated to the lower layer. Once files have been purged from the higher layer, they exist only on the lower layer to which they were previously migrated. An example of a three-layer DXUL-SM storage hierarchy is shown in Figure 5 on page 24.

Hierarchical file storage system 23

24

Introduction


Note: DXUL-SM also provides automated migration between layers of secondary storage. This repacking function, referred to as “vault migration,” occurs when storage in the online devices approaches storage capacity.

Figure 5 Three-layer DXUL-SM storage hierarchy

When the user requests access to a DXUL-SM file which has been migrated and purged from the disk cache, files are cached (copied) from the layer where a copy resides in the DXUL-SM hierarchy, directly back to the disk cache layer. DXUL-SM automatically caches files upon user access. Caching does not require system administrator intervention except to mount tapes if the requested files have been migrated to manually-mounted media.

After a file is cached, there are at least two copies of the file. The copy on the lower storage layer is not deleted. The copy on the higher layer continues to exist until it is modified by a user or purged from the

Magnetic disk

DiskXtender running onUNIX server

Tape robot

Manually mounted tape

GEN-000880


Introduction


higher layer. The copy on the lower layer will continue to exist until a modified version of the file is migrated to that layer. Modified files supersede previous versions of the files.

Hierarchical file storage system 25

26

Introduction


TerminologyTo understand the administration of DXUL-SM, it is important to become familiar with the terminology. Here is a list of common terms used to discuss DXUL-SM concepts:

◆ archiving

Moving a file to another location.

◆ backup

Creating a copy of the DXUL-SM databases.

◆ caching or staging

Copying files managed by DXUL-SM from a lower layer in the hierarchy to the disk cache layer in the DXUL-SM hierarchy. Also referred to as staging.

◆ capability

Every file managed by DXUL-SM is assigned a unique 256-bit identifier called a capability. The Name Server maps between names and capabilities. When other DXUL-SM servers access a file, they use the capability rather than its pathname.

◆ daemon

UNIX term for a server. DXUL-SM provides two daemons in the UNIX sense of this term, unfsmntd and uftpd. DXUL-SM also provides programs that ensure the availability of servers by providing a persistent execution mechanism:

• cmld

• namesd

• diskd

• taped

• migd

• repackd

◆ disk cache

Collection of disk partitions that comprise the disk (highest) layer of the DXUL-SM hierarchy.


Introduction


◆ disk partition

Disk partition refers to either a physical raw device partition on a disk drive, or a large file in the UNIX file system which is treated as a partition for storing DXUL-SM databases.

◆ families

DXUL-SM mechanism that enables the grouping of files together through the designation of file families. Each file in a family is migrated to secondary storage media only with files from the same family.

◆ file system

Single file system which can span multiple volumes and media types.

◆ journaling

Storing each change to a database in a sequential file. These changes may then be played back to update a prior version of the database.

◆ location

Arbitrary grouping of volumes. Volumes can be grouped by robot, vault, media type, owner, and so on.

◆ media

Class of storage medium used by DXUL-SM to physically store user and backup data. A DXUL-SM system may consist of several types of media.

◆ migration

Copying a file from the highest layer in the DXUL-SM hierarchy to a lower layer in the hierarchy.

◆ mover

DXUL-SM server that moves data from a device to clients or another mover.

◆ offline storage

The storage of volumes in a physical location outside of a robot. Offline volumes need to be manually mounted when needed.

Terminology 27

28

Introduction


◆ online storage

Storage of volumes in an online device such as a robot. Online volumes are automatically mounted by a robotic device when needed.

◆ purging

Deleting files from the highest layer in the DXUL-SM hierarchy after the files have been migrated to a lower layer of the hierarchy.

◆ repacking

DXUL-SM function that attempts to keep the number of unused volumes at a predefined level. Volumes are repacked when they become sparse due to file deletion or file remigration due to modification. The data on the sparse volumes is moved (repacked) to an empty volume, freeing up volumes where the files previously resided.

◆ server

Program that provides services to client programs. DXUL-SM servers are referred to as servers, movers, and the daemons unfsmntd and uftpd.

◆ trash cans

A DXUL-SM safety feature that protects users against accidental file deletion.

◆ vault migration

Moving files to a predefined location. Vaulting can be triggered when there is insufficient space to repack a location in place. This feature may also be utilized to ensure against data loss by allowing media to be removed from the system and stored in a physically remote location. Vault migration is a function of the Repack Server.

◆ volume

Single physical piece of media, which has a label and contains either user data or backup data.


Introduction


DXUL-SM serversDXUL-SM is a collection of servers that run on a UNIX machine. Table 3 on page 29 describes the functions of the servers that manage DXUL-SM.

The DXUL-SM servers work together to provide high-level services. DXUL-SM also provides a collection of client utilities referred to as the Storage System Manager. All of these utilities are available in command line form and many may be used through DXUL-SM System Environment Manager (dxsem) graphical user interface.

The UNIX FTP and NFS daemons access DXUL-SM through the Name Server and the Disk Server. The Name Server executes directory commands and maintains the directory database. The Disk Server stores and retrieves datafiles. The relationship between the

Table 3 Description of DXUL-SM server functionality

DXUL-SM server Function

cmlsrvr Logs messages sent by other servers in a tokenized form.

disksrvr Manages files stored on disk.

diskmovr Moves file data to and from disk.

migsrvr Initiates the movement of files downward in the hierarchy.

namesrvr Manages the UNIX-style directory structure. Maps humanfilenames to machine-resource identifiers (capabilities).

pvrsrvr Manages where tape volumes are located, such as, robot slot ordrive. Initiates mounts and dismounts of tape volumes.

repacksrvr Repacks tapes and migrates (moves) files between differentlayers of secondary storage.

tapesrvr Manages files stored on tape.

tapemovr Moves file data to and from tape.

uftpd DXUL-SM FTP daemon (server) that accesses DXUL-SMthrough the Name Server and Disk Server.

unfsmntd DXUL-SM NFS mount daemon (server) that accessesDXUL-SM through the Name Server and Disk Server.

DXUL-SM servers 29

30

Introduction


DXUL-SM servers described in Table 3 on page 29 is shown in Figure 6 on page 32.


Introduction


User accessUsers can access DXUL-SM through the standard UNIX FTP and NFS protocols without any modification to the FTP or NFS clients that run on the users' machines.

Users view DXUL-SM through the FTP and NFS protocols as a remote UNIX file system. The hierarchical nature of DXUL-SM is visible to the users through two mechanisms, the DXUL-SM FTP dir command and the NFS ls -l command.

User access 31

32

Introduction


Note: The DXUL-SM FTP dir command displays an expanded listing of the designated directory. A special DXUL-SM column in the example below shows whether the file is located on the disk cache (DK) or tape archive (AR)..

Figure 6 Co-operation between the DXUL-SM servers

Diskcache

Manualtape

Taperobot

GEN-000881

CMLserver

Nameserver

Migrationserver

Repackserver

Diskmover

Tapemover

Physicalvolume

repository

FTP/NFSdaemon

Diskserver

Datapath

Datapath

Datapath

Tapeserver


Introduction


For example, if a file exists on the disk cache and on tape (because it has migrated to tape but has not yet been purged from the disk cache), the column will show DK as the resident media. After the file has been purged from the disk cache, the column will show AR (archive) as the resident media. If the file is then cached back to disk, the column will again show DK as the resident media.

Note: Directories will always appear as DK because they are always disk resident (they are never migrated or purged). Also, the family designation on directories is always set to the default (common) family and cannot be changed, since families are used to associate file sets on secondary media and directories are always kept on disk storage.

DXUL-SM provides several special commands through the FTP quote mechanism. Five of these commands are standard UNIX commands:

◆ CHMOD

◆ CHOWN

◆ CHGRP

◆ LN

◆ UMASK

The other commands which are unique to DXUL-SM are:

◆ GTRSH

◆ NMDUP

◆ PURGE

◆ SETFAM

◆ STRSH

◆ SWAP

◆ STAGE

◆ WAIT

◆ OFFLEN

DXUL-SM cannot provide the same added functionality that uses the NFS protocol which is available through FTP. However, NFS provides a transparent user interface for both interactive users and programs. DXUL-SM does provide one feature for NFS functionality. The ls -l command displays a sticky bit on files that have been purged from the disk cache (and therefore reside only on secondary media).

User access 33

34

Introduction


Note: The sticky bit feature can be disabled by the system administrator.


Introduction


Coexistence of DXUL-SM and UNIX file systemsDXUL-SM coexists with the native UNIX file system. However, DXUL-SM and UNIX file systems use different storage devices to store their separate databases of directories and files. DXUL-SM does not utilize the native UNIX file system to store DXUL-SM databases.

DXUL-SM needs disk partitions and a tape allocated to it. Once partitions have been created, a system administrator is not required to run mkfs on these devices. DXUL-SM will overwrite the data placed on the devices by mkfs.

DXUL-SM uses file space, referred to as the “DiskXtender System Tree,” in the native UNIX file system to store its reference manual (man) pages, binaries, configuration files, log files, core files, and utilities. The space for these files and the UNIX directories that contain them were created at DXUL-SM installation. Collectively, these DXUL-SM files and directories in the native UNIX file system are referred to as the DXUL-SM system tree and are described in Chapter 2, “Files and Directories.”

DXUL-SM servers are implemented as UNIX processes, and also use UNIX system resources such as file descriptors, memory, and sockets for communication.

Coexistence of DXUL-SM and UNIX file systems 35

36

Introduction


Root point for DXUL-SM system treeAt installation, a root point for the DXUL-SM system tree was created, which is referred to in this guide by the naming convention <DISKXTENDER>. The root point for the DXUL-SM system tree is the UNIX path to the top of the tree. For example, if the DXUL-SM system tree was installed beginning at the UNIX directory /usr/diskx, the root point of the DXUL-SM system tree <DISKXTENDER> will be /usr/diskx. The DXUL-SM for UNIX installation guide provides more information.

The DXUL-SM daemons, servers, and utilities need to know the root point location where they are installed so that they may access the configuration files. By default they look in the root point /usr/diskx. However, this may be overridden by setting the environment variable DISKXTENDER_ROOT_PATH. When this environment variable is set, all daemons, servers, and utilities use this path instead of the default.



2


◆ Man pages ........................................................................................... 38◆ Binary files .......................................................................................... 39◆ Configuration files ............................................................................. 48◆ Log files ............................................................................................... 51◆ Core files.............................................................................................. 52

Files and Directories

Files and Directories 37

38



Man pagesThe source files for the DXUL-SM man pages are located in <DISKXTENDER>/man/man7. These pages may be accessed through the standard UNIX man utility by setting the MANPATH environment variable to include <DISKXTENDER>/man.

On systems which cannot process nroff files (for example, SGI), preprocessed files are provided in the <DISKXTENDER>/man/cat7 directory.

The DXUL-SM man pages include a windex file, allowing man -k DXUL-SM keyword searches.




Binary filesDXUL-SM binary files can be found in two locations in the DXUL-SM system tree. DXUL-SM servers are located in <DISKXTENDER>/bin, and the DXUL-SM utilities and daemons are located in <DISKXTENDER>/adm/bin.

Figure 7 DXUL-SM system tree

DXUL-SM servers are covered in Table 3 on page 29. The DXUL-SM utilities are discussed throughout this guide. In addition, daemons, servers, and utilities are documented in the man pages.

Table 4 on page 40 lists the binary files and their functions and are sorted by their position in the system tree and their functionality.

Binary files 39

40



<DISKXTENDER>/bin Table 4 on page 40 are the binary files for the DXUL-SM servers and binary executables utilized by the FTP and NFS daemons.

Table 4 DXUL-SM executable files in <DISKXTENDER>/bin

Executable Purpose

cmlsrvr Executable file for the Common Message Logger (CML) Server.

ddir Executable file by the FTP server to execute the ls/dir command.

diskmovr Executable file for the Disk Mover.

disksrvr Executable file for the Disk Server.

migsrvr Executable file for the Migration Server.

namesrvr Executable file for the Name Server.

pvrsrvr Executable file for the Physical Volume Repository.

repacksrvr Executable file for the Repack Server.

tapemovr Executable file for the Tape Mover.

tapesrvr Executable file for the Tape Server.

uftpd Executable file for the FTP server/daemon.

umt Executable file by the Tape Mover to perform tape control functions.

unfsmntd Executable file for the NFS mount daemon.

Table 5 STK robot (page 1 of 2)

Executable Purpose

ssi.sh Shell script to DXUL-SM pathname and network name of machine that controls the STK robot. For more information, refer to <DISKXTENDER>/etc/ssi.sh.default.

ssi Process that controls the issuing of commands to the STK robot.

t_parent Parent process for the STK ssi process.




<DISKXTENDER>/adm/bin

Files in the <DISKXTENDER>/adm/bin directory are executables for the DXUL-SM persistence daemon processes and the various utilities necessary for the following:

◆ Backup

◆ Configuration

◆ Installation

◆ Management

◆ Monitoring DXUL-SM

◆ Recovering the from hardware or media failures

All daemons attempt to keep their related server processes up and running. They start their related processes as child processes and restart all related processes when the daemon detects that one of its processes has exited.

IMPORTANT!The nscr, setmap, disklabel, and zerodisk commands are used to initialize the DXUL-SM databases. Do not type these commands unless certain of the effects. Doing so may result in data loss. See the man pages for more information on these utilities.

fake_el Event logger for the ssi process.

mount_task Utility called by the PVR to mount STK tapes.

dism_task Utility called by the PVR to dismount STK tapes.

Table 5 STK robot (page 2 of 2)

Executable Purpose

Table 6 Daemons (page 1 of 2)

Executable Purpose

cmld CML Server daemon that oversees the execution of the CML Server.

diskd Disk processes daemon that oversees the execution of the Disk Mover and Disk Server.

migd Migration Server daemon that oversees the execution of the Migration Server.

Binary files 41

42



namesd Name Server daemon that oversees the execution of the Name Server.

repackd Repack Server daemon that oversees the execution of the Repack Server.

taped Tape processes daemon that oversees the execution of the Tape Mover, Tape Server, and the PVR Server and optionally STK processes.

Table 7 Initialization

Executable Purpose

setmap Initializes the Tape Server's tapemap.

tapelabel Writes an internal label on DXUL-SM volume.

nsfmt Formats new Name Server disk partitions in order to extend the Name Server database.

nscr Formats the Name Server database.

zerodisk Overwrites and patterns a disk partition. It destroys all information on the disk partition.

disklabel Writes an internal label onto each disk cache resource.

Table 8 Configuration

Executable Purpose

settape Changes Tape Server tapemap fields.

nsau Adds users to the DXUL-SM file system. It opens and reads from the <DISKXTENDER>/etc/adduser file.

ns_gettrash Displays a user's trash can timeout.

ns_settrash Sets a user's trash can timeout.

Table 6 Daemons (page 2 of 2)

Executable Purpose




Table 9 Monitoring

Executable Purpose

checkmap Performs a consistency check on the tapemap block count field.

diskstats Displays Disk Server statistics.

getfilediskstat Used to check if the file is on the disk or not, and whether a file has been Migrated or not.

namestats Displays Name Server statistics.

migstats Displays Migration Server statistics.

pvrstats Displays PVR Server statistics.

readmap Displays the Tape Server's tapemap.

repackstats Displays the Repack Server statistics.

statall Displays the Disk Server's disk cache usage statistics for each partition in the cache.

statup Reports the disk cache partition status and total capacity.

tapestats Displays Tape Server statistics.

tphdrdump Scans the Tape Server database and displays information about all files.

tdspace Reports tape header database utilization.

storping Checks whether a server is responding.

read_log Displays the CML tokenized log in a readable format.

ns_space Used to monitor the space on the Name Server database.

mkfilex Used to test DXUL-SM file system performance.

readtape Reads and tests tapes in DXUL-SM format.

writetape Write test data or copy of another DXUL-SM format tape in DXUL-SM format.

Binary files 43

44



Table 10 Backup and Recovery

Executable Purpose

backup Copies Tape Server data structures (primary tape header and primary search table partitions) to backup volumes.

cleartapeheader Remove an entry from the tape header database only.

ns_quiesce Changes the Name Server state from read-write to read-only mode in preparation for shutdown or backup.

ns_restart Changes the Name Server state from read-only to read-write mode.

ns_rolljournal Changes the Name Journal transaction file currently used to a new one.

ns_insert Insert an entry into the name database.

diskmap Rebuilds the free space maps during disaster recovery.

newsrch Rebuilds the Tape Search table.

logtodsk Restores the Tape Server's file headers from the partial backup log. During disaster recovery, this data is merged with the data retrieved from the full backup tapes.

swapback Provides access to a file copy in the event that the primary file copy resides on an unreadable tape.

tptodsk Restores the Tape Server's file header data, search table, and tapemap from the full backup tapes during disaster recovery.

nsrcrf Re-creates the rootcap and nsrofr files. This utility is for disaster recovery only.

ns_edit Repairs and edits the Name Server databases.

Table 11 Administration (page 1 of 3)

Executable Purpose

cancelstage Cancel a pending or active stage.

chfam Change the family to which a file is assigned.

diskdown Takes a Disk Server disk partition out of service.

diskhdrscan Scans a disk cache partition and reports back information about files on the partition.




disklabel Writes the label on the Disk Server's disk cache partitions and prepares the partition for use by the Disk Server.

disksize Reports the number of blocks for a given disk partition.

diskup Returns to service a Disk Server disk partition that was disabled through the diskdown utility.

dismounttape Dismount a tape from a drive in a SCSI robot where the drive is not currently under DXUL-SM control.

exporttape Export a tape from a PVR Server controlled SCSI robot.

forcemig Forces an immediate migration from the disk cache, overriding existing configuration parameters.

forcepack Forces volumes to be repacked and when necessary, forces migration of files from one secondary storage location to another in order to free volumes and defragment secondary storage volumes.

importtape Import a tape into a PVR Server controlled SCSI robot.

ioctlconf Allows editing of the tape IOCTL configuration file <DISKXTENDER>/etc/ioctl.conf.

mounttape Mount a tape in a drive in a SCSI robot where the drive is not currently under DXUL-SM control.

numdup Change the number of migrated copies of a file.

opermount Notify tape system that an operator mount has occured.

prioritypurge Allows a user to set a file to be marked as a purge candidate.

read_data_file Report the current state of the Repack Server’s datafile.

readlabel Reads the internal label on a volume.

rfset Set the related number of files.

stagefile Stage a file from tape to the disk cache.

tapeconf Allows editing of the tape media format configuration file <DISKXTENDER>/etc/tape.conf.

testlicense Prints the unique system ID and validate license string.


Executable Purpose

Binary files 45

46



testrobot Perform robotic movement and tape mounts in SCSI controlled robotics.

tpdevdown Take a drive down that is currently in use by DXUL-SM.

tpdevup Bring a drive up that is currently configured but down in DXUL-SM.

tpeject Eject a tape from a drive, over ridding regular ejection controls.

tsedit Report and edit Tape Search table information.

cap_to_path Report a file pathname given its unique capability.

check_cmf Verifies the format of the Common Message File (cmf).

log2cml Writes a time stamped log message into the CML tokenized log (token_log).

path_to_cap Given a pathname, return the unique file ID (capability).

show_cmf Displays text messages from the Common Message File (cmf) and the Site Message File (smf) that are used by the Common Message Logger (CML) system.

mkidf Create an interchange datafile.

applyidf Import an interchange datafile.

delidf Delete an interchange datafile.

Table 12 Volume Manager utilities (page 1 of 2)

Executable Purpose

lts_mntpgm Mount program called by the PVR to mount tapes through the Volume Manager.

lts_dismnt Dismount program called by the PVR to dismount tapes through the Volume Manager.

utmtlib 3494 callout library.

mapcon Converts tape map from UniTree version 1.7 to DiskXtender version 2.X.

nscon Convert UniTree name data base version 1.7 to DiskXtender version 2.X.


Executable Purpose




nsconvertchk Print entries in the Name Server data base.

mktdb Make a portable DiskXtender tape header data base image.

applytdb Create DiskXtender tape header data base.

mkndb Make portable name database image.

applyndb Create DiskXtender name database.

Table 12 Volume Manager utilities (page 2 of 2)

Executable Purpose

Binary files 47

48



Configuration filesThe DXUL-SM configuration files are located in <DISKXTENDER>/etc. They are used to configure and tune DXUL-SM to meet the needs of each site. These files are described in Chapter 3, “Configuring DXUL-SM,”and in the man pages. Configuration files for robotic devices and the man pages are discussed in Appendix A, “Robotic Devices and the Volume Manager.”

Table 13 Configuration files in <DISKXTENDER>/etc (page 1 of 3)

Configuration file Function

DBFile Contains cross- reference information used for error message reporting. Do not edit this file.

MessageFile Contains messages for use with error handling routines. Do not edit this file.

PVRINFO Contains the configuration parameters for the PVR Server. The PVR Server reads this file at startup to determine the devices under its control. Robotic devices (SCSI, STK, IGM, MTM, or STL) or the Volume Manager (LTS) must be specified.

DiskXtender.conf Holds the configuration parameters for the DXUL-SM Servers. The Servers read this file upon startup.

DiskXtender.net Contains the network address information for the DXUL-SM Servers.

DiskXtender.path Contains the system pathnames to the DXUL-SM binaries, configuration and log files, and core file directories for the DXUL-SM Servers.

adduser Name Server database file containing system users' information. This file is read by the nsau utility to add new users to DXUL-SM and create their home and .trash directories.

cmf The cmf or Common Message File contains the message number, text and control flags for all messages that are logged to DXUL-SM by the CML Server. This file is used in conjunction with the smf or Site Message File.

diskdevs List of disk partitions that compose the Disk Server's disk cache. This file is read by the Disk Server at startup.




exports List of DXUL-SM directories that can be mounted by remote hosts through the NFS protocol.

family Contains family UID and family GID mappings. Files of the same family reside on the same volume.

ioctl.conf Used to configure the behavior of different tape drives.

kill.diskxtender Used to stop the DXUL-SM daemons and servers.

killbyname Used to stop select DXUL-SM daemons and server by DXSEM.

rc.diskxtender Used to start the DXUL-SM persistence daemons.

rmtab Used by the unfsmntd daemon. This file is generated automatically by the Disk Server (derived from the exports file). Do not modify this file.

rootcap Binary file containing the resource identifier for the root directory of the DXUL-SM file system. Do not modify or remove this file.

smf The smf or Site Message File is a site configurable file intended as an override for a standard message found in the cmf file. The file contains the message number, text and control flags for all messages that are to be cmf overridden. This file need not exist if no site specific messages are specified.

tape.conf Used to define the different media format and behavior of tapes.

tddevs List of disk partitions that the Tape Server uses to store its databases.

diskxtender.login The csh script which contains all of the required DXUL-SM environment variables and paths.

diskxtender.profile The ksh script which contains all of the required DXUL-SM environment variables and paths.

tpdevs List of tape drives dedicated to the DXUL-SM tape processes. If the Volume Manager is in use, the tpdevs file will contain logical tape paths.



Configuration files 49

50



nsdevs List of disk partitions that the Name Server uses to store its internal data structures.

vollblmap Mapping file used by PVRserver. Generated automatically during installation process.

version file Contains DXUL-SM version information.






Log filesThe DXUL-SM daemons, servers, and some utilities write log or trace files into the <DISKXTENDER>/adm/log directory. Log files record the success or failure of many of the operations performed by the processes that write to them.

All servers accomplish logging by communicating with the Common Message Logger Server (cmlsrvr) that writes the server's log messages to a common log file, <DISKXTENDER>/adm/log/token_log (this is a tokenized file). The following have their messages logged in the common log file:

◆ Name Server (namesrvr)

◆ Disk Mover (diskmovr)

◆ Disk Server (disksrvr)

◆ Tape Mover (tapemovr)

◆ Tape Server (tapesrvr)

◆ PVR Server (pvrsrvr)

◆ FTP daemons (uftpd)

◆ Migration Server (migsrvr)

◆ Repack Server (repacksrvr)

The daemons and some utilities that alter databases will write individual log files that are identified by the name of the daemon or utility that produced them with a .t suffix. In the event that the cmlsrvr is down, all servers will write to their respective .t log files, except for uftpd, which must have the cmlsrvr running to perform logging.

Log files 51

52



Core filesThe DXUL-SM servers write core files into individual subdirectories if the servers crash due to UNIX or DXUL-SM errors. Core files are used for investigating the causes of a crash. The core files are located in <DISKXTENDER>/adm/cores.

If DXUL-SM servers are writing core files to the cores subdirectories for unknown reasons, the core files should be left intact for diagnostic assessment by the DXUL-SM vendor.



3

This chapter includes the following sections:

◆ Configuration files in <DISKXTENDER>/etc............................... 54◆ General configuration........................................................................ 63◆ Migration server configuration........................................................ 65◆ Disk mover configuration................................................................. 69◆ Disk Server configuration ................................................................. 70◆ Name Server configuration .............................................................. 80◆ Tape server tape map parameters.................................................... 90◆ Repack server configuration............................................................. 92◆ Resource usage parameters .............................................................. 95◆ Repack action...................................................................................... 97◆ PVR Server configuration ................................................................. 99◆ CML server configuration .............................................................. 100◆ NFS compared with FTP................................................................. 112◆ FTP ..................................................................................................... 128◆ Exports file ........................................................................................ 130◆ Root permissions.............................................................................. 131◆ NFS access toggle ............................................................................. 132◆ Dual NFS ........................................................................................... 133◆ NFS mount options.......................................................................... 134

Configuring DXUL-SM

Configuring DXUL-SM 53

54

Configuring DXUL-SM


Configuration files in <DISKXTENDER>/etcThe DXUL-SM configuration files are located in <DISKXTENDER>/etc. They are used to configure DXUL-SM to meet the needs of each site. The following sections describe each configuration file. Configuration files for robotic devices (NASINFO, SCSIINFO, and STKINFO) are discussed in Appendix A, “Robotic Devices and the Volume Manager.” Man pages are also available on all configuration files.

<DISKXTENDER>/etc/DiskXtender.confThe DiskXtender.conf file holds the configuration parameters for the DXUL-SM servers. The servers read this file upon startup to obtain parameter values that affect operations such as caching, migration, purging, repacking, and trash can operations.

To change the parameter values, edit the DiskXtender.conf file and input the appropriate change. Then signal the appropriate server to reread DiskXtender.conf by issuing the server a SIGHUP.

Table 14 on page 54 describes the parameters that may be set in the DiskXtender.conf file.

Table 14 DiskXtender.conf parameters (page 1 of 9)

Configuration Parameter Range Description/Comments

GENERAL

general.use_nis=1 int: 0 | 1 1 = native UNIX file0 = DXUL-SM specific

general.savecores=1 int: 0 | 1 1 = old cores saved0 = overwritten

general.use_sticky_bit=1 int: 0 | 1 1 = use sticky bit for AR files0 = normal

general.diskserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to disk server.

general.tapeserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to tape server.


Configuring DXUL-SM


general.nameserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to Name Server.

general.diskmover_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to disk mover.

general.tapemover_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to tape mover.

general.migserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to mig server.

general.repackserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to repack server.

general.pvrserver_timeout=15

int: 1-maxint Seconds before timeout reported by other servers talking to PVR Server.

general.wormfs=0 int: 0 | 1 1 = disallow removes of migrated files.

general.wormfs_allowmoves=1

int: 0 | 1 1 = allow moves or renames of files when wormfs is on.

MIGRATE

migserver.split_threshold=1,000,000

int: 1-maxint Number of files per list.

migserver.migrate_fileage=3

int: 1-maxint Must be at least migrate_fileage to migrate.

migserver.migrate_threshold=100

int: 1-maxint Number of new files before migrate runs.

migserver.migrate_wait=60 int: 0-maxint Minutes before migrate is forced to run.

migserver.migrate_wakeup=3

int: 0-maxint Minutes for migration server to sleep.

migserver.file_copies=1 int: 1-15 Number of tape file copies.



Configuration files in <DISKXTENDER>/etc 55

56

Configuring DXUL-SM


migserver.max_filecopies=4 int: 1-15 Maximum number of tape file copies allowed.

migserver.min_filecopies=1 int: 1-15 Minimum number of tape file copies allowed (FTP only).

migserver.min_get_header_timeout=0

int: 1-maxint Total number of seconds allowed to get headers, default is system controlled.

migserver.minimum_migtime=7200

int: 1-maxint Minimum seconds allocated to migrate a single file.

migserver.minimum_thruput=1048576

int: 1-maxint Minimum bytes per seconds required to migrate a single file.

migserver.numdisksrvrs=1 int: 1-32 Number of disk servers to migrate from.

migserver.default_media_type=0

int:0-255 Media type for default migration.

DISKMOVR

diskmover.MaxBufSize=1048576

int:1-maxint Maximum buffer to use for I/O operations.

diskmover.ISDDM=0 int: 0 | 1 Set to 1 if host is a distributed data mover storage node.

DISKSRVR

diskserver.start_data_purge=90

int: 1-99 Start body purge at this % used.

diskserver.stop_data_purge=70

int: 1-99 Stop body purge at this % used.

diskserver.start_hdr_purge=95

int: 1-99 Start header purge at this % used.

diskserver.stop_hdr_purge=80

int: 1-99 Stop header purge at this % used.

diskserver.minimum_disk_time=0

int: 0-maxint Time in minutes that files live on disk before purge is allowed.




Configuring DXUL-SM


diskserver.purge_exp=0.8(alias to diskserver.time_purge_exp)

float: 0-5 Time allowed based on tuning of purge algorithm.

diskserver.purge_zero_files=0

int: 0 | 1 Set to 1 to purge zero length files.

diskserver.size_purge_exp=1

float: 0-5 Parameter to allow size based tuning of purge algorithm.

diskserver.min_purge_size=-1

int:-1 - maxint Min size (bytes) before file may be purged. -1 all files purgable.

diskserver.purge_wakeup_time=5

int:1 - maxint Seconds to sleep between purging scans of the disk cache.

diskserver.HassDDM=0 int: 0 | 1 Set to 1 if the system has storage nodes.

diskxerver.purge_idle_stages=0

int: 0 | 1 Set to 1 to use last accessed time, instead of stage time for staged files.

diskserver.purges_per_scan=10,000

int: 1,000-1,000,000 Set the maximum number of files purged per scan of disk headers.

diskserver.hdr_ratio=0.01 float: 0.001-0.5 Default ratio of disk cache partition to use as headers.

diskserver.rfstages=0 int: 0 | 1 1 = Enable related file set staging.

diskserver.maxrfstages=10 int: 1 - maxint 1 = Enable related file set staging.

diskserver.start_nfs=1 int: 0 | 1 Start NFS 0 is off1 is on.

diskserver.nfs_port=2049 int: 1 - maxint Port to use for DXUL-SM NFS (2049 default).

diskserver.nfsv3_write_threads=8

int:1-64 Number of threads in the disk server processing NFS V3 write requests.

diskserver.nfsv3_write_gather=1

int:0 | 1 1 = write-gathering algorithm0 = write as each request is received.




58

Configuring DXUL-SM


diskserver.MaxNFSWriteCacheMem= 134,217,725

int: 1-maxint Set the number of bytes for write- gathering.

diskserver.ACacheSize=100

int:100 - 2048 Size of directory name cache.

diskserver.ACacheTime=30 int:30 - 300 Expiration time (sec) of directory entry.

diskserver.DCacheTableSize=128

int:0 - maxint Size of data read-ahead cache.

diskserver.BucketLifeTime=0

int:0 - maxint Expiration time (sec) of read ahead cache.

diskserver.BucketSize=65536

int:0 -maxint Read-ahead size (bytes).

diskserver.IsDFS=0 int: 0 | 1 1 = part of DFS0 = stand-alone diskserver.

diskserver.max_nfs_tcp_waits=0

int: 1-maxint Number of times to loop and retry. NFS over TCP.

diskserver.nfs_nfs_tcp_wait_time=0

int: 0-maxint Sleep time before starting next loop (specified in 100ths of a second). NFS over TCP.

diskserver.max_nfs_udp_waits=0

int: 1-maxint Number of times to loop and retry. NFS over UDP.

diskserver.nfs_nfs_udp_wait_time=0

int: 0-maxint Sleep time before starting next loop (specified in 100ths of a second). NFS over UDP.

diskserver.MaxMem Range: 0-2047 Max memory used as read ahead cache.

NAMESRVR

nameserver.run_trash can=1

int: 0 | 1 Trash can enable flag, 0 = off1 = on.

nameserver.trash can_timeout=30

int: 0 - maxint Minutes for default expiration of files.

nameserver.trash can_wakeup=1

int: 0 - maxint Minutes between trash can wake-ups.




Configuring DXUL-SM


nameserver.max_objs_in _cache=5000

int: 1-maxint Maximum number of objects that fit in Name Server memory cache.

nameserver.cache_hash_width=25

int: 1-1000 Number of Name Server memory cache elements in each list.

nameserver.rfsetpropagate=0

int: 0 | 1 1 = Propagate related file set number of directory to new files.

nameserver.journal=0 int: 0 | 1 1 = Enable Name Server journaling. 0 = No Name Server journaling.

nameserver.journal_size=500000

int:1-maxint Maximum number of entries per journal file when name journaling is enabled.

TAPEMOVR

tapemover.IsDTS=0 int: 0|10 | 1 1 = Part of DTS, 0 = stand alone tapemover.

TAPESRVR

tapeserver.unused_for_backups=1

int: 0|1 Whether to use tapes marked as unused in tape map for backup.

tapeserver.start_partbu=30 int: 0-maxint Number of transaction sectors before PARTBU volume used.

tapeserver.num_fullbu_copies=1

int: 1-15 Number of copies of FULLBU data to make.

tapeserver.num_partbu_copies=1

int: 1-15 Number of copies of PARTBU data to make.

tapeserver.license_value=”” alpha-numeric System size limit in bytes, must be a string in quotes.

tapeserver.size_warning_threshold=90

int: 1-99 Percentage of system size at which to start warning messages.

tapeserver.lazy_eject_time=120

int: 0-maxint Idle time in seconds before which eject happens.

tapeserver.min_mig_drives=0

int: 0-63 Minimum number of drives reserved for migration.




60

Configuring DXUL-SM


tapeserver.min_cache_drives=0

int: 0-63 Minimum number of drives reserved for caching.

tapeserver.max_simul_same=1

int: 1-63 Maximum number of same type tapes to use for multiple migration.

tapeserver.mount_retry_time=10

int:1-maxint Seconds before resend mount request to pvrserver.

tapeserver.ping_drives=1 int:0 | 1 1 = Ping all drives on request, 0 = ping only on mount success.

tapeserver.ping_tape_timeout=5

int:1-maxint Seconds to wait before pinging the same drive again.

tapeserver.unload_wait_time=0

int:0-maxint Seconds to wait after unload before attempting to dismount.

tapeserver.id_wait_time=0 int:0-maxint Seconds to wait after load before attempting to read tape.

tapeserver.check_stage_cap=1

int:0 | 1 1 = Verify capability on tape, 0 = do not verify capability.

tapeserver.reset_tapemap_fam=1

int:0 | 1 1 = Reset family to -1 when tape entry block count reaches 0. 0 = Leave family values as is.

tapeserver.reset_tapemap_loc=1

int:0 | 1 1 = Reset location to -1 when tape entry block count reaches 0. 0 = Leave location values as is.

tapeserver.reset_tapemap_cnum=1

int:0 | 1 1 = Reset copy number to -1 when tape entry block count reaches 0. 0 = Leave copy number as is.

tapeserver.reset_tapemap_usage=1

int:0 | 1 1 = Reset usage to UNUSED when tape entry block count reaches 0. 0 = Leave usage as is.

tapeserver.HasDDM=0 int: 0 | 1 Set to 1 if the system has distributed storage nodes.

tapeserver.tape_map_size=10112

int: 10112-500,000 Maximum number of volumes in the system.




Configuring DXUL-SM


tapeserver.id_retry_drives=0

Retry ID on another drive after failure.

tapeserver.id_retry_times=0 Number of times to retry same drive.

tapeserver.max_media_errors=0

Number of errors before media is unavailable.

tapeserver.max_drive_errors=0

Number of errors before drive is marked down.

tapeserver.down_on_dism_fail=0

Set to 1 to mark a drive down upon dismount failure.

REPACKSRVR

repackserver.wake_up=-1 int:-1 - maxint Number of minutes between automatic repacks; -1 for no automatic repacking.

repackserver.loc_vault=1 int: 0-31 Default location for vaulting, 0 means don't vault.

repackserver.last_repack_loc=0

int: 0-255 Last location to automatically repack.

repackserver.free_tape_percentage=20

int: 1-99 Percent tapes specified free in location.

repackserver.in_use_percentage=50

int: 1-99 Maximum tape use percentage for repack candidates.

repackserver.cache_use =500

int: 1-maxint Limit on disk cache use in megabytes.

repackserver.max_cache_streams=1

int: 1-10 Number of tapes to repack simultaneously.

repackserver.last_access=30

int:0-maxint Minimum age in days of files to be vaulted.

repackserver.group_families=1

int:0-1 Group all families into one for determining repack level: 0 is off, 1 is on.

repackserver.group_copies=1

int:0-1 Group all copies into one for determining repack level: 0 is off, 1 is on.




62

Configuring DXUL-SM


repackserver.stage_retries=3

int: 1-maxint Number of times stage requests files before repack of file fails.

repackserver.stage_timeout=7200

int: 1-maxint Seconds until unresponsive stage is retried.

repackserver.split_threshold=1,000,000

int: 1-maxint Threshold to spoilt migration list, enabling multiple repack write tapes.

repackserver.tape_err_cnt=4

int: 1-maxint Number of stage errors before a tape fails and staging stops.

PVRSRVR

pvrserver.dismount_retry_time=60

int: 1-maxint Seconds until dismount is retried.

pvrserver.mount_retry_time=10

int: 1-maxint Seconds until mount is retried.

pvrserver.IsDTS=0 int: 0 | 1 1 = Part of DTS, 0 = stand alone pvrserver.

pvrserver.max_dismount-tries=2160

int: 1-maxint Maximum dismount attempts.

#-----CMLSRVR -----#

cmlserver.severity=5 int: 0-9 Minimum message severity level.

cmlserver.max_log_size=1000

int: 0-maxint Maximum token_log file size in kilobytes.

cmlserver.max_log_age=7 int: 0-maxint Maximum token_log file age in days.




Configuring DXUL-SM


General configuration

general.save cores DXUL-SM saves a core file if a server should crash. By default, it also renames any existing core files to a new name with a timestamp so that older core files are not overwritten. However this renaming can result in a file system containing the core files filling up if a server is crashing repeatedly. To prevent a server rename its core files to a time stamped file, but instead overwrite any existing core files, set the “save_cores” parameter to off (0).

general.use nis By default, DXUL-SM uses its own password and group parsing routines to read the authentication files specified in the DiskXtender.path file. The reason for this usage is that some sites do to give everyone who has access to the DXUL-SM file system a login on the machine on which DXUL-SM resides. By keeping a separate password/group file, these sites can restrict user access to only be through the DXUL-SM FTP daemon, and not through login. However, DXUL-SM can use the standard authentication files and parsing routines, such as /etc/passwd or NIS.

◆ To use the standard system parsing routines, which enables the use of NIS or NIS+, set the use_nis value to on (1).

◆ To use the DXUL-SM specific files, set the use_nis value to 0.

general.use sticky bitWith FTP, users can see whether their files exist on the disk cache, or only on secondary storage by performing a dir command and examining the output for either DK or AR. With NFS, the ls command does not display such information. However, DXUL-SM can provide information back to the user through the use of NFS. The sticky bit should be set On if a file only exists on secondary storage (corresponding to AR in FTP), and leaving it Off if the file resides on the disk cache. However, some sites need to use the sticky bit for its intended purpose. Therefore, DXUL-SM provides a way for the system administrator to use the sticky bit for its intended usage or to either use it to convey file location:

General configuration 63

64

Configuring DXUL-SM


◆ To use the sticky bit to convey file information, set the use_sticky_bit to on (1).

◆ To retain its conventional purpose, set this value to off (0).

general.pvrserver_timeoutDXUL-SM servers maintain TCP connections between each other, even during idle periods. When control messages are passed between the servers, servers use these values for their timeout. Normally these values should not be changed, although if there are networking or other hardware problems, then timeouts may be necessary.

general.wormfs DXUL-SM may be configured to disallow the removal of migrated files, which provide a write-once, read-many (WORM) file system. Files that have not been migrated may be removed. When this option is enabled, migrated files appear as read-only files in directory listings.

general.wormfs_allowmovesWhen DXUL-SM is running with the general.wormfs flag set to On, files may not be renamed or moved by default. When the general.wormfs_allowmoves flag is set to On, renames and moves of migrated files, and remove of migrated files with a link count more than 1 are allowed. This feature allows files and their names to be moved and renamed while ensuring that the contents remain in a WORM state. When this flag is in use, the nameserver.run_trash can should be set to 0, otherwise files may be removed and be placed in the trash can, where they then cannot be removed.


Configuring DXUL-SM


Migration server configuration

File migration File migration serves two purposes for the system administrator:

◆ To back up the files in the Disk Server's disk cache.

◆ To permit the purge operation to keep enough free disk space available on the disk cache for creating new files and caching existing files from lower layers in the DXUL-SM hierarchy.

Tuning the migration parameters involves altering the timing of migration so that both of the purposes of migration are served. Since migration is the backup procedure for the disk cache, the loss of a disk partition will result in the loss of all of the files on the partition that has not migrated. Therefore, it is necessary to accurately tune migration in order to provide a backup copy in case of a disk cache failure. Migration should occur often enough to minimize this risk.

Migration should also occur often enough for the purge operation to be efficient. Only files that have been migrated can be purged. If migration does not occur often enough, files will not be purgable, and the purge operation will not be able to keep enough free space on the disk cache for new and cached files. However, if file migration occurs too often, performance degradation of the system can occur because migration uses Disk Server resources, competing with user requests to the Disk Server.

Accurate tuning of migration parameters to satisfy migration purposes, without causing system performance degradation, is a site- dependent function. There are two migration parameters:

◆ migserver.migrate threshold

The migrate_threshold parameter defines the minimum number of migratable files in the disk cache before migration starts. This value must be a positive decimal integer.

◆ migserver.migrate wait

The migrate_wait parameter defines the maximum number of minutes between occurrences of migration. Migration of every migratable file in the disk cache begins the next time the Migration Server wakes up and either the wait or threshold parameter is met or exceeded.

This value must be a positive decimal integer.

Migration server configuration 65

66

Configuring DXUL-SM


The other Migration Server parameters that control file migration are:

◆ migserver.migrate fileage

This parameter defines the minimum number of minutes after the last file modification of file before that file can be migrated. This prevents migration of incomplete files (for example, files currently being written). For example, during an FTP session, a file could be migrated while it is being written due to a heavy load on the client machine which results in a delay of the FTP transfer. To prevent this occurrence, increase the value of migrate_fileage.

The value must be a positive decimal integer greater than zero.

◆ migserver.migrate wakeup

The migrate_wakeup parameter defines the interval in minutes to wake up the Migration Server. The value must be a positive decimal integer. Automatic migration of files will only occur at this interval. Manual migration may be accomplished at any time by executing the forcemig utility.

Example 1 File migration

In this example, the parameters are set as follows:

◆ migserver.migrate_fileage = 5

◆ migserver.migrate_threshold = 20

◆ migserver.migrate_wait = 60

◆ migserver.migrate_wakeup = 5

The Migration Server will wake up every 5 minutes to see if it should migrate. A migration will be triggered if either there are more than 20 files marked for migration, or if more than 60 minutes have passed since the last migration. A file must be older than 5 minutes in order to be a candidate for migration.

If users typically create large quantities of small files, then set the migrate_threshold high and keep the migrate_wait parameter the same or increase it. Since the files are small, the disk cache will not be filled as rapidly, so migration can occur less frequently.

If users typically create very large files which rapidly fill up the disk cache, set the migrate_threshold very low, and lower the migrate_wait parameter.


Configuring DXUL-SM


Multiple file instancesDXUL-SM provides the ability to have multiple copies of files stored on different volumes. The copies are created during migration. The Migration Server has three parameters that control the multiple copy feature.

Note: This feature provides the only backup mechanism for file copies. If no copies are created and a volume is lost or destroyed, the data is lost.

migserver.file copies The parameter file_copies sets the default number of multiple copies created for each file migrated. The value must be a decimal integer in the range 1-15. If this parameter is set to 1, the default is the original file only.

migserver.max filecopies The parameter max_filecopies sets the maximum number of copies a user can request for a DXUL-SM file. The value must be a decimal integer in the range 1-15. If this parameter is set to 1, no file copies will be created.

migserver.min filecopies The min_filecopies parameter restricts the minimum number of copies a user can request for a DXUL-SM file. The value must be a decimal integer in the range 1-15.

Note: Individual users can control the number of multiple copies created for their files through a special DXUL-SM FTP command, NMDUP. In addition, the DXUL-SM administrator command numdup command can be used to chance the number of copies created.

Once copies of a file have been written to volumes and the file has been purged from the disk cache, the primary copy is accessed by DXUL-SM when the user requests the file. If the volume that the primary copy is stored on is marked unavailable, one of the secondary copies of the files will be automatically accessed from the volume it resides on.

Note: To force DXUL-SM to access a specific file instance, the swapback utility is used. Refer to the swapback man page for more information.

Migration server configuration 67

68

Configuring DXUL-SM


migserver.min_get_header_timeoutThe min_get_header_timeout parameter should only be used when the migration server reports a timeout trying to get the headers from the disk server. When a very large number of headers are available on the disk cache, the automatic algorithm to compute a timeout may fail. In this situation, the parameter should be used.

migserver.minimum_migtimeThe minimum_migtime parameter defines the minimum amount of time to wait for a file to migrate before returning a timeout. This parameter may not be used if there is serious tape drive contention that may keep tapes from being mounted for migration for long periods of time.

migserver.minimum_thruputThe minimum_thruput parameter defines the minimum data transfer rate in bytes per second. If this rate is not maintained, and the minimum_migtime has passed, a timeout error will be reported. This value may need to be increased when using remote tape drives.

migserver.default media typeThe default_media_type parameter defines what media type to migrate files to in the absence of an administrator-defined rule set. The default_media_type must be one that exists in the tape.conf file (type 0 is predefined) and has volumes available for migration in the tape map. “Dynamic migration using the media switch” on page 144 provides an explanation of the administrator defined rule set.

migserver.num disksrvrsThe migserver.num value is used for the DXUL-SM Departmental File Server and should be left at the default value of 1 unless the DFS is running.


Configuring DXUL-SM


Disk mover configuration

diskmover.MaxBufSizeThe MaxBufSize parameter controls the buffer size used by the disk mover double buffering scheme. This parameter should only be modified at the direction of a DXUL-SM vendor.

Disk mover configuration 69

70

Configuring DXUL-SM


Disk Server configuration

Purge parameters The Disk Server uses purging for two purposes:

◆ To provide enough free space on its disk cache for the creation of new files.

◆ To allow for the caching of existing files from the lower layers in the DXUL-SM hierarchy.

There are eight parameters which control the purge task.

diskserver.start data purgeThe start_data_purge parameter is the high-water mark for disk file data use. Once the disk file data space on the disk cache reaches this percentage of use, the disk cache will be purged. The value must be a positive decimal integer in the range 1–99.

diskserver.stop data purgeThe stop_data_purge parameter is the low-water mark for disk file data use. Once the disk file data space on the disk cache has been purged to this percentage of use and the disk header space is below the stop_hdr_purge percentage, the disk cache purge will be terminated. The value must be a positive decimal integer in the range 1–99.

diskserver.start hdr purgeThe start_hdr_purge parameter is the high-water mark for disk header use. Once the disk cache header space reaches this percentage of use, the disk cache headers will be purged. The value must be a positive decimal integer in the range 1–99.

diskserver.stop hdr purgeThe stop_hdr_purge parameter is the low-water mark for disk header use. Once the disk cache header space has been purged to this percentage of use and the disk file data usage is below the stop_data_purge percentage, the disk cache header purge will be terminated. The value must be a positive decimal integer in the range 1-99.

diskserver.minimum disk timeThe minimum_disk_time parameter is the minimum amount of time in minutes that a file must reside on disk before it is eligible to be


Configuring DXUL-SM


purged from the disk cache. This parameter applies to all files in the cache. The value must be a positive decimal integer.

diskserver.purge exp (alias for diskserver.time_purge_exp)The purge_exp parameter is used to determine the importance the time of last access when computing a files purge weight as part of the purging algorithm:

◆ A value of less than 1 will cause time of last access to have less importance in determining which files get purged.

◆ A value of greater than 1 will purge primarily on time, using a Least Recently Used algorithm. The value must be a non-negative real number.

diskserver.size_ purge_ expThe size_purge_exp parameter is used to determine the importance of the size (megabytes) of the file when computing a files purge weight as part of the purging algorithm:

◆ A value of less than 1 will cause the size to have less importance in determining which files get purged.

◆ A value of greater than one will cause larger files to be purged as opposed to the files which have been accessed least recently. The value must be a non-negative real number.

diskserver.min_ purge_ sizeThe min_purge_size is used to keep small files from being purged from the disk cache. You can keep these files on the cache if they consume a small amount of disk and take a relatively long time to retrieve in relation to their size. To keep small files on the disk cache, specify the min_purge_size in bytes of the minimum size a file must be to be selected for purging. The value should be set to -1 to allow small files to be purged from the disk cache.

diskserver.purge_wakeup_timeThe purge_wakeup_time is used only when a purge of the disk cache fails to bring the water marks to their low levels. At this time, the disk server will wait for purge_wakeup_time before it attempts to purge again. This value may be increased when migration is not occurring and the disk server is using excessive system resources in an attempt to purge.

Disk Server configuration 71

72

Configuring DXUL-SM


Purge parameter effectsThe start_data_purge and start_hdr_purge parameters represent the percentage of utilized data or utilized header space in the disk cache as a whole that will trigger purging. For example, if the values are 95 for start_data_purge and 90 for start_hdr_purge, then when either of these percentages is reached, purging will begin. These two values are referred to as high-water marks.

The stop_data_purge and stop_hdr_purge parameters are percentages of utilized space that determine when a round of purging activity triggered by a high-water mark will stop. For example, if the value for stop_data_purge is 80 and the value for stop_hdr_purge is 75, then purging will stop when both conditions are met, regardless of which high-water mark initiated the purge. The stop_data_purge and the stop_hdr_purge values are referred to as low-water marks.

The minimum_disk_time, time_purge_exp and size_purge_exp parameters determine which files to purge. Files will not be purged from the disk cache until they have resided on the disk cache for the number of minutes specified by the minimum_disk_time parameter. The purge exponent values determines which files to purge first to reach a low-water mark.

The purge factor is calculated for each file that is a candidate for purging (for example, a file has been migrated and is older than minimum_disk_time). Once the purge factor has been determined for each file, DXUL-SM ranks the purgable files by purge factor. Files are purged in this order until both low-water marks are met or there are no more purgable files.

The algorithm used to compute the purge factor is:

By default, the size_purge_exp is set to 1. In this case, if the time_purge_exp is greater than 1, least recently used files (based upon last access time) will be ranked first for purging. If the time_purge_exp is less than 1, files will be ranked by file size, and the larger files will be purged first. If the time_purge_exp is equal to 1, both factors are considered equally.

purgefactor Size_in_MBsize_purge_exp Access_time_in_hourstime_purge_exp×=


Configuring DXUL-SM


Care should be taken when setting the purge exponents that the purge factors which get calculated do not exceed the value that may be stored in an integer. Doing so will set all files which exceed the value to have the maximum purge factor and all will be purged.

Tuning the purge parametersThe goal of tuning the purge parameters is to avoid system performance degradation caused by purging too frequently or too infrequently. Symptoms of performance degradation caused by inappropriate configuration of the low- and high-water mark settings are shown on Table 15 on page 73.

Suggestions to prevent performance degradation include:

◆ The purging water marks (low and high) should be set somewhat lower for data than for headers to account for the larger variance in the size of datafiles.

◆ The purging water marks (low and high) should be sufficiently separated to accommodate periods of peak activity with a minimum number of purges.

Table 15 Tuning purge parameters

Setting Too low Too high

High-water marks Purging will occur during user's peak access periods, causing performance degradation, since purging competes with users for access to the disk cache.

User access to the system may be effectively denied during purging since there could be insufficient disk space for more user files.

Low-water marks Too many files will be purged off the disk cache to maintain a satisfactory disk cache hit rate. Users will see a slower response time since files may need to be cached from a lower layer.

The disk cache hit rate will not improve significantly and the purge operation will occur more often than is efficient.


74

Configuring DXUL-SM


◆ The data high-water mark should reflect the average size and size variance of files users store in DXUL-SM. In general, as the average file size and variance increases, the data high-water mark should decrease.

◆ The header high-water mark should reflect the average number and number variance (to accommodate periods of peak activity) of files users store in DXUL-SM. In general, as the number of files and number variance increase, the header low-water mark should decrease.

◆ The low-water marks should allow sufficient room for retention of files that are likely to be accessed again within a short time (that is, files currently being edited, chronologically-written files, and so on).

◆ The time_purge_exp parameter may also be set to 1, accelerating the purging of files based on time residence on the disk cache, accelerating the purging of files based on file size. In general, if users create more large files than small files, purging should be based on time. If users create more small files than large files, purging should be based on file size.

To determine the size and number of files written to the disk cache, periodically run the statall or diskstats utility. The statall utility reports the current utilized header space on the cache as a whole and the current utilized data space on the cache as a whole. It also reports the current number of files in the cache. The diskstats -d command displays detailed information about the number of files and headers utilized on each disk cache.

The prioritypurge utility may also be used to mark files as candidates for purging. When this utility is supplied with the DXUL-SM pathname to a file, it sets information in the files header which makes the candidate have a purge factor above any other files. When purging does occur, this file is the first one purged. In addition, options to purge a file immediately, last, and never are supported by the prioritypurge utility. The prioritypurge man page provides more details. Priority purging is also available through the FTP interface.


Configuring DXUL-SM


Disk cache header ratioThe Disk Server stores both file header (that is, inode, metadata, or attribute) information and file data on each partition in the disk cache. The header ratio configuration parameter allows the system administrator to set the ratio of header space to data space on the disk cache partitions.

diskserver.hdr_ratio There is one ratio for all of the partitions. The value of the ratio must fall within the range of 0.001 (0.1 percent)-0.5 (50 percent). Only files in the disk cache have file headers allocated. After a file is migrated and purged from the cache, the file header is released. This value is only used at the time a disk partition is labeled with the disklabel utility.

As more information is learned about the size and numbers of files users store in the system, the hdr_ratio parameter. may be adjusted

A calculation of the approximate minimum data cache header ratio may be made by using the following formula:

Tuning the disk cache header ratioTuning the disk cache header ratio involves setting the header ratio so that the space on the disk cache partitions is used efficiently, given the size and number of files stored in DXUL-SM. For example, if users write large numbers of small files, then the header ratio should be set higher than if users write small numbers of large files. The goal is to avoid wasting either header or data space on a partition by correctly setting the header ratio.

To determine the size and number of files written to the disk cache, periodically run the statall or diskstats utility. The statall utility reports the current utilized header space on the cache as a whole and the current utilized data space on the cache as a whole. It also reports the current number of files in the cache. Disk cache utilization can also be seen from the disk cache thermometers in the main dxsem display. The diskstats -d command displays detailed information about the number of files and headers utilized on each disk cache.

minHeaderRatio partitionSize avgFileSize⁄( ) headerSize×partitionSize

--------------------------------------------------------------------------------------------------------=


76

Configuring DXUL-SM


The procedure for tuning the header ratio, which is described in detail below, involves iteratively moving the files from each partition in the cache to the remaining partitions in the cache and relabelling the empty partition.

To alter the header ratio:

1. Run the statall utility during an idle state (no DXUL-SM users) to determine whether there is enough free space in the cache to accept all of the data from each partition as it is prepared for re-labelling. If there is enough free space, go to step 3.

2. If there is not enough free space in the disk cache to empty each partition iteratively, an immediate migration from the disk cache must be forced. Type the following command:

% <DISKXTENDER>/adm/bin/forcemig -a

Migration will begin immediately.

To determine when the migration round has completed, read the CML token_log file by using the read_log utility. The Migration Server will log when it has successfully completed migrating all of the migratable files off the disk cache.

3. Change the diskserver.hdr_ratio parameter in DiskXtender.conf. The value is a percentage and can range from .001 to .5 (0.1 percent to 50 percent).

Repeat the following steps for each disk cache partition in the diskdevs file:

4. Type the diskdown utility for each partition in diskdevs:

% <DISKXTENDER>/adm/bin/diskdown logdisk

where logdisk is the logical device number of the partition from the diskdevs file.

The utility first changes the access mode on the partition to read-only. It then attempts to move all files that have not been migrated to tape to other partitions in the disk cache. The files that have been migrated are purged from the disk cache because they exist on a lower layer in the hierarchy. If there is enough space for the copy of all data off the partition, diskdown completes the copy operation and returns successfully.


Configuring DXUL-SM


If the diskdown utility returns with an error, the system administrator must run the forcemig utility to force another immediate migration from the disk cache. When migration has successfully completed, rerun the diskdown utility.

5. When the diskdown utility returns successfully, relabel the partitions by running the DXUL-SM disk label utility on each partition in turn:

% <DISKXTENDER>/adm/bin/disklabel -d device_path

The disklabel utility installs the new header ratio value.

IMPORTANT!Run disklabel only after diskdown returns successfully. This utility destroys any existing data on a partition.

Note: Altering the disk cache header ratio parameter may also require altering the purge high-water marks. “Purge parameters” on page 70 provides more information.

6. Now that the new header ratio has been written to disk, bring the disk partitions back online so they will be recognized by DXUL-SM. Type the diskup utility to bring up the disk that was disabled by the diskdown utility. To run diskup, type the following command:

% <DISKXTENDER>/adm/bin/diskup logdisk

where logdisk is the logical device number of the partition in the diskdevs file. Once this command is executed, the partition is online. Use the statup utility to confirm the status of the partition.

Related file staging DiskXtender allows files to be grouped into related file sets. After one file of a set is staged, all other files in the same directory that are in the related file set can be staged by using the related file staging package. A file may be assigned to a set by using the rfset utility or the ftp command rfset. A directory may also be assigned to a set, and when the nameserver.rfsetpropagate parameter is enabled, files created in that directory and any new directories will inherit that set.

diskserver.rfstages The rfstages parameter enables DXUL-SM related file set staging. When a file is staged, any other files in the same directory belonging to the same related file set will be staged.


78

Configuring DXUL-SM


diskserver.maxrfstage The maxrfstages parameter controls the number of concurrent stages to perform for each related file set stage. This ensures that a system does not become flooded with requests in case related file staging is used on very large sets.

NFS tunables

diskserver.start nfs The start_nfs parameter enables DXUL-SM NFS at disk process startup. The parameter may be set off (0) or on (1). If this parameter is off, NFS access will be denied.

diskserver.nfs_port The nfs_port is used to define an alternate port for DXUL-SM to set its NFS daemons to On. By default, NFS runs on port 2049. However, if you run dual NFS, the systems NFS daemons will run on port 2049. You must select a different port number on which to run the DXUL-SM NFS daemons.

Note: Some systems require the disk server to run as the root user to register the NFS daemons on port 2049. Setting the disksrvr executable to be owned by the user root and set-uid (chmod +s <DISKXTENDER>/bin/disksrvr) will meet this requirement.

diskserver.nfsv3_write_threadsThe DXUL-SM NFS V3 server provides support for asynchronous NFS write calls. This leads to improved NFS write performance. The nfsv3_write_threads parameter determines the number of background threads that are processing NFS write calls. Increasing this number will cause NFS writes to be processed more quickly.

Note: Be careful when setting this value. If set too high, memory or process paging can result in memory or process paging.

diskserver.nfsv3_write_gatherThe DXUL-SM NFS V3 server will collect write requests in memory, order them, and then write them to the disk in large blocks. Since NFS V3 usually writes in 32 KB chunks, and the chunks are not always in order, and can provide a significant speed improvement by using the disk resources more efficiently. Each write thread will use up to 2.5 MB of memory when write-gathering is enabled. The write-gathering algorithm also attempts to write a single file with each thread, so if a large number of simultaneous writes are


Configuring DXUL-SM


occurring, more write threads may be needed or write-gathering should be turned off.

diskserver[ACacheSize, ACacheTime, DCacheTableSize, BucketLifeTime, BucketSize, MaxMem]

These values pertain to the read-ahead NFS buffer cache. They are described in detail in “DXUL-SM NFS server data cache” on page 135".

diskserver.IsDFS Keep the diskserver.IsDFS parameter Off unless this disk server is the remote part of a Departmental File Server (DFS).

diskserver.drop_ejukeboxValues are 0 or 1. By default, this value is disabled, but enabling it by setting to 1 will enable working of the disk server with the solution involving DXNAS and recall from the Celerra the files that have been offlined.


80

Configuring DXUL-SM


Name Server configuration

Trash cans DXUL-SM provides a trash can safety feature to protect users from mistaken file deletions. Files deleted from a user directory are moved by the DXUL-SM Name Server into a subdirectory called .trash in the user's DXUL-SM file system home directory. Every time a user is added to the DXUL-SM <DISKXTENDER>/etc/adduser file, the nsau utility is runned and a .trash directory is created for each new user.

When a file is deleted, it will be moved to the .trash directory of the user who deleted the file. If no .trash directory exists for that user, the file will go into the .trash directory of the owner of the directory that file was in. If no .trash exists for that user, the delete will be final. For example, if the user root deletes a file from user Bob's home directory, the file will be moved to root's .trash directory. If root does not have a trash can, the file will go into Bob’s .trash directory. If user Bob has no trash can, the deletion will be final.

Entries will remain in a user's .trash directory for a length of time called the timeout period. The timeout period runs individually for each file in .trash. Timeout periods can be individually set for each .trash directory. When the timeout period expires, the Name Server deletes expired entries from the .trash directory. Deletions from .trash are final.

When the Name Server inserts an entry into .trash, it lengthens the entry name by adding two ASCII strings to it:

◆ The first string is the date the entry was inserted into the .trash directory.

◆ The second string is a global counter.

This prevents name conflicts in .trash should a user delete several files of the same name from different directories at the same time. The date string also tells the user when the timeout period began for that entry. The string components of a .trash entry name are separated by the # character.


Configuring DXUL-SM


Example 2 Trash can entries

The .trash entries for two filenames that were deleted from two directories during the same second appear as:

foo#04-01-97#14:47:33PST#0013

foo#04-01-97#14:47:33PST#0014

Unlike filenames in standard UNIX directories, .trash entries in DXUL-SM directories can be of unlimited length.

Commands used with trash cansTable 16 on page 81 describes the trash can commands and operations.

Users can retrieve entries from their .trash directories prior to the expiration of the timeout period by using FTP or NFS commands. Users can also list the contents of .trash and delete entries from their .trash directories. Deletions from .trash are final.

Note: FTP and UNIX commands may not accept filenames beyond some local system limit (for example, 255 characters).

There are commands that cannot be used on the .trash directory. Users cannot delete, move, or rename the .trash directory. Only the superuser may remove .trash directories. Users cannot rename entries in .trash, since the trash can depends on the date string to determine when the timeout period has expired for each entry. Also, users cannot insert entries directly into .trash directories through commands such as mv, cp, or put.

Table 16 Trash can commands

Trash can operations FTP commands NFS commands

List the contents of .trash dir ls

Retrieve files from .trash get cp or mv

Delete entries in .trash del rm

Name Server configuration 81

82

Configuring DXUL-SM


Trash can parametersThe DiskXtender.conf file contains configuration parameters for the Name Server's trash can functionality. The trash can parameters are:

◆ nameserver.run_trash can

◆ nameserver.trash can_wakeup

◆ nameserver.trash can_timeout

The Name Server wakes up periodically to check a trash can destruction queue to determine if entries need to be deleted from any .trash directories. The trash can_wakeup parameter tells the Name Server how often it is to wake up and check the destruction queue for work. The trashcan_timeout parameter is the default timeout period for entries in .trash directories. Both the value for trashcan_wakeup and the value for trashcan_timeout are integer decimal minutes.

The run_trashcan parameter is a switch that allows the trash can feature to be disabled (set to 0) or enabled (set to 1) for the system. If this feature is disabled, file deletions will be immediate.

Changing the trashcan wakeup intervalThe value chosen for the trashcan_wakeup interval can affect the length of time that entries remain in .trash directories, so the value should be chosen carefully. For example, if the default timeout period is 15 minutes but the wakeup interval is 30 minutes, then entries can remain in .trash directories for almost 45 minutes. This 45-minute period will occur if the 15-minute timeout is almost, but not quite, ready to expire when the Name Server wakes up. Since the timeout period has not expired, it will simply go back to sleep for another 30 minutes. When it wakes again, the entries will be deleted.

To change the trashcan_wakeup interval, edit DiskXtender.conf and change the value assigned to the trashcan_wakeup parameter. The value is in integer decimal minutes. Then send a HUP signal to the Name Server to make it reread DiskXtender.conf. For example:

% kill -HUP pid[namesrvr]

Changing the default timeout periodTo change the default timeout period, edit DiskXtender.conf and change the value assigned to the trashcan_timeout parameter. The value is in integer decimal minutes.


Configuring DXUL-SM


After the editing is complete, send a HUP signal to the Name Server to reread DiskXtender.conf.

Changing the timeout period for individual usersThere are two ways to change the timeout period for a user of DXUL-SM. The first method can only be used by individuals who have access to the machine where DXUL-SM is hosted. The second method is available through FTP to each user accessing DXUL-SM.

◆ To change the timeout period for a single user, use the ns_settrash utility. This command will only succeed if the user executing it is either the user specified on the option line or the superuser:

% ns_settrash user_name number_of_minutes

Use the -n option for ns_settrash if the standard UNIX password parsing routines and files are being used.

For example, to change the timeout period for user bob to 60 minutes, type:

% ns_settrash bob 60

The ns_gettrash utility may also be used to see an individual's timeout interval in minutes.

For example, to see user bob's timeout, type:

% ns_gettrash bob

◆ Type the FTP command STRSH (set trash). The timeout period will be changed for the user who types the command.

Using FTP:

FTP quote STRSH time

Where time is in minutes.

For example:

FTP quote STRSH 60

The users may also use the FTP command GTRSH (get trash) to see their timeout interval in minutes.

Using FTP:

FTP quote GTRSH


84

Configuring DXUL-SM


Name Server cache parameters

nameserver.max objs in_cacheThe max_objs_in_cache parameter is used to specify the number of directory objects to keep in the memory cache used by the Name Server.

nameserver.cache_hash_widthThis parameter sets the maximum number of entries for each hash list used in the Name Server memory cache. Setting the value too large will slow down accesses to objects in the memory cache. Setting the value too small will cause entries to be purged from the memory cache prematurely. You can type commands, and run programs and utilities to view Name Server memory cache statistics.

Name Server related file set parameters

nameserver.rfsetpropagateThe rfsetpropagate parameter enables the propagation of related file sets to new subdirectories or files. A directory may be assigned a related file set number by using the rfset utility or ftp command rfset. When a new file or directory is created in this directory, that object will have the same set.

Name Server journal parameters

nameserver.journal The journal parameter is used to enable Name Server journaling. When this feature is enabled, each transaction that is performed on the name database is also written into a journal file. The filename is specified in the DiskXtender.path file under the PATH/NAMEJOURNAL entry.

The journal file is used to bring an old snapshot of the name database up-to-date by applying the transactions to the old name data base. The ns_edit utility journal option applies journal files to the name data bases.

The ns_rolljournal command should be executed just before a snapshot is made of the name data bases. This will start a new journal series, and once the snapshot is complete, prior journal files may be discarded.


Configuring DXUL-SM


The name data base journaling option allows backups to be performed without putting theName Server into a read-only mode during the snapshot. It also provides data security, since the journal will contain all of the changes since the snapshot. However, name journaling can use a large amount of disk space on active systems and will slow down all Name Server activities.

nameserver.journal_sizeThis parameter controls the maximum number of transactions that will be written into the current name database journal file before it is closed, renamed with a timestamp, and a new file is started. This feature allows for reasonable size journal files to be created and older files to be copied off machine for data safety. Each journal transaction requires 1 KB.

Tape mover configuration

tapemover.IsDTS This parameter should only be set when this tape mover is a remote part of a distributed tape system.

Tape server configuration

tapeserver.unused_for_backupsThe unused_for_backups parameter instructs DXUL-SM whether to use tapes:

◆ That are marked in the tapemap as being UNUSED for writing its backup information.

◆ Tapes marked explicitly for that purpose.

If the value is set to 1, a volume marked as UNUSED may be used for backup purposes. A value of 0 restricts use of volumes marked FULLBU or PARTBU. “Backup procedures” on page 172 provides more information.

tapeserver.start_partbuThe start_partbu parameter instructs DXUL-SM how many tape header database transactions to store on disk before writing to a PARTBU volume. Each sector holds 11 transactions and the default number of sectors is 30. This value may be adjusted to increase or decrease the number of PARTBU volume mounts that occur.


86

Configuring DXUL-SM


tapeserver.num_fullbu_copiesThe num_fullbu_copies parameter instructs DXUL-SM how many copies to make of each full backup set. The default is 1, but sites with multiple robots and media types may make a second copy on an alternate media.

tapeserver.num_partbu_copiesThe num_partbu_copies parameter instructs DXUL-SM how many copies to make of each partial backup set. The default is 1, but sites with multiple robots and media types may make a second copy on an alternate media.

System sizing constraintsDXUL-SM vendors restrict the size of the DXUL-SM file system by setting an encrypted “license value” on their customer's system. This value sets the maximum allowable size for system storage. The value is then decrypted and checked by the Tape Server each time DXUL-SM migrates a file. The current and maximum amount of data that may be stored can be viewed with tapestats -l.

Multiple copies of a file will affect the system size variable, as each copy of the file is counted against the system size limit.

The Tape Server maintains a system size variable (in bytes) that is incremented and decremented for each file that is migrated to or deleted from tape. The size_warning_threshold value is set as a percentage of the licensed system size.

When the number of bytes of data equal to this value are stored to secondary storage, warnings will be issued for each percentage point over this limit. If the system migrates data to secondary storage equal to the maximum license limit, migration will no longer succeed and an error message will be issued upon every attempt by the Tape Server to migrate data.

Files can still be stored and retrieved to the disk cache until it becomes full. Users can delete unnecessary files to re-nable migration.

The trash can mechanism may delay the actual deletion of files (when a user deletes a file, the file is moved into the user's trash can for a configurable length of time), so the system size may not be immediately updated.


Configuring DXUL-SM


There are two parameters to regulate the system sizing constraint.

tapeserver.license_ valueThe license_value parameter defines the maximum allowable size for system tape storage. This encrypted value is supplied by the vendor. If none is supplied, the value will default to the vendor's demonstration size.

tapeserver.size_ warning_thresholdThe size_warning_threshold parameter sets the percentage of DXUL-SM tape capacity at which the first warning message appears. At 100 percent capacity, DXUL-SM will no longer migrate files from the disk cache.

Drive allocation DXUL-SM supports the multiple simultaneous operation of all media drives installed and allocated to DXUL-SM (drives listed in the <DISKXTENDER>/etc/tpdevs file). The Tape Server has parameters to specify the number of drives to reserve for the migration and caching functions. This provides the flexibility to assure preferential treatment of a given function (migration or caching) with the highest administrative priority.

Three parameters regulate multiple simultaneous migration. In addition, detailed settings are available for configuring drives for use for migration and staging. “Format of tpdevs” on page 123 and “Format of tpset” on page 125 provides more information.

tapeserver.min_ mig_ drivesThe tapeserver.min_mig_drives parameter specifies the reserved minimum number of drives allocated to the file migration function. The default value is 0, meaning no drives are reserved for migration. The migration will still occur, but another function can have a higher priority. Migration may be delayed until the other function has completed.

If rapid storage of large quantities of incoming data is the priority, set the min_mig_drives value high. Do not exceed the total number of tape drives minus one.

tapeserver.min cache drivesThis parameter specifies the reserved minimum number of drives allocated to the file caching function.The default value is 0, which means no drives are reserved for caching. The caching will still occur,


88

Configuring DXUL-SM


but another function may have a higher priority and file caching may be delayed until the other function has completed.

If a quick response to cache requests is the priority, set the min_cache_drives value high. Do not exceed the total number of tape drives minus one.

tapeserver.max_simul_ sameThe max_simul_same parameter specifies the maximum number of drives to be simultaneously allocated for migration of files with identical parameters, specifically, files of the same location, family and copy number.

The default value of this parameter is 1 (only one volume of each type may be in a drive at one time). When set to 1, if a large number of files with the same location/family/copy number combination are being migrated, the Tape Server will use only one drive for the migration of the files for the family even if another drive is available for migration.

If the value of max_simul_same is greater than 1, the Tape Server can utilize more than one drive for volumes belonging to a given family (where the copy number is the same). This feature will only occur when another drive is free. If a large number of files belong to the same location/family/copy number combination, this parameter should be set to a value greater than 1.

IMPORTANT!The combined value of max_simul_same and min_cache_drives cannot exceed the total number of tape drives. The combined value of min_mig_drives and min_cache_drives cannot exceed the total number of tape drives. If these two conditions are not met, then the tapesrvr does the following: both mig_mig_drives and min_cache_drives are set to 0, and max_simul_same is set to 1.

If one tape of a particular location/family/copy number combination is being written to drive 1, and a file of the same combination is the next tape to be migrated, the file could be written simultaneously to another volume of the same combination in drive 2 while other files are being written to the volume in drive 1.

In order for this to occur, the following conditions must exist:

◆ The max_simul_same parameter value is greater than 1.

◆ Another drive (in this example, drive 2) must be free.


Configuring DXUL-SM


◆ min_cache_drives must be available.

◆ A backlog of files is waiting for drive 1 that is greater than twice the migserver.migrate_threshold value.

Drive allocation parametersSample setting for Tape Server Drive Allocation parameters:

◆ tapeserver.min_mig_drives= 2

◆ tapeserver.min_cache_drives= 1

◆ tapeserver.max_simul_same= 2

Given that the total number of tape drives is equal to 5, the above parameters determine the following:

◆ The maximum number of drives that can be used for migration is three (two drives are reserved plus the unallocated drive).

◆ The maximum number of drives that can be used for caching is two (one drive is reserved plus the unallocated drive).

◆ A maximum of two drives can be used to mount tapes for the same location/family/copy number combination simultaneously.

◆ One drive is left unallocated to handle any waiting function (migration, caching, repacking and/or backup).

tapeserver.lazy_eject timeoutThe lazy_eject_timeout parameter defines an interval in seconds after which an eject may occur on a drive. If a drive has been idle for at least the specified interval, the volume may be ejected from the drive. This feature is useful if files in a directory (which are not on the disk cache) are being processed in a sequential mode. (For example, through NFS a user is running a cat * command.)

The stage requests are being received only after the data from the previous file has been processed. This would normally result in the tape being dismounted between the finishing of the stage of the previous file, and the stage of the current file. However, by setting the lazy_eject_timeout, the stage request for the current file will be sent before it is time for the volume to be ejected, saving the time to mount and load the volume.

Note: The lazy_eject timeout and an aggressive_eject timeout may be set on a per drive basis. “<DISKXTENDER>/etc/tpset” on page 125" provides more details.


90

Configuring DXUL-SM


Tape server tape map parameters

tapeserver.reset_tapemap_famFlags to control if a CACHE tape family is set to -1 when its block count reaches 0. A value of 1 enables this feature.

tapeserver.reset_tapemap_locFlags to control if a CACHE tape location is set to -1 when its block count reaches 0. A value of 1 enables this feature.

tapeserver.reset_tapemap_cnumFlags to control if a CACHE tape copy number is set to -1 when its block count reaches 0. A value of 1 enables this feature.

tapeserver.reset_tapemap_usageWhen the last block count of a cache tape reaches 0, the Tape Server considers the tape to be empty. At this point the family, location, and copy number may be set to -1, the free pool, and the usage to UNUSED.

To disable any one of these features, set the appropriate reset option to 0. For example, if all of the tapes have been explicitly assigned to families and there is no free pool for families, set tapeserver.reset_tapemap_fam to 0.

tape server parameters

tapeserver.check_stage_capWhen tapeserver.check_stage_cap parameter is on, during the stage of a file the tape server will verify whether the unique file identifier stored in the header block on the tape matches the request. This parameter should always be on unless old format tapes that do not have this information are being used.


Configuring DXUL-SM


tapeserver.mount_retry_timeThe tapeserver.mount_retry_time parameter sets how many seconds the tape server will wait before resending a mount request to the PVR Server. This value should be kept relatively small to ensure that any dropped requests are still mounted in a timely manner. The value may be increased if the load on the PVR Server needs to be reduced.

tapeserver.ping_drivesWhen tapeserver.ping_drives parameter is on, each drive will have a status command run to check if a tape has been mounted in it. Otherwise a drive is checked only after the PVR Server has reported a successful mount.

tapeserver.ping_tape_timeoutThe tapeserver.ping-tape_timeout parameter specifies how many seconds to wait before pinging a drive. Normally this parameter should not be changed, but on some systems like SGI, pinging the drive will bring offline tapes online, causing DXUL-SM serious problems. For these types of systems, a timeout of 120 seconds, or at least twice the tapeserver.unload_wait_time and pvrserver.dismount_retry_time should be used.

tapeserver.unload_wait_timeThe tapeserver.unload_wait_time parameter specifies how many seconds to wait after a tape has been unloaded before having a robot dismount the tape. Normally this is 0, but some systems will report that a drive has unloaded before it can be dismounted by a robot. This parameter allows some time for those situations.

tapeserver.id_wait_timeThe tapeserver.id_wait_time parameter specifies how many seconds to wait after a tape has been reported mounted by the PVR Server before attempting to read the tape. Normally this is 0, but this parameter may be used with the tapeserver.ping_tape_timeout setting to alleviate certain system problems.

Tape server tape map parameters 91

92

Configuring DXUL-SM


Repack server configurationThe Repack Server has two distinct functions:

◆ To keep the level of free volumes at a specified level by increasing volume utilization

◆ To provide vault migration of inactive files

Volumes are repacked when they have become sparse due to file deletion or when files are remigrated due to modification. The files on the sparse volumes are moved (repacked) to free volumes.

A free volume can be a volume with a zero block count that has been assigned to the location, family, and copy number, or it can be a volume from the free tape pool (a group of volumes that have not been assigned a location, family, and copy number).

Repacking frees up volumes where the files previously resided. After a volume is freed, the volume remains assigned to the location/family/copy number combination it was previously assigned to.

If the Repack Server does not have enough free volumes to repack the location, it will move files to the configured vault location. The vault location is defined by the system administrator. Volumes of a particular type of media may be specified for vaulting by use of a media switch. “Dynamic migration using the media switch” on page 144" provides more information.

Tapes become candidates for repacking based upon the parameters in DiskXtender.conf. When the tape utilization falls below a defined percentage, the tape will be considered ready for repacking.

The following parameters determine the frequency of repacking, the disk cache utilization level, and the tape usage threshold levels that will trigger repacking and vault migration. All parameter settings can be overridden with the use of the forcepack utility.

Repacking parametersThe Repack Server wakes up and checks each location/family/copy number combination to determine the percentage of free volumes. If it finds that the percentage of free volumes is less than the appropriate percentage, the Repack Server will look for repack candidate volumes. Volumes become repack candidates based upon


Configuring DXUL-SM


their percentage of use. Volumes that are currently being used for migration or repacking cannot be repack candidates. If enough repack candidate volumes are found to meet the needed free volume percentage and there is at least one free volume available, volume repacking is triggered.

repackserver.free tape percentageThe free_tape_percentage parameter defines the needed percentage of volumes that are kept free within a location/family/copy number combination. The Repack Server uses this parameter as a target for repacking functions. The value must be a positive decimal integer between 1 and 99.

repackserver.in use percentageThe in_use_percentage parameter is the threshold that defines volume utilization. When the volume utilization percentage for any given tape is less than this threshold, it becomes a candidate for repacking. Utilization is based on the number of active blocks as a percentage of the critical block or the last block written to the volume, whichever is larger. The in_use_percentage value must be a positive decimal integer between 1 and 99.

repackserver.group familiesThe group_families parameter is used when determining if enough free volumes exist and which volumes to select for repacking. If group_families is set to 1, all families are grouped together when making this determination. Otherwise, the families are all calculated as being separate.

repackserver.group copiesThe group_copies parameter is used when determining if enough free volumes exist and which volumes to select for repacking. If group_copies is set to 1, all copies are grouped together when making this determination.

Vault migration parametersIf enough repack candidate tapes cannot be found to meet the needed free volume percentage or there is not at least one free volume available, vault migration is triggered.

Repack server configuration 93

94

Configuring DXUL-SM


Files that meet the minimum age criteria (based on their last_access time) become candidates for vault migration. These files will be moved from their current location to the configured vault location.

repackserver.loc vault This parameter is used to define the destination location for vault migration, referred to as the vault location. A location is an arbitrary grouping of volumes. The forcepack utility can be used to override this and all configuration options and cause vault migration to occur at any time to any location. The value must be 0 or an integer between 1 and 31. If this parameter is set to 0, the vault migration function will be disabled.

repackserver.last accessThis parameter defines the minimum age of a file in days before the file becomes a candidate for vault migration. The Repack Server will look for files on the repack candidate tapes that have not been accessed or modified within the last_access number of days. The value must be 0 or a positive decimal integer. If 0 is selected, all files on the repack candidate tapes will be candidates for vaulting.

repackserver.last repack locThis parameter is used to define the last location the Repack Server should repack automatically. You may not have the Repack Server try and repack all 32 locations in the DXUL-SM hierarchy if:

◆ The site does not have that many locations.

◆ The volumes associated with a particular location may be located off-site or not be immediately available.

This value should be set to the lowest level to be repacked automatically.


Configuring DXUL-SM


Resource usage parametersThe Repack Server has the potential to monopolize DXUL-SM system resources. If the Repack Server tries to repack a large amount of data, it may use up too much of the disk cache and as a result, file caching may not be possible.

If the Repack Server wakes up too frequently, it may affect the performance of other DXUL-SM processes. Therefore, three parameters are provided to control the Repack Server's affect on the DXUL-SM system resources.

repackserver.cache useThis parameter prevents the Repack Server from requesting a group of files that is too large for the available disk cache and keeps the disk cache from being overloaded with repack files.

If during the process of repacking, the total MB of all repack files in the disk cache surpasses the cache_use value, the Repack Server stops requesting the caching of more files while it waits for the files that are already cached to be repacked to new volumes. Caching resumes when the total megabytes used by the repack files in the disk cache falls below the cache_use.

The value of cache_use must be 0 or a positive decimal integer. If 0 is selected, the Repack Server will use as much cache as necessary for repacking.

repackserver.max_cache_streamsThe max_cache_streams parameter defines how many source tapes, streams, will be used for staging files during a multitape repack session. When an automatic repack or forcepack with several tapes is performed, the Repack Server normally starts staging files from the first tape, then the next, and so on.

By setting repackserver.max_cache_streams to be three, for example, then three different tapes will be mounted for staging files.

Note that the Repack Server stages two files at a time per tape. This is to ensure the source tape does not stall and this value is not changed by this parameter.

repackserver.wake up The wake_up parameter defines the interval in minutes between Repack Server wake-ups. The value must be -1 or a positive decimal integer. If the value is set to a positive decimal integer, the Repack

Resource usage parameters 95

96

Configuring DXUL-SM


Server automatically awakens after the specified interval since completion of its last repack or wake-up and perform volume repacking and vault migration.

If the value is set to -1, the Repack Server will not awaken automatically, and repacking can only be accomplished by running the forcepack utility. This feature is used to allow the system administrator to control how often repacking will occur. The forcepack utility also allows for selective repacking of individual tapes and other subsets of the tape map.

If repacking at a specified time of the day/week is appropriate, then the forcepack -w command may be used through cron.


Configuring DXUL-SM


Repack actionVolume repacking and vault migration are distinct functions. Volumes may be repacked with or without vault migration, depending on the circumstances that exist when the Repack Server wakes up. The circumstances fall into the following categories:

◆ If the number of free volumes in a location/family/copy number combination is greater than or equal to the level specified in the free_tape_percentage parameter, neither repacking nor vault migration occurs.

◆ If the number of free volumes is less than the level specified by the free_tape_percentage parameter and repacking the candidate volumes within a location/family/copy number combination will increase the number of free volumes above or equal to the threshold level, then repacking will occur.

◆ If the number of free volumes is less than the level specified by the free_tape_percentage parameter and repacking the candidate volumes will not increase the number of free volumes above or equal to the threshold level, then repacking and vault migration will occur.

Note: There must be enough repack candidate volumes to increase the percentage of free volumes to reach or exceed the threshold level. If there are no free volumes within the pool of volumes and the unassigned pool, then both repacking and vault migration will occur.

Manual control of volume repacking and vault migration, including options for separate handling of volumes by tape ID, location, family, and copy number, is provided by the forcepack utility. The forcepack man page provides further information on use of this utility.

Example 3 If the Repack Server parameters are configured as:

◆ repackserver.wakup_up = 30

◆ repackserver.loc_vault = 1

◆ repackserver.free_tape_percentage = 20

◆ repackserver.in_use_percentage = 50

◆ repackserver.cache_use = 5000

◆ repackserver.last_access = 30

Repack action 97

98

Configuring DXUL-SM


◆ repackserver.group_family = 0

◆ repackserver.group_copies = 0

Repack Server would act as follows:

a. The Repack Server would wake up every 30 minutes and calculate the percentage of free tapes for each location/family/copy number combination.

b. The vault location is defined as location 1 by the loc_vault parameter.

c. The Repack Server will attempt to repack any location/family/copy number combination where less than 20 percent of its DXUL-SM volumes are free (as defined by the free_tape_percentage parameter). A warning will be logged to token_log when the level of free tapes falls below a certain level.

d. All tapes with a tape utilization level of under 50 percent will be candidates for repacking (defined by the in_use_percentage parameter).

e. A maximum of 5000 MB of the disk cache will be used when caching files for repacking (defined by the cache_use parameter).

f. Only files older than 30 days (last_access) will be candidates for vaulting.

Note: The <DISKXTENDER>/adm/tmp/repack_data_file file tracks the status of all files processed by the Repack Server in case the Repack Server is stopped during repacking.

This file is used by the Repack Server to track the status of its requests to the Disk Server and Tape Server, and it should never be modified. After the Repack Server has completed its task, this file is deleted.

To stop a repack:

1. Terminate the Repack Server.

2. Remove the file.


Configuring DXUL-SM


PVR Server configuration

pvrserver.dismount_retry_timeThis parameter controls how long the PVR Server will wait after issuing a dismount request before it will retry the request. The PVR Server will continue to retry until the tape is dismounted.

pvrserver.mount_retry_timeThis parameter controls how long the PVR Server will wait after issuing a mount request before it will retry the request. The PVR Server will continue to retry until the tape is mounted.

pvrserver.IsDTSThis parameter should only be set when this PVR Server is a remote part of a Distributed Tape System.

PVR Server configuration 99

100

Configuring DXUL-SM


CML server configurationThe Common Message Logger (CML) Server is the central process for logging all messages and errors for DXUL-SM. All DXUL-SM servers, unfsmntd and some utilities log messages to the CML Server.

The CML Server receives messages from these interfaces through the ONC/RPC protocol. The message that is sent to the CML Server does not contain the actual text of the message, but instead a token to represent the message. The tokenized messages are written to one log file, <DISKXTENDER>/adm/log/token_log. DXUL-SM provides a utility, read_log, to translate the token log file into text.

CML log file configurationThe following parameters configure the DXUL-SM CML log file, token_log. CML allows DXUL-SM sites to control the amount and level of information logged. Sites can also determine when to create new logs.

cmlserver.severity The severity parameter defines the minimum severity level of messages that are logged in the tokenized log. For example, if this parameter is set to 5, all messages with a severity of 5 and higher are logged to the token_log file. The value must range from 0 to 9.

cmlserver.max log sizeThe max_log_size parameter defines the maximum size that the token_log can grow to be in kilobytes. Once this size is reached, the file is closed, renamed with an appended timestamp, and a new log

Table 17 CML Server Severity

Value Level

9 Panic

8 Severe

7 Warning

6 Recover

5 Info

0-4 Debug


Configuring DXUL-SM


file is started. The value must be a positive decimal integer. If the value is set to 0, this feature is disabled.

cmlserver.max log ageThe max_log_age parameter defines the maximum age that the token_log file can be in days. Once this age is reached, the file is closed, renamed with an appended date stamp, and a new log file is started. The value must be a positive decimal integer. If the value is set to 0, this feature is disabled.

CML server configuration 101

102

Configuring DXUL-SM


<DISKXTENDER>/etc/DiskXtender.netThe DiskXtender.net file contains the IP addresses for the DXUL-SM Servers. Each server accesses this file to learn its own address and the addresses of the other servers so that server communication can proceed.

DXUL-SM permits server IP addresses to be changed after installation. To change an IP address or addresses, edit DXUL-SM.net appropriately, and then restart the entire DXUL-SM system.

Format of DiskXtender.netNETADDR server h1.h2.h3.h4.p1.p2

where:

◆ server is the DXUL-SM server (for example, TAPESRVR).

◆ h1 - h4 is the host IP address.

◆ p1 - p2 is the port for the server. The “p1” number is also used to distinguish multiple instances of DXUL-SM by setting it to 256 minus the instance number. For example, all servers for DXUL-SM instance 3 would have “p1” set to 253 (256-3).

The “p1” and “p2” values are merged to form a 16-bit port number with the formula:

port number = p1 * 256 + p2

Example 4 DiskXtender.net

Table 18 Contents of DiskXtender

IP address Port number

NETADDR MIGSRVR 141.248.100.101.255.32

NETADDR DISKSRVR 141.248.100.101.255.6

NETADDR TAPESRVR 141.248.100.101.255.20


Configuring DXUL-SM


Example 3 is a partial list of the contents of DiskXtender.net. For each entry, the process is specified along with the corresponding IP address and port number.

In the example, NETADDR TAPESRVR refers to the Tape Server. This process has a network address of 141.248.100.101.255.20, where the first four sets of integers (141.248.100.101) comprise the IP address and the last two sets of integers are the port number (255.20 = port number 65300).

The IP address 0.0.0.0 may be used when all components of a DXUL-SM system reside on the same machine. This allows DXUL-SM to use any network address.

<DISKXTENDER>/etc/DiskXtender.net 103

104

Configuring DXUL-SM


<DISKXTENDER>/etc/DiskXtender.path<DISKXTENDER>/etc/DiskXtender.path contains the system pathnames to the DXUL-SM configuration, log, and core file directories for the DXUL-SM Servers. The DiskXtender.path file contains three fields:

◆ Entry type (CORE, PATH, LOG, or STAT)

◆ Process specification, such as TAPESRVR

◆ Corresponding pathname

Note: There is no consistency-check of the DiskXtender.path file. If the entry type, process specification, or path field is improperly modified, servers may crash, communicate improperly, or write log files to /tmp. Only the path portion of the entry should be modified.

Example 5 DiskXtender.path

The above example displays some of the entries for the DiskXtender.path file.

These entries tell the corresponding processes where to locate and put files. For example, the Migration Server will put its core files in the directory /diskx/adm/cores/migrate and will create its log file in /diskx/adm/log.

CORE MIGSRVR /diskx/adm/cores/migrate

CORE DISK /diskx/adm/cores/disk

PATH BINARIES /diskx/bin

PATH CONF /diskx/etc/DiskXtender.conf

LOG MIGSRVR /diskx/adm/log


Configuring DXUL-SM


<DISKXTENDER>/etc/adduserThis Name Server database file contains the system user information. The nsau utility uses the adduser file to add new users to DXUL-SM and create their home and .trash directories.

Format of adduser

For each user that will be given a home directory and trash can, duplicate exactly the username, UID, GID, and home directory pathname information from the password file into the adduser file. FTP access to DXUL-SM fails for users whose home directory in DXUL-SM does not match the home directory specified in the password file.

Example 5 shows the contents of adduser. Three users (george, larry, and bob) are eligible users for DXUL-SM (their entries match the password file).

Example 6 Contents of adduser

They will have their home directories and .trash directories created under the parent directory /diskx/users (for users george and larry)

parent _directory

user1 UID GID permissions trash_can_timeout

user2 UID GID permissions trash_can_timeout

-1 -1 -1 -1 -1

/diskx/users

george 109 410 755 -1

larry 106 410 755 -1

-1 -1 -1 -1 -1

/diskx/labtechs

bob 110 420 755 -1

-1 -1 -1 -1 -1

<DISKXTENDER>/etc/adduser 105

106

Configuring DXUL-SM


or /diskx/labtechs (for user bob). The line containing the -1 fields marks the end of the section.

“User maintenance” on page 153 provides more information.


Configuring DXUL-SM


<DISKXTENDER>/etc/cmfThe cmf or Common Message File contains the message number, text and control flags for all messages that are logged to DXUL-SM by the CML Server. This file is used in conjunction with the Site message file (smf). The smf file is a site configurable file that overrides the standard messages found in the cmf file.

The read_log utility reads the token_log file (which contains tokenized messages), and then reads the cmf and smf files to translate the tokenized message into a user-friendly message.

Format of CMF msg_num brevity lineno severity flag override text

where:

Table 19 CMF format

Generic label Example Definition

msg_num 11011 Message number (1-99999).

brevity 0 Brevity code - A code that determines the amount of information displayed by read_log. Code definition is:0 - Terse1 - Normal message length 2 - Detailed message3 - Further Explanation

lineno 0 Line number - A number that allows multiple lines in a message for each brevity code. There is no limit to the number of lines in a message.

severity 7 Severity - Severity of the message. Where: 9 - Panic8 - Severe7 - Warning6 - Recover5 - Info0-4 - Debug

<DISKXTENDER>/etc/cmf 107

108

Configuring DXUL-SM


Example 7 cmf entry

1101 1 1 0 7 N F Disk is down, Error = $0

Note: Do not modify the cmf file. To customize messages, modify the smf file. The smf file can be made to override the messages in the cmf file.

flag N Control flag - Used by the display processing routines to control display behavior. Where:N - Normal message H - Highlight message (Not implemented)K - Keep message on screen (Not implemented)B - Bell (Not implemented)R - Response required (Not implemented)

override F Override flag - Used to determine if a message will be logged. If the message is logged, the flag is used to determine what message text to display.

text Disk is down Error = $0

Text - The ASCII text for the message with embedded placeholders for each argument.



Configuring DXUL-SM


<DISKXTENDER>/etc/diskdevsThe diskdevs file contains a list of devices (disks or disk partitions) which compose the Disk Server's disk cache. This file is read at Disk Server startup. The Disk Server must be restarted each time the diskdevs file is modified.

The disklabel utility must be run on each device in diskdevs to format and initialize the device for use by the Disk Server.

The disklabel utility will remove all files currently on the device. Verify that the device has no active files on it before running disklabel.

Example 8 diskdevs

This example defines three disk partitions available to DXUL-SM.

The diskdevs describes one device in the DXUL-SM disk cache and has four fields:

1/dev/disk00 25600 4096

2/dev/disk01 59000 4096

3/dev/disk02 25590 4096

logical_device_number Consecutive integer from 1 to 256.

device_path Device pathname.

blocks Number of blocks on the partition or disk.

blocksize Size of the block in multiple of 4K.

<DISKXTENDER>/etc/diskdevs 109

110

Configuring DXUL-SM


<DISKXTENDER>/etc/exportsThe exports file contains a list of DXUL-SM directories that can be mounted by using the NFS protocol. Any directory within the DXUL-SM file system may be exported.

The exports file may be used to restrict access to a particular set of directories and remote hosts. The Disk Server must be sent a HUP signal each time the exports file is modified.

If you are running “Dual” NFS and are exporting both the native file system and the DXUL-SM file system, the “/DISKXTENDER” string must be appended to all DXUL-SM directory names to distinguish them from UNIX directory pathnames.

Format of exports directory_name host_name (permissions, options)

where:

◆ directory_name is the Mount point pathname. (Prepend with /DISKXTENDER if running “Dual” NFS and mount point is a DXUL-SM directory name.)

◆ host_name is the machine that can mount.

◆ permissions are the Permissions for machine.

• rw: Allows mount point to be read and written.

• ro: Allows only read access to the mount point.

◆ options are:

• root_squash: Locks out root access by changing the UID and GID to 60001, “nobody” id.

• no_root_squash: Allows root privileged access to mount directories and files.

Example 9, two machines have permission to NFS mount DXUL-SM at the mount point /diskxtender. The machine maui has read and write permissions, and root has super user privileges. The machine alcatraz has read only permissions, and root has no privileges. This example assumes that you are running “Dual” NFS.

“NFS” on page 129 provides more details on configuring NFS.


Configuring DXUL-SM


<DISKXTENDER>/etc/familyDXUL-SM allows the segregation of files into file family designations. Each file in a family resides on a tape with files of only the same family. The family file contains family-UID (for FTP) and family-GID/NETGROUP (for NFS) mappings.

Volumes can be specifically designated to a particular family or to the free pool. Volumes in the free pool have a family_id of -1, which indicates there is no data on the volume. The family identifier assigned to a volume can be changed if there is no data on the volume.

Files may be assigned to a family before or at file creation time. Once a file has been assigned to a family, its family may be changed with the setfam command. An attempt to set a family to a family_id not in the family file, will default to a family_id of 0 or the “common” family.

The family file allows the system administrator to designate file families. At most 65,535 families may be assigned in addition to the “common” family (default).

<DISKXTENDER>/etc/family 111

112

Configuring DXUL-SM


NFS compared with FTPFamilies are handled differently for NFS and FTP. In order to designate the family for NFS access, a group or netgroup name must be assigned to a family (because the family file uses GID/NETGROUP mapping for NFS access). All files created using NFS with that group will be assigned to the matching family.

To designate a family for FTP access, users are assigned to a family (UID mapping is used). Users may belong to multiple families. However, when a user FTPs to the DXUL-SM site, all files created will by default belong to family 0 (the “common” family). If the user create files that will belong to a family, they must execute the DXUL-SM FTP command, SETFAM, and specify the family with which to associate the file to.

Format of a family file entry

family_name:family_id:#copies:user_name|group.group_name|netgroup.netgroup_name

where:

◆ family_name is a 1 to 15 character ASCII string.

◆ family_id is a positive decimal integer from 1 to 65535. 0 is reserved for the common family.

◆ copies is the Number of copies for nfs created files, use numdup with ftp. 0 is reserved for default.

◆ user_name is a username from the password file.

The other formats used are:

◆ group.group_name—The group name from the systems group file. A group may only belong to one family.

◆ netgroup.netgroup_name—The netgroup name from the systems. A netgroup may only belong to one family.

Files created through FTP by any of the users listed in the addams family will have a family_id of six and the user must execute the DXUL-SM FTP SETFAM command for the family addams before the files are created. Files cannot be placed in the addams family through NFS because there is no group associated with this family.

The family brady allows the users listed to create files through FTP with a family_id of seven. Files created through NFS and which are assigned a group of kids will be assigned to the family brady and two


Configuring DXUL-SM


copies will be made of each file, regardless of the migserver.file_copies setting.

Files created through NFS by users in the partridge group or kigroup netgroup will be in the partridge family and will have a family_id of eight. Files created through FTP by user reuben will be in the partridge family if user reuben executed the FTP command SETFAM for the partridge family.

NFS compared with FTP 113

114

Configuring DXUL-SM


<DISKXTENDER>/etc/rc.diskxtenderThe rc.diskxtender script can be used to start the DXUL-SM system. An entry for rc.diskxtender can be inserted into a UNIX boot time configuration file to start the DXUL-SM system automatically. The DISKXTENDER_ROOT_PATH variable should be set in this file and also the unfsmntd command to be executed.


Configuring DXUL-SM


<DISKXTENDER>/etc/rmtabThe rmtab file is derived from the exports file and is generated automatically by the Disk Server. The file is used by the unfsmntd daemon to determine the hosts that have permission to mount the specified portions of the file system.

IMPORTANT!Do not modify this file.

<DISKXTENDER>/etc/rmtab 115

116

Configuring DXUL-SM


<DISKXTENDER>/etc/rootcapThe rootcap file contains the binary resource identifier for the root directory of the DXUL-SM file system. The rootcap file is created automatically when the Name Server database is created. This file is used by uftpd and other processes to communicate with the Name Server. The file should have read-only permissions to all identities.

IMPORTANT!Do not modify, delete, move, or rename the rootcap file. Without this file, the processes will not be able to communicate with the Name Server. If the rootcap file is accidentally removed, it may be re-created by running the nsrcrf command.


Configuring DXUL-SM


<DISKXTENDER>/etc/PVRINFOThe Physical Volume Repository (PVR) configuration file <DISKXTENDER>/etc/PVRINFO contains the configuration parameters for the PVR Server. The PVR Server reads this file at startup to determine the devices under its control.

If a robotic device (SCSI, STK, or MTM) is specified in PVRINFO, the PVR Server will also read the configuration file associated with that robotic device (SCSIINFO or STKINFO). Appendix A, “Robotic Devices and the Volume Manager,” provides more information.

Format of PVRINFO for 64-bit drive supportname upper32 lower32 (64-bit drive support)

where:

◆ name is the name of the robot system , such as SCSI, and STK.

◆ upper32 is a High-order 32 bits of the device bitmap in hex.

◆ lower32 is a Low-order 32 bits of the device bitmap in hex.

Format of PVRINFO for 128-bit drive supportname upper-upper-32 upper-lower-32 lower-upper-32 lower-lower-32 (128-bit drive support)

where:

◆ name is the name of the robot system (e.g .: SCSI, STK,...).

◆ upper-upper 32 is the high-order higher 32bits of the device bitmap in hex.

◆ upper-lower 32 is the high-order lower 32 bits of the device bitmap in hex.

◆ lower-upper 32 is the low-order higher 32 bits of the device bitmap in hex.

◆ lower-lower 32 is the low-order lower 32 bits of the device bitmap in hex.

<DISKXTENDER>/etc/PVRINFO 117

118

Configuring DXUL-SM


Note: The name OPR is used in the Name field to designate manually mounted tape drives. An OPR entry is required even if no manually mounted tape drives exist.

The bitmap entries must have one bit set for each tape drive in use, represented in hexadecimal starting at the left-most hex digit. The bits must correspond to the logical number to which the tape drive is assigned in the tpdevs file.

To change parameter values (in the event tape drives have been added or removed from tpdevs), edit PVRINFO to reflect the change. Once the file has been edited, the PVR Server must be signaled to reread the file. Send a HUP signal to the PVR Server.

Example 9

If the tpdevs file is as follows:

The PVRINFO file would have the OPR line with bit 1 set and the STK line with bit 2 set. The file would look as follows:

Note: Bit 1 is the most significant bit in the bitmap.

Adding tape drives To add a manually mounted tape drive, edit the tpdevs file and add an entry such as:

3:dev/rmt3h:all={3;*;*;*}:0:120:15#Manual-mount tape drive

and edit the PVRINFO file to appear as follows:

1:/dev/rmt1h:all={3;*;*;*}:0:120:15 #Manual-mount tape drive

2:/dev/mt2h:all={3;*;*;*}:0:120:15 #STK cartridge tape robot

OPR 80000000 00000000

STK 40000000 00000000

OPR A0000000 00000000

STK 40000000 00000000


Configuring DXUL-SM


Removing tape drives

To remove the STK tape drive, edit the tpdevs file and remove the following entry:

2:/dev/rmt2:all={3;*;*;*}:0:120:15#STK tape drive

Renumber the logical tape device number for the third drive:

2:/dev/rmt3h:all={3;*;*;*}:0:120:15#Manual-mount tape drive

Note: Renumbering of the logical tape device numbers after removal of a tape drive is recommended. It is not required.

Then edit the PVRINFO file as follows:

OPR C0000000 00000000

<DISKXTENDER>/etc/PVRINFO 119

120

Configuring DXUL-SM


<DISKXTENDER>/etc/smfThe smf is an optional, site configurable file that is intended as an override for a standard message found in the cmf file. To create site- configurable messages, this file must be created by the site and contain the message number, text, and control flags for all messages that are to be logged to DXUL-SM by the CML Server.

The read_log utility reads the token_log file (which contains tokenized messages) and then reads the cmf file and smf file, if it is present, to translate the tokenized message into a user-friendly message.

Note: The format of smf is identical to the cmf file.

Format of the smf file

msg_num brevity lineno severity flag override text

Table 20 on page 120 explains the format of a smf file and its attributes.

where:

Table 20 smf file format


msg_num 11011 Message number

brevity 0 Brevity code - A code that determines the amount of information displayed by read_log. Code definition is:0 - Terse1 - Normal message length 2 - Detailed message3 - Further explanation

lineno 0 Line number - A number that allows multiple lines in a message for each brevity code. There is no limit to the number of lines in a message.


Configuring DXUL-SM


Example 10 smf entry

11011 1 0 7 N F Error reading header - Error $0

Note: Do not modify the cmf file. To create site- configurable messages, modify the smf file. The smf file will override the messages in the cmf file.

severity 7 Severity - Severity of the message where: 9 - Panic8 - Severe7 - Warning6 - Recover5 - Info0 - 4 - Debug

flag N Control flag - Used by the display processing routines to control display behavior. Where:N - Normal message H - Highlight message (Not implemented)K - Keep message on screen (Not implemented)B - Bell (Not implemented)R - Response required (Not implemented)

override F Override flag - Used to determine if a message will be logged. If the message is logged, the flag is used to determine what message text to display.

text Disk is down error = $0

Text - The ASCII text for the message with embedded placeholders for each argument.


<DISKXTENDER>/etc/smf 121

122

Configuring DXUL-SM


<DISKXTENDER>/etc/tddevsThe Tape Disk Devices (tddevs) file contains the pathnames of the disk partitions that the Tape Server uses to store its internal data structures. Each line in the file describes one partition allocated to the Tape Server.

Format of tddevs logical_device#/partition_pathname block_size

where:

◆ logical_device# is a consecutive integer from 1 to 16.

◆ partition_pathname is the pathname to the partition.

◆ block_size is the partition size in blocks of 4K.

Example 11 Contents of tddevs

There are two types of Tape Server disk partitions: header partitions and search table partitions. Partitions are allocated in multiples of two for disaster recovery purposes. The search table partitions are the last two partitions listed in tddevs. All other partitions in the file are header partitions.

The number and size of the header partitions can be modified. The number of search table partitions cannot be modified and the size of the search table partitions cannot be easily altered after DXUL-SM installation.

1/dev/rrz1h 42590 #primary tape header disk (1)

2/dev/rrz2h 42590 #secondary tape header disk (1)

3/dev/rrz3h 123984 #primary search table disk

4/dev/rrz4h 123984 #secondary search table disk


Configuring DXUL-SM


<DISKXTENDER>/etc/tpdevsThe Tape Devices (tpdevs) file contains the pathnames of the tape drives that are available to DXUL-SM. There may be 64 tape devices used by DXUL-SM. The tpdevs file may also contain the logical names of the devices for use by the Volume Manager. These pathnames are the pathnames for physical devices directly controlled by the PVR or the logical pathnames for devices under the control of the Volume Manager.

Format of tpdevs logical_number:path:opset1={m;f;c;l}opsetn={m;f;c;l}:set:let:aet

where:

◆ logical_number is a consecutive integer from 1 to 64.

◆ path is the absolute pathname to the device.

◆ opset is the operations allowed on the drive. Must be All, Cache, Migrate, Repack, FullBU, PartBU. Multiple opsets may be defined.

◆ m is the media type Numeric value from <DISKXTENDER>/etc/tape.conf file Required with opset.

◆ f is the family number Numeric value from <DISKXTENDER>/etc/family file. Wildcard character of ‘*’ allowed.

◆ c is the copy number numeric value from 0-15. Wildcard character value of ‘*’ allowed.

◆ l is the location number Numeric value of 0-255 Wildcard character value of ‘*’ allowed.

◆ set is the tape set to use from the <DISKXTENDER>/etc/tpset file. Optional. Default of 0.

◆ let is a alternate lazy eject timeout to use. A value of -1 uses the system default from the <DISKXTENDER>/etc/DiskXtender.conf file. Optional. Default of -1.

◆ aet is a aggressive eject timeout to use. When not specified, uses same values as lazy eject timeout. Optional. Default not used.

<DISKXTENDER>/etc/tpdevs 123

124

Configuring DXUL-SM


Example 12 tddevs

When the Volume Manager is in use, the tpdevs file contains the logical names of the devices which are linked to physical device names when a tape is mounted.

Note: Devices controlled by the Volume Manager must appear first in the tpdevs file. Devices must be in an uninterrupted sequential list starting with 1.

1:/<DISKXTENDER>/adm/logicaltapes/tape1:::15 #Volume Manager Tape Drive

2:/dev/rmt/tps4d1nrnsvc:Migrate={4;*;0;*}:1:-1 #DXUL-SM Tape Drive

3:/dev/rmt/0cn:Migrate={5;*;1,2;*}:Cache{5;*;*;*}:1:30:10 #DXUL-SM Tape Drive


Configuring DXUL-SM


<DISKXTENDER>/etc/tpsetThe Tape Set (tpset) file contains configuration information about how many drives are reserved for reading (cache) and writing (migrate, repack, and backup) for a particular tape set.

Drives in the <DISKXTENDER>/etc/tpdevs file may be assigned to a particular tape set. If a matching tape set definition is located in the <DISKXTENDER>/etc/tpset file, the value of the minimum read and minimum write drives overrides those values found in the <DISKXTENDER>/etc/DiskXtender.conf file.

Format of tpset The tpset file contains tape set usage definitions in the following format:

where:

◆ set is a literal string “set”.

◆ set_number is the number of the set being described.

◆ configuration_type is a type of action that the configuration number should override. Valid strings are “min_cache_drives” for read drive reservation and “min_mig_drives” for write drive reservation.

◆ configuration_value is a number of drives to reserve for the specified configuration type.

Example 13 tpset

set set_number configuration_type configuration_value

set 0 min_cache_drives 1

set 0 min_mig_drives 2

set 1 min_cache_drives 2



<DISKXTENDER>/etc/tpset 125

126

Configuring DXUL-SM


<DISKXTENDER>/etc/nsdevsThe Name Server Devices (nsdevs) file identifies all of the primary and secondary (shadow) partitions of the Name Server database. The Name Server shadows each primary copy of its database to protect against failure of a single disk partition. A maximum of 128 partition pairs is allowed.

Format of nsdevs The nsdevs files must contain pairs of partitions in the following format:

primary_partition_path : partition_size

secondary_partition_path: partition_size

where:

◆ partition_path—The pathnames to the primary and secondary partitions.

◆ partition_size— The number of 4K blocks in the partition.

Note: Partition sizes should be the same for each pair. If the primary partition is larger than the secondary partition, the Name Server will not come up. If the secondary partition is larger than the primary partition, then disk space will be wasted on the second partition.

Example 14 nsdevs

In the above example, partitions /dev/rra0f and /dev/rrb0f are the primary partitions. /dev/rra1f and /dev/rrb1f are the secondary partitions.

/dev/rra0f 150000 No of primary partition

/dev/rra1f 150000 No of secondary partition

/dev/rrb0f 200000

/dev/rrb1f 200000


Configuring DXUL-SM


<DISKXTENDER>/etc/xtabThis file describes the local directories that can be mounted by remote hosts through NFS. The xtab file is rebuilt each time the NFS portion of the Disk Server parses the exports file.

The xtab file is used by unfsmntd to verify access to the exported file systems. This file contains the same information as the exports file, but is expanded to contain only one exported directory for each host and some added security information.

IMPORTANT!Do not modify this file.

<DISKXTENDER>/etc/xtab 127

128

Configuring DXUL-SM


FTPChanging FTP access to DXUL-SM involves changing port assignments for the UNIX FTP daemon, ftpd and the DXUL-SM FTP daemon, uftpd. FTP access to a DXUL-SM system may be configured as the default access through the well-known port (port 21) or as a requested access through another port. To ascertain the configuration on the system, look at the configurations set in the /etc/inetd.conf and /etc/services files.

For example, if uftpd was not assigned to the well-known FTP port 21 (default port), and you need to change the default FTP service from ftpd to uftpd, the services file must be edited to assign DXUL-SM uftpd port number 21, and UNIX ftpd must be assigned to an alternate port number.

Once modifications are made to the inetd.conf and services files, the inetd process must be signaled to reread these files. Send a HUP signal to inetd. For example:

% kill -HUP pid[inetd]

When the system is configured in the preceding manner, UNIX ftpd must be accessed with an explicit port number. For example:

% ftp remote_machine port_number

Authentication DXUL-SM supports secure control channel feature for FTP interface to secure authentication and command transmission over the network. The control channel is compliant with SSL protocol version v2 and v3 and the user authentication, commands from FTPS clients (SSL enabled FTP clients) to uftpd of DXULSM and the reply messages from uftpd to the FTPS clients will be encrypted.

For example: during login, FTPS clients will send an AUTH command followed by auth method 'TLS' as an authentication method.

The TLS auth method is common for both SSL and TLS protocols. The actual protocol level (SSL v2, SSL v3 or TLS) will be decided between the client and server.

After validating the authentication type method in FTP server sent by the FTPS client, the uftpd will send a reply as AUTH TLS OK. with 234 as the reply code, if the authentication method is TLS. After this,


Configuring DXUL-SM


the FTPS client and uftpd will do a SSL integration. The login will be successful only after the completion of these security negotiations.

DXUL-SM FTP server supports both standard FTP and FTPS clients. If a client sends AUTH TLS command, DXUL-SM FTP server would recognize that the client is SSL-enabled and proceed for SSL negotiations. If the standard FTP client is used, then the SSL negotiation will not occur and the communication between FTP client and FTP server will not be secure over the network.

Depending on the requirements, a user can access the DXUL-SM FTP either by standard FTP clients (which are not SSL enabled) or by using the standard FTPS clients (which are SSL enabled) to avail the secure control channel communication with the DXUL-SM FTP server.

uftpd Server configurationTo use the SSL-encryption feature for control channel, copy the files in the <DISKXTENDER>/etc directory as follows:

◆ SSL-certificate file as cacert.pem

◆ Private key file as privkey.perm

NFS Tuning the DXUL-SM NFS configuration involves adding or deleting mountable DXUL-SM directories and NFS export hosts, and toggling NFS access to DXUL-SM.

FTP 129

130

Configuring DXUL-SM


Exports fileThe exports file contains a list of DXUL-SM mount points that can be mounted by remote hosts that use the NFS protocol. The exports file may be used to restrict access to a particular set of mount points and remote hosts.

To add or delete mountable directories and export hosts, edit the exports file. Entries in the exports file must follow a specific format, so that the Disk Server will be able to read the file.

Format of exports directory_name host_name (permissions, options)

where:

◆ directory_name is the mount t point pathname. Prepended with the /DISKXTENDER string if running “Dual” NFS and the mount point is a DXUL-SM directory.

◆ host_name is the machine that can mount.

◆ permissions are the permissions for machine:

• rw: Allows mount point to be read and written.

• ro: Allows only read access to the mount point.

◆ options are:

• root_squash: Locks out root access by changing the UID and GID to 60001, for the user “nobody”.

• no_root_squash: Allows root privileged access to mounted directories and files.

The DXUL-SM exports man page provides details on the exports format.

The Disk Server must be restarted or signaled each time the exports file is modified. For example:

% kill -HUP pid[disksrvr]


Configuring DXUL-SM


Root permissionsThe DXUL-SM root_squash mechanism prevents superuser access to DXUL-SM from an NFS client machine. root_squash is set as the default. To give root full superuser privileges, edit exports and insert no_root_squash in the options field of every entry where superuser access is to be allowed.

For example, the following entry in exports enables superuser access to the DXUL-SM /diskxtender directory from the NFS client alcatraz:

/DISKXTENDER/diskxtender alcatraz (rw, no_root_squash)

The following entry in exports explicitly prevents superuser access to the DXUL-SM /diskxtender directory from the NFS client alcatraz:

/DISKXTENDER/diskxtender alcatraz (rw, root_squash)

If the root_squash mechanism is in use, then whenever the client UID or GID 0 accesses the DXUL-SM file system through NFS, the UID becomes the UID of the user nobody, meaning it has the nobody UID or GID identity. As a result, the superuser will only be able to access directories and by files using world permissions.

Root permissions 131

132

Configuring DXUL-SM


NFS access toggleToggling NFS access to DXUL-SM requires editing the DiskXtender.conf file and signaling the Disk Server to reread the file.

In the DiskXtender.conf file, there is a Disk Server parameter called diskserver.start_nfs. The value of this parameter may be 0 or 1. A value of 0 will deny NFS access to DXUL-SM, while a value of 1 will permit NFS access to DXUL-SM.

The Disk Server must be restarted each time the DiskXtender.conf file is modified.

The following NFS tunables require a Disk Server restart:

◆ diskserver.start_nfs

◆ diskserver.nfs_port

◆ diskserver.nfsv3_write_threads


Configuring DXUL-SM


Dual NFSBoth the DXUL-SM file system and the system’s regular UNIX file system can be exported with NFS. To do this, set the diskserver.nfs_port in the DiskXtender.conf file to be a value other than the NFS standard port of 2049. Once this has been done, ensure that the native system’s mount daemons are not running. While there may be multiple NFS daemons running on a given machine, only one mount daemon may be running. The system’s mount daemon does not know about the DXUL-SM file system, but the DXUL-SM mount daemon, unfsmntd, knows about both the UNIX file system and the DXUL-SM file system.

The DXUL-SM mount daemon, unfsmntd, must be started with the -d option to support dual mode NFS. This option tells the mount daemon to service any mount request with pathnames that start with the /DISKXTENDER string from the DXUL-SM file system, and all other mount requests from the UNIX file system.

To mount the DXUL-SM file system by using NFS when running dual mode, specify the DXUL-SM NFS port as an option on the mount line.

Specify:

o port-xxx

where xxxx is the DXUL-SM NFS port number.

For example, if DXUL-SM NFS is running on port 2050, type the following command to mount DXUL-SM:

% mount -o port=2050 hostname:/DISKXTENDER/path_to_mount local_mnt_point

Dual NFS 133

134

Configuring DXUL-SM


NFS mount optionsMost operating systems allow options that specify how a remote file system may be mounted. Such options include which version of the NFS protocol to use, data transfer size, and which networking protocols to use.

Standard options are shown in Table 21 on page 134.

A sample mount command line that uses the recommended values would be:

mount -o \ intr,port=2050,proto=udp,vers=3,rsize=32768,wsize=32768 \hostname:/DISKXTENDER/path_to_mount local_mnt_point

Check your system mount man pages for information on NFS mount options.

Table 21 Standard NFS mount options

OptionAllowable values

Recommended value Explanation

vers 2:3 3 NFS supports both the 2 and 3 protocol. Version 3 has expanded features and better performance.

proto udp:tcp udp UDP NFS mounts perform significantly better than TCP mounts, especially in LAN environments.

intr n/a intr The intr value allows processes to interrupt commands that may be stalled due to NFS timeouts or loss of network connectivity.

rsize 8192-32768 32768 Use of large packet sizes increases performance because fewer packets are transferred.

wsize 8192-32768 32768 Use of large packet sizes increases performance because fewer packets are transferred.


Configuring DXUL-SM


DXUL-SM NFS server data cacheDXUL-SM uses a data read-ahead cache in its NFS server implementation in order to efficiently service client read requests. The data cache is designed to hold not only the data for a particular read request, but a certain quantity beyond in anticipation of subsequent requests. Read performance increases of up to 50 percent have been observed, as well as a significant lessening in the rate of disk I/O on the DXUL-SM server, as a result of the data cache.

The data cache is a hash table of data that has been read from previous NFS read operations. When a read request comes in, based on its file ID, the table is first searched to see if the request can be fulfilled with data that is already in the cache. If there is a cache hit, then the data is copied out and returned to the client, saving the server a disk I/O. If the data is not found in the cache, a disk read is started. The amount to read from the disk is generally much more than the actual request, in the hope that a subsequent read request will want the data. Since most of the disk I/O time is spent on head positioning, the difference in time between reading an 8-KB block and some reasonable multiple, such as a 64-KB block, is negligible.

The data cache was designed to facilitate configuration based on usage patterns. The same basic mechanism can remain useful across a wide range of data requirements such as:

◆ Average file size

◆ Number of different files that are read in a given time period

◆ Rate of concurrent requests for a given file

◆ System memory availability

All the configurable parameters of the data cache are found in the DiskXtender.conf file, and are described in detail in the man pages of DiskXtender.conf. The following is a summary of what those parameters do and how relate to each other.

ACacheSize The Attribute Cache holds detailed information about filename lookups (for example, stat information). Attribute requests for items in the cache are serviced directly from the cache instead of being requested from the appropriate server, which improves directory lookup operations (for example, ls, or ls -l).

DXUL-SM NFS server data cache 135

136

Configuring DXUL-SM


ACacheTime The ACacheTime is the length of time (in seconds) to keep detailed information in Attribute Cache for future lookup. Attributes in the cache may become stale if activity is happening through the FTP interface to DXUL-SM. This timeout prevents items from remaining in the cache for an undetermined period of time.

DCacheTableSize If the server has to fulfill read requests on a large number of different files in a given time, DCacheTableSize should be set large enough to avoid searches down long chains of data blocks during a cache lookup.

BucketLifetime Data that has been read by the client no longer needs to be kept in the cache since that wastes valuable memory that can be used by other read-ahead requests. This number should generally be kept very low, such as one or two seconds.

BucketSize This is the read-ahead amount on the server, and depends on such factors as average size of files that are read, amount of system memory available for data cache, disk drive speed, and so on. If files are approximately 32 KB in size, for example, setting the BucketSize to 64 KB wastes data cache memory. If the server is already short on in-core system memory, then setting the BucketSize too large can force the system to begin paging or swapping, actually degrading the NFS read performance. On the other hand, if the system has in-core memory to spare, the disk drives are fast, and typical files are large in size, then it may be beneficial to use a larger BucketSize.

MaxMem Range is 0-2047. This is the maximum amount of memory to allocate for the entire NFS read-ahead cache, in megabytes.


Configuring DXUL-SM


Tapeconf and Ioctlconf — Configuring tape devicesIn order to allow for new devices and for different site needs, DXUL-SM allows the system administrator to define how archiving hardware performs, and in what format to write the archive media. This functionality is achieved using two configuration files:

◆ ioctl.conf, which controls the behavior of the archive hardware

◆ tape.conf, which defines the format media to be written in

The tapeconf and ioctlconf utilities form a part of the configurable tape subsystem, since they allow new media types to be defined and used by DXUL-SM without requiring changes to be made to the software.

This flexibility is derived from the use of two configuration files, namely <DISKXTENDER>/etc/tape.conf and <DISKXTENDER>/etc/ioctl.conf, which describe the formatting of DXUL-SM tapes and the ioctl(2) system commands which their corresponding tape drives support. These two files may be inspected and modified by using the tapeconf and ioctlconf utilities, respectively. These files are then read at startup of the tape subsystem, and also when using certain utilities which require this information (for example, logtodsk, readlabel, and tapelabel.)

The use of tapeconf and ioctlconf is described in the man pages.

ioctlconf The ioctlconf utility asks the user to answer a list of questions about the archive device being used. By using the ioctlconf utility, a user can modify and delete entries in the ioctl.conf file, and add entries.

Enter index to modify (0-255, default = 0)This feature defines which ioctl set to configure. To modify or delete an existing ioctl set, type the number of the set to modify or delete. For adding an ioctl set, use an index which is not currently in the ioctl.conf file, or listed when you start ioctlconf.

Is this entry in use (y/N, default = Y)This item specifies whether this entry is to be used by the tape subsystem and tape utilities.

Tapeconf and Ioctlconf — Configuring tape devices 137

138

Configuring DXUL-SM


Is device like a disk(0) or tape(1) (0-1, default = 1)This item defines whether the archive drive being used behaves like a disk or a tape:

◆ If the drive behaves like a disk, select 0.

◆ If the drive behaves like a tape, select 1.

Positioning: use fsf/bsf(0), ioctl(1), or lseek(2) (0-2, default = 0)This item defines how the device positions itself:

◆ If the device used the traditional forward space file (FSF) and backward spaced file (BSF)commands, select 0. (Almost all tape drives support this feature.)

◆ If the device supports the ability to locate to a specific block number using the ioctl () system call interface, select 1.

◆ If the device uses the lseek () system call (that is, it behaves like a disk), then select 2.

Does driver accept count parameter (Y/N, default = Y)This item defines whether the drive (and driver for the device) supports the ability to add a count parameter to a positioning command. For example:

◆ If the drive supports the ability to issue a singe FSF command with 16 as a parameter to forward past 16 filemarks, select Y.

◆ If the drive would require you to issue 16 separate FSF commands to forward over those same 16 filemarks, select N.

Write after read: None(0), after TM(1), before TM(2), before/after TM(3), unrestricted(4) (0-4, default = 0)

This defines whether the device is able to issue write commands after reading the tape. Several devices, such as those based on helical scan technology, do not allow this feature. Such a device requires special positioning to reset the drive so it can write.

The choices are defined as follows:

◆ None: Select this option if the driver is unable to write immediately after reading the device. Few drives are this restrictive.

◆ After TM: Select this option if the drive is only able to write if it is positioned immediately after a filemark.


Configuring DXUL-SM


◆ Before TM: Select this option if the drive is only able to write if it is positioned immediately before a tapemark.

◆ Before/After TM: Select this option if the drive is only able to write if it is positioned either immediately before or after a tapemark. If the drive has any restrictions, this option is preferred.

◆ Unrestricted: Select this option if the drive has no restrictions about writing a tape after reading.

Can driver perform bsr (Y/N, default = Y)This parameter defines whether a drive can efficiently perform a BSR (backward space record) command. Some helical scan devices perform BSR very slowly, and it is more efficient to go back an extra filemark and FSR (forward space record) to the correct location. If this is the case, select N. Otherwise, select Y. For disk like devices, select Y.

Sync: None(0), implicit/logical EOF (1), new file (2), buffer(3), user file EOF(4), old style(5) (0-5, default = 4)

Normally the syncing of data is performed automatically by using the most efficient method by DiskXtender. Option 4 should normally be selected. Option 3, the buffer is available to turn on buffered mode for use with the gd disk driver.

Can the driver report positioning info (Y/N, default = N)This determines whether the device can report block count positioning information. This feature is only possible for those devices which use the ioctl() interface for positioning above.

Rewind: on load/unload(0), none on load(1), none on unload(2), none on load/unload(3) (0-3, default = 0)

This feature is not currently used.

Does device support zero-length TM (Y/N, default = Y)This option determines whether the device supports writing zero length tapemarks to sync the drive’s internal buffers. Unless sure that both the device and driver support this option, select N.

Does device have a loadable display (Y/N, default = Y)This option determines whether the device has a loadable display which can show what actions the drive is taking (such as, reading, writing, positioning, and rewinding).


140

Configuring DXUL-SM


tapeconf The tape.conf file determines the format in which a media set will be written. By using the tapeconf utility, the administrator is able to modify or delete entries in the tape.conf file, and add entries.

Do not change the tape configuration of indexes for which volumes have already been written. If the block sizes or blocks between file marks are modified, the tape subsystem will encounter problems when trying to read tapes which are written while using the previous values.

Enter the index to modify (1-255, default = 1)This defines which media set to configure. To modify or delete a media set, type the number of the set to be modified or deleted. To add a media set, use an index which is not currently in the tape.conf file, or listed when tapeconf was started.

Index 0 is hard coded and reserved for by the DXUL-SM system as the official, original DXUL-SM format prior to 1.9. Sets 1-255 are available for use.

Enter the media type This is an ASCII string used only for user identification purposes. It is intended to contain the name of the physical media used.

Enter DXUL-SM vendor This is an ASCII string used only for user identification purposes. It is intended to contain the name of the machine vendor DXUL-SM is installed on (for example, Sun, SGI, HP).

Enter drive product id This is an ASCII string used only for user identification purposes. It is intended to contain the drive name that this media type is written on.

Enter label size in bytes (0-4294967295, default = 80)This denotes the size of the label on the front of the tape. By default, DXUL-SM writes an 80 byte, ANSI compliant label. To write a label of a different size (necessary if the device the media is written on cannot support blocks of data of 80 bytes), then change this value.

Enter after label size in bytes (0-4294967295, default = 15872)This is the size of the three blocks immediately following the two ANSI labels at the start of the media. Traditionally, this value has been set to 15872 bytes (15K + 512 bytes). These blocks do not contain any data and exist mainly for historical reasons and backward compatibility. They may be changed to whatever value is necessary. However, if configuring a media type for the purposes of reading existing data, set this value to the size of the blocks written before.


Configuring DXUL-SM


Enter header size in bytes (0-4294967295, default = 512)This is the size of the header which is written at the start of each data block. The minimum size of this header is 512 bytes.

Enter data block size in bytes (0-4294967295, default = 15360)This value is the actual size of the data portion of the data block written. Historically, this size has been 15360 bytes (15 KB). However, higher performance drives require that larger block sizes be used to achieve optimum performance.

In addition, some tape drives achieve better data compression when larger data block sizes are used. Ensure the size of the data block plus the header is not larger than the maximum block size supported by the drive or the device driver; otherwise performance may actually suffer, or data loss may result.

Enter record size (0-4294967295, default = 15872)This is the size of the record physically written to the media. This value needs to be a multiple of the data block plus the header. Writing for a media type is only supported if the record size is equal to the size of the data block plus the header.

However, in prior DXUL-SM versions, some vendors placed multiple data block/header pairs into a single media record. If this is the case for this media, then this value should be the size of the actual media record previously written.

Enter moverbuffer size (0-4294967295, default = 15872)This is the size of the buffer to allocate in the Tape Mover for reading data into and writing data from. It should be set to the record size.

Enter sysbuffer size (0-4294967295, default = 15872)This feature is not currently used.

Number of blocks between filemarks (0-4294967295, default = 128)This defines the number of tape records to write between tape file marks. Placing more records between filemarks has the effect of increasing throughput when reading and writing the tape, but may slow the positioning of the tape.

Placing fewer tape records between filemarks may slow data throughput, but speed positioning. In general, if the files to go onto a particular media type are large (the size of the file is greater than the


142

Configuring DXUL-SM


data block size multiplied by the blocks between filemarks), then use a larger number.

If the files to go onto this particular media are small, use a smaller number.

First data block number (0-4294967295, default = 128)This is the number of the first data block. Historically, this value has been 128. It may be changed, but must always be larger than 5.

Guaranteed media length in blocks (0-4294967295, default = 0)This value defines the number of data blocks that are guaranteed to fit onto this media. This value is also referred to at the critical tape block. While DXUL-SM will write data to the end of the media, it needs to know how many blocks it can be guaranteed to put on any particular piece of media.

This feature enables files to span tapes, and also is used by the repack server to determine when a particular piece of media is below its repackserver.in_use_percentage value.

In general, estimate this value between 80 and 90 percent of the uncompressed capacity of the media. For fixed-length media, this value should be set to 0.

Media capacity in bytes (-1-9223372036854775807, default = 0)This value is only used for devices where the media is fixed-length. For variable-length media, this should be set to 0. Otherwise, set it to the number of bytes available on the formatted and partitioned media.

When a value of -1 is specified, the size of the media is calculated during the tapelabel. This is the preferred method, since it computes an exact capacity for the current media and drive.

Header type (0-4294967295, default = 0)This field is for future use. Its value should be left at 0.

ioctl set (0-255, default = 0)This value defines the ioctl set, defined in ioctl.conf, to use when accessing the media.

End of media handling (0-3, default = 0)This field is for future use. Its value should be left at 0.


Configuring DXUL-SM


Tape platter treated as 0(default = 0)If the media is a tape, set it to 0.

Is media (default = 0) This may be done after tapelabel has been run on the media. By default, this value is 0, which allows the media to be relabeled at the beginning of migration/repack.


144

Configuring DXUL-SM


Dynamic migration using the media switchDXUL-SM allows the system administrator to determine what type of media a file is migrated to, based on certain characteristics of the file. Using a callout, the Migration Server determines the type of media to migrate a particular file.

This script or program, whose path is determined by the PATH, TAPESWITCH pairing in the <DISKXTENDER>/etc/DiskXtender.path file, is called once for each file to be migrated and is passed the following null terminated strings as arguments:

Mig_type UID GID Family CopyNum Location LastRead LastWrite FileLength

where:

◆ Mig_type is a character string, either “Migrate” or “Repack”, depending on the operation being performed.

◆ UID is the User ID of the file.

◆ GID is the Group ID of the file.

◆ Family is the Family ID of the file.

◆ CopyNum is the copy number being migrated.

◆ Location is the location the file is being migrated/repacked to.

◆ LastRead is the last read time of the file. Specified as seconds since the Epoch.

◆ LastWrite is the last write time of the file. Specified as seconds since the Epoch.

◆ FileLength is the file length in bytes. Specified as two hexadecimal numbers. For example: 0x0 0x22248598 for a file whose length is 23933496 bytes.

The script is then expected to print to standard out (stdout) the media type that the file is to be migrated to. The media type must be a type defined in the tapemap and exist in the tape.conf file. The man pages for readmap, settape, and tapeconf provides more information.

In the absence of a TAPESWITCH script, all files will be migrated to the media type configured in the DiskXtender.conf file as migserver.default_media_type.


Configuring DXUL-SM


Moving the system treeTo move the DXUL-SM system tree after installation to a different UNIX root point, the contents of the following files must be updated with the new root point or DXUL-SM will not operate.

Moving the DXUL-SM system tree should only be attempted by qualified system administrators.

DISKXTENDER_ROOT_PATHIf DXUL-SM is installed or moved to a different directory than the default, /usr/diskx, the DISKXTENDER_ROOT_PATH environment variable must be set. DXUL-SM servers and utilities look at the DISKXTENDER_ROOT_PATH to determine what point to use as the DXUL-SM root for locating configuration files and executables.

System boot script The system boot script was modified at installation to include an entry for the DXUL-SM persistent execution mechanism. This entry includes the pathname to the rc.diskxtender file. Change the pathname in the script to contain the new root point so the persistent execution mechanism will continue to function.

/etc/inetd.conf The inetd.conf file was modified at installation to include an entry for the DXUL-SM uftpd binary. This entry includes the pathname to the uftpd binary.

Complete the following steps to update inetd:

1. Change the uftpd pathname, in the inetd.conf file, to the new DXUL-SM root point so inetd can continue to execute uftpd when requested.

2. Send a HUP signal to the inetd process to cause it to reread the inetd.conf file.

<DISKXTENDER>/etc/rc.diskxtenderThe rc.diskxtender file contains the DISKXTENDER_ROOT_PATH environment variable. Change the pathname to contain the new root point so that servers run from this file will know where to locate configuration files and executables.

Moving the system tree 145

146

Configuring DXUL-SM


<DISKXTENDER>/etc/DiskXtender.pathThe pathnames in DiskXtender.path need to be modified to reflect the new location of the DXUL-SM system tree.



4

This chapter includes the following topics:

◆ DXUL-SM startup and shutdown ................................................. 148◆ DXUL-SM servers ............................................................................ 151◆ User maintenance............................................................................. 153◆ Monitoring use of the System ........................................................ 158◆ File migration and tape repacking................................................. 162◆ Family files ........................................................................................ 170◆ Backup procedures .......................................................................... 172◆ Volumes (tapes) ................................................................................ 180

Routine ManagementProcedures

Routine Management Procedures 147

148

Routine Management Procedures


DXUL-SM startup and shutdown

DXUL-SM persistence daemonsDXUL-SM provides daemons to start and automatically restart its servers if they crash or are powered off. Use of the DXUL-SM daemons ensures persistent server execution. The binaries for the daemons are located in <DISKXTENDER>/adm/bin. The pathnames to the daemon binaries are contained in the <DISKXTENDER>/etc/rc.diskxtender file. An entry for rc.diskxtender may be inserted into a system boot script at DXUL-SM installation so that the daemons are automatically started at UNIX system boot time. The daemons will, in turn, start the DXUL-SM servers. Table 22 on page 148 describes the daemons and functions.

The daemons start their respective servers by forking them as child processes. A daemon will kill and restart all of its servers when it catches a death-of-child signal for any of its servers. A daemon will terminate all of its servers and then exit if it was sent a INT, QUIT, IOT, or TERM signal. If the daemon was sent a HUP, it will terminate and then restart all of its servers.

Before starting a DXUL-SM daemon, check that the related servers are not already running. If the servers are already running, the daemon's attempt to start them again will fail. Because the daemon is persistent, it will repeatedly attempt to start the servers and fail. The servers running before the daemon was started will continue to run. The <DISKXTENDER>/etc/kill.diskxtender script is used to kill all DXUL-SM server processes automatically.

Table 22 Persistence daemons

Daemon Function

cmld Starts the CML Server

namesd Starts the Name Server

diskd Starts the Disk Server and Disk Mover

taped Starts all of the DXUL-SM tape processes

migd Starts the Migration Server

repackd Starts the Repack Server




◆ If any part of DXUL-SM is not running, check to see if the appropriate daemons are running.

◆ If a daemon is not running, starting it manually will restart its servers.

◆ If the daemon is running, but its servers are not running, refer to the troubleshooting procedures in the section “DXUL-SM crashes at startup” on page 218.

Using daemons to start DXUL-SMIf a system boot script contains an entry for rc.diskxtender, DXUL-SM will be started automatically at UNIX boot time through the DXUL-SM daemon mechanism. If the DXUL-SM servers crash or are otherwise taken down after boot time, the daemons will restart them as long as the daemons are running. There is no DXUL-SM or UNIX process that restarts the daemons.

DXUL-SM may be started by using the DXUL-SM daemons or by starting the individual servers manually. Start DXUL-SM by using the daemons. These daemons provide a persistent execution mechanism (if a server goes down, the related daemon will automatically terminate any related servers and restart the servers in the proper sequence).

Start the daemons in the following order:

1. <DISKXTENDER>/adm/bin/cmld

2. <DISKXTENDER>/adm/bin/namesd

3. <DISKXTENDER>/adm/bin/diskd

4. <DISKXTENDER>/adm/bin/taped

5. <DISKXTENDER>/adm/bin/migd

6. <DISKXTENDER>/adm/bin/repackd

Note: The CML Server should be brought up before the other servers as it receives the log messages from the other servers; if any servers encounter problems, CML will record the errors to the token_log file.

The NFS mount daemon, unfsmntd, must also be accessed. The unfsmntd daemon does not automatically restart if it is stopped. “Terminology” on page 26 provides information.

DXUL-SM startup and shutdown 149

150



To access unfsmntd, type:

<DISKXTENDER>/bin/unfsmntd

Specify the -d option if you want to start dual NFS

Note: Ensure that the rpc.mountd process is not running before executing the above command. Some systems start the mount daemon by using the inetd process. If this is the case, remove the mount daemon entry from the /etc/inetd.conf file and send a HUP signal to the inetd daemon.

Shutting down DXUL-SM by using the DXUL-SM daemonsTo shut down DXUL-SM, power off the DXUL-SM daemons. The daemons should be powered off in the following order:

1. kill pid[namesd]

2. kill pid[diskd]

3. kill pid[taped]

4. kill pid[migd]

5. kill pid[repackd]

6. kill pid[cmld]

Note: The CML server should be the last server to be killed as it logs the messages from the other servers.

To shut down NFS, first unmount any mounted directories and then type:

kill pid[unfsmntd]




DXUL-SM serversDXUL-SM is a collection of servers (programs that provide services to client programs) that run on a UNIX machine. The DXUL-SM servers are referred to as servers, movers, and the daemons unfsmntd and uftpd.

The DXUL-SM servers can be started manually if their daemons are not running. The binaries for the servers are located in <DISKXTENDER>/bin. The functionality of the servers managing DXUL-SM are described in Table 3 on page 29.

Note: The uftpd utility is runned by using inetd whenever an FTP session is initiated.

DXUL-SM provides several utilities to report on the execution status of each server. The storping command is used to determine whether a server is up and responding to requests. The -a option will ping all servers. Alternatively, the server executable name may be specified to ping an individual server. In addition, to get statistics information from a particular server, run one of the following commands: namestats, diskstats, tapestats, pvrstats, repackstats, or migstats.

Manual startup of DXUL-SMTo start DXUL-SM without the persistent execution mechanism, start the DXUL-SM servers manually. These commands should also be started in the background (or the processes will be killed upon logout).

Table 23 Startup order of DXUL-SM processes (page 1 of 2)

Executable name Server name

cmlsrvr Common Message Logger Server

namesrvr Name Server

diskmovr Disk Mover

disksrvr Disk Server

unfsmntd DXUL-SM NFS mount daemon

tapemovr Tape Mover

DXUL-SM servers 151

152



Note: The unfsmntd is a daemon and does not need to be started in the background.

Example 15 Server startup

To start the CML Server, run the following command:

<DISKXTENDER>/bin/cmlsrvr &

Note: Manual startup of the DXUL-SM servers is not the preferred method for DXUL-SM startup. Use of the persistence daemons ensures the servers will always be brought up in the correct order. Also, if a server crashes, the persistence daemon will restart the related server or servers.

Shutdown of servers To shut down DXUL-SM, take down the DXUL-SM servers:

1. kill pid[namesrvr]

2. kill pid[diskmovr]

3. kill pid[disksrvr]

4. kill pid[tapesrvr]

5. kill pid[pvrsrvr]

6. kill pid[tapemovr]

7. kill pid[migsrvr]

8. kill pid[repacksrvr]

9. kill pid[unfsmntd]

10. kill pid[cmlsrvr]

pvrsrvr Physical Volume Repository Server

tapesrvr Tape Server

migsrvr Migration Server

repacksrvr Repack Server

Table 23 Startup order of DXUL-SM processes (page 2 of 2)

Executable name Server name




User maintenance

User authentication file The DXUL-SM adduser file contains user authentication information to allow users DXUL-SM access. The nsau utility reads the adduser file to obtain user authentication information and then creates a home directory and .trash directory for each user. Each time users are to be added to DXUL-SM, the adduser file must be edited and nsau must be rerun.

Format of adduser The format of adduser is:

The home_directory_parent_pathname is the pathname of a directory where users' home directories are installed. There is one line for each user whose home directory is in the parent directory. On each user line:

◆ homedir is the name directory of a user to be added.

◆ UID is the user’s user id.

◆ GID is the group id for that user.

◆ permissions are the octal UNIX access control permissions for that user’s home directory.

◆ trashcan_timeout is the initial timeout period in minutes for that user's .trash directory.

The line of -1 fields marks the end of a section in the file.

home_directory_parent_pathname

homedir UID GID permissions trashcan_timeout

- - - - -

- - - - -

- - - -

homedir UID GID permissions trashcan_timeout

-1 -1 -1 -1 -1

User maintenance 153

154



Note: The DXUL-SM default values for permissions and trash can timeout will be used if a -1 is entered for the user in these fields.

If users larry and george are added as users with home directories in the /usr/diskx parent directory, the adduser file would appear as:

Note: The trash can timeout for user george is set to use the default trash can timeout that is set in DiskXtender.conf. When this value is changed, george’s trash can timeout changes with it.

If users stan and quivers in /usr/other are added following user george, then the adduser file would appear as:

Note: The UIDs, GIDs, permissions, and trash can timeout periods are example values. The actual values for these fields are site dependent.

/usr/diskx

larry 105 410 755 15

george 106 410 755 -1

-1 -1 -1 -1 -1

/usr/diskx

larry 105 410 755 15

george 106 410 755 -1

-1 -1 -1 -1 -1

/usr/others

stan 107 411 755 60

quivers 108 411 755 20

-1 -1 -1 -1 -1




Adding DXUL-SM users

To add users to DXUL-SM:

1. Add the users to the UNIX authentication file if they do not already exist (for example, the password file or NIS system).

DXUL-SM 2.11 supports LDAP users. Use DXUL-SM host as LDAP client, and add any LDAP user to the adduser file.

2. Edit the adduser file.

For each user being given access to DXUL-SM, exactly duplicate the UID, GID, and home directory pathname information from the password into the adduser file. Access to DXUL-SM will fail for each user where any of this information in the two files differs.

For example, user tom already has an entry in the password, with a UID of 130, GID of 420, and home directory pathname of /usr/labguys/tom. To add user tom to DXUL-SM and give him access to the system, create an entry in the /usr/labguys section of the adduser file which duplicates the information in the password file:

Note: The permissions and trash can timeout information are not found in the password file.

3. Run the nsau utility. The utility uses no parameters. It communicates with the Name Server to create the user home and .trash directories. The -n option is used if the standard system authentication files are being used.

Note: The Name Server must be running for nsau to function.

The nsau utility Ensure that the Name Server is running. If it is not running, the nsau utility displays an error. You can start the Name Server by following the procedures described in “DXUL-SM startup and shutdown” on page 148. Then, rerun nsau.

If nsau returns with an error and the Name Server is running, the most likely cause for the error includes are incorrect permissions or

/usr/lapguys

tom 130 420 755 45


156



formatting problems in the adduser file. Follow the troubleshooting procedures described in Chapter 7, “Troubleshooting.”

The nsau utility is flexible in that it permits a system administrator to use the adduser file in different ways. For example, some sites may prefer to use the adduser file to hold the complete list of all users of DXUL-SM. Other sites may choose to create a new adduser file each time a set of users is added to the system. Both alternatives are possible with nsau.

To use the adduser file to keep a list of all DXUL-SM users, continue adding new directories to the file and inserting new lines in existing sections of the file when new users are added.

For example, to add user norris in the existing /usr/others parent directory and user bob in the parent directory, /usr/labguys, the adduser file would be displayed as below:

The user entries can be in any order within a section, and the sections can be in any order.

Running nsau adds new users norris and bob to DXUL-SM. In reading the adduser file, the utility gives warning if it finds a user with an existing trash can in the users home directory.

/usr/diskx

larry 109 410 775 15

george 106 410 755 -1

-1 -1 -1 -1 -1

/usr/others

stan 107 411 755 60

quivers 110 411 755 20

norris 111 410 755 15

-1 -1 -1 -1 -1

/usr/labguys

tom 115 420 755 45

bob 116 420 755 40

-1 -1 -1 -1 -1




The adduser file is useful only for adding users to DXUL-SM and keeping a list of added users. It is not updated to reflect changes in information pertaining to an existing user. For example, if the trash can timeout is changed for user norris after being added to DXUL-SM, the adduser file will not be updated.

Note: Changing the values (other than the username) on an existing line will not change the values in DXUL-SM. For example, changing the permissions for user bob to 700 and running nsau will have no effect.

Removing DXUL-SM users

1. As the root user, manually delete the user's DXUL-SM directory structure by using standard FTP or NFS commands.

For example:

# rm -fr /usr/labguys/tom

2. Delete the user's line from the adduser file so that nsau does not re-create the deleted user the next time that utility is run.

3. To deny a user FTP access to the UNIX file system, delete the user's authorization line from the authentication file (for example, the password file or NIS system).


158



Monitoring use of the System

Common message logger and other log filesThe DXUL-SM log files are an important part of monitoring DXUL-SM. The log files should be reviewed at least once a day. The DXUL-SM daemons, servers, and utilities write log or trace files to the <DISKXTENDER>/adm/log directory. Log files record the success or failure of many of the operations performed by the processes that write to them. When errors are reported to the log files, follow the procedures in Chapter 7, “Troubleshooting.”

The DXUL-SM servers and some utilities accomplish logging by communicating with the Common Message Logger (CML) Server, cmlsrvr, which writes the server's log messages to a common log file, (<DISKXTENDER>/adm/log/token_log. token_log) is a tokenized log file that contains only a message number and variable data. The read_log utility translates the logged messages into text.

The DXUL-SM daemons and some utilities write individual log files that are identified by the name of the daemon or utility that produced them with a .t suffix. In the event that the cmlsrvr is down, all servers will write to their respective .t log files.

The text for the logged messages in the tokenized log is in <DISKXTENDER>/etc/cmf. A site may also create site-dependent messages in the <DISKXTENDER>/etc/smf file. The smf file is logically merged with cmf for message control and processing.

Note: If the same message number appears in both the smf and cmf files, the message in smf is used.

Monitoring token log

If an individual DXUL-SM Server is continually crashing, the best place to begin troubleshooting is with the read_log utility. Each server sends its error messages to the CML tokenized log. The read_log utility is used to extract specific information from the tokenized log. The log contains the following information for each message:

◆ Date/Time— The date and time of the error message.

◆ Message Number— The integer message number.




◆ Severity—The severity of the message identified by the following terms: Panic, Severe, Warning, Recover, Info, and Debug.

◆ Module—The name of the process that issued the message.

◆ Transaction ID—The IP number and process ID of the server or mover that issued the message.

Log information can be requested based on the following:

◆ Severity—Displays the requested severity level or range of severity levels.

◆ Brevity—Determines the amount of detail in the message.

◆ Module name—Displays only messages for the namesd modules or servers.

◆ Filename—Can specify the log file to read the messages from.

◆ Date—Determines the start and end date for log entries.

◆ Time—Determines the start and end time for log entries.

◆ Host—Determines the host that generated the message.

The corrective action is often suggested by the error message.

Monitoring other log files

The DXUL-SM daemons and some utilities write their log messages to their respective .t log files. These files should also be examined periodically for error messages. These log files do not wrap and should either be saved and moved or zeroed out periodically.

Note: The token_log file does not wrap. The CML Server creates a new token_log file after the file reaches a configurable size or age.

Disk cache usage DXUL-SM provides three utilities to monitor usage of the Disk Server disk cache. The statall utility reports the current percentage of utilized header space on the disk cache as a whole and the current percentage of utilized data space on the disk cache as a whole. It also reports the current number of files on the cache.

The statup utility reports the status of each partition in the disk cache, the total number of headers available on each partition, the maximum number of headers on each partition, and the size of each partition. The status reported is UP, DOWN, or GOING DOWN.

The diskstats utility can also be used to report disk cache usage. When run with no options, it reports back the number of migrated

Monitoring use of the System 159

160



and unmigrated files on the disk cache, the total amount of data read, written and migrated, and the number of active transfers. When used with the -d option, information about each partition in the disk cache will be displayed.

Tape usage DXUL-SM provides the readmap utility to report the tapemap structure for all DXUL-SM tapes. This information includes the fields shown in Table 24 on page 160.

Monitoring tape usageThe information generated by the readmap utility can be used to monitor tape usage. Run readmap and answer the following questions:

Table 24 tapemap fields

Tapemap field Meaning

MEDTYP Media type of the volume. From the tape.conf file.

TAPEID ID of the volume.

CNT In-use block count. Reports the number of blocks on the volume with active data in them.

LAST BLOCK Reports the last block written to the volume. The next write will begin here.

USAGE A value that reports the function that the volume is currently being used for. Valid uses are migration (MIGRAT), caching (CACHE), partial backup (PARTBU), full backup (FULLBU), repacking (REPACK) and unused (UNUSED). Volumes marked unavailable (UNAVAI) will not be used by DXUL-SM.

FAM Family to which the volume is assigned.

CPY Copy set which is stored on the volume.

LOC Location of volume.

RPKS Number of times a tape has gone from in-use to UNUSED.

ERRS Number of read errors on volume.

MNTS Number of mounts performed on the volume.

LST_ACCS Time the volume was last mounted and accessed (by date).




◆ Are too many or too few tapes assigned to a specific family?

◆ Are there enough free tapes, or do more tapes need to be initialized?

◆ Which tapes are in use and for what purpose?

◆ Are the site's goals for data management being accomplished? Is the duplicate copy feature in-use, is data being migrated to the vault location, and so on.

Monitoring use of the System 161

162



File migration and tape repackingFile migration is performed at two levels by DXUL-SM. On all DXUL-SM systems files are migrated from the disk cache to online secondary storage level. DXUL-SM sites may also choose to migrate files to a vault level (offline storage).

Migration from disk cache to tapeAll files created in DXUL-SM reside first on the disk cache, the highest layer in the DXUL-SM hierarchy. At a time configurable by the system administrator, these files will be migrated (copied without destroying the original) to a lower layer in the DXUL-SM hierarchy (for example, magnetic tape).

DXUL-SM provides automatic control of the migration of files from the disk cache to tape through the set of configuration parameters in DXUL-SM.conf. Manual control of migration from the disk cache to tape is achieved through use of the forcemig utility. The forcemig utility forces an immediate migration of files from the disk cache, based on one of the following parameters:

◆ repackserver.file_age parameter in DXUL-SM.conf

◆ parameters supplied by the user

Monitoring migrationThe Migration Server logs to the CML Server and its errors are reported in the token_log file. Use the read_log utility to search for data on file migration. The token_log file will contain:

◆ An entry each time the Migration Server wakes up

◆ The number of files that are candidates for migration

If the criteria defined in DiskXtender.conf is met, migration will begin. If migration occurs and debugging is enabled, an entry in the log file will be created for each file as it is migrated. More importantly, the log will contain any errors encountered by the Migration Server, regardless of the debugging setting.

Some common problems that result in a migration error are:

◆ Requested volume is not mounted.




◆ Volume is jammed in the drive.

◆ File was deleted during migration.

Migration and caching DXUL-SM has the ability to migrate to many drives simultaneously. If unrestrained, migration may use all the drives allocated to DXUL-SM in tpdevs. However, it is possible to reserve some of the available drives for particular uses.

A set number of drives may be reserved for migration and caching purposes. This gives DXUL-SM the ability to provide parallel activity when writing to and reading from volumes. The system administrator sets the priority of migration and caching in either of two ways:

◆ By setting the min_mig_drvies, min_cache_drives, and max_simul_same parameters for the entire system in the DiskXtender.conf. “Tape server configuration” on page 85 provides more information.

◆ By setting the min_mig_drives and min_cache_drives parameters for each tape set in the <DISKXTENDER>/etc/tpset file. “<DISKXTENDER>/etc/tpset” on page 125 provides more information.

If rapid storage of large quantities of incoming data is important, frequent migration may be the priority. The administrator can reserve one or more drives for the migration function.

If quick response to cache requests is preferred, there may be a need to increase the priority of caching. The administrator can reserve one or more drives for the caching function.

The administrator can also tell DXUL-SM to allocate multiple drives to the migration that have identical parameters, specifically, tapes allocated to the same family and copy number. Unless activated, if a large number of files with the same family ID and copy number are being migrated, the Tape Server will use only one drive for the migration of the files for the family even if another drive is available for migration. This is controlled by using the tapeserver.max_simul_same configuration variable in the <DISKXTENDER>/etc/DiskXtender.conf file.

By using the op field in the <DISKXTENDER>/etc/tpdevs file, the administrator may explicitly allocate drives for individual uses.

File migration and tape repacking 163

164



“<DISKXTENDER>/etc/tpdevs” on page 123 provides more information.

Note: Caution needs to be exercised if drives are assigned for specific operations in the <DISKXTENDER>/etc/tpdevs file and set declarations in the <DISKXTENDER>/etc/tpset file are used. It is possible to create a configuration which leads to poor drive utilization.

Tape repacking and vault migrationThe Repack Server has two distinct functions:

◆ To keep the level of free volumes at the appropriate level by increasing volume utilization.

◆ To provide vault migration of inactive files.

Volumes are repacked when they have become sparse due to file deletion or remigration due to file modification. The data on the sparse volumes is moved (repacked) to free volumes. A free volume can be either of the following:

◆ A volume with a zero block count that has been assigned to the specified family, copy number, and location.

◆ A volume from the free volume pool (a group of volumes that have not been assigned a family, copy number, and location). Repacking frees up the volumes where the files previously resided.

If the Repack Server does not have enough free volumes to repack a location, it will move files to the configured vault location. The vault location is defined by the system administrator in <DISKXTENDER>/etc/DiskXtender.conf. “Repack server configuration” on page 92 provides more information.

In DXUL-SM systems that manage both online volume storage and offline volume storage, the Repack Server manages volume repacking and the automated moving of files from online to offline volume layers (vault migration). Volumes repacking and vault migration are distinct functions. Volumes may be repacked with or without vault migration, depending on the circumstances that exist when the Repack Server wakes up. These circumstances fall into the following categories, based on parameters in the DiskXtender.conf file:




◆ If the number of current free volumes in a location/family/copy number combination is greater than or equal to the level specified in the free_tape_percentage parameter, neither repacking nor vault migration occur.

◆ If the number of free volumes is less than the level specified by the free_tape_percentage parameter and repacking the tapes within a location/family/copy number combination will increase the number of free tapes above or equal to the threshold level, then repacking will occur.

◆ If the number of free volumes is less than the level specified by the free_tape_percentage parameter and repacking the tapes will not increase the number of free tapes above or equal to the threshold level, then repacking and vault migration will occur.

Note: There must be enough repack candidate volumes within the pool of volumes being repacked to increase the percentage of free volumes to reach or exceed the threshold level. If there are no free volumes within the pool of volumes or in the unassigned pool, then both repacking and vault migration will occur.

Manual control of volume repacking and vault migration including options for separate handling of volumes by location, tape id, family, and copy number is provided by the forcepack utility.

Forcepack utility The forcepack utility can be used to override the repack parameters configured in <DISKXTENDER>/etc/DiskXtender.conf. The forcepack utility can be used to perform a complete repack of all location/family/copy number combinations:

<DISKXTENDER>/bin/forcepack [-s] -w<DISKXTENDER>/bin/forcepack [-s] -i tapeids [-A] [-T ToLoc] [-m]<DISKXTENDER>/bin/forcepack [-s] -F FromLoc [-f family] [-c copynum] [-T ToLoc] [-m]

or subsets of volumes may be selected. For example:

◆ If the -i option is selected, the Repack Server repacks those specific tapes.

% forcepack -i tapeid1,tapeid2

% forcepack -F FromLoc


166



◆ If the -F option is used, the Repack Server examines all tapes in the location FromLoc to select repack candidates.

◆ If the -A option is used, this causes the repacksrvr to repack all copies of the files found on the media specified with the -i option.

Files can also be forced to be vaulted to the configured vault location by typing the following command:

% forcepack -F FromLoc -m




Example 16 Repacking and vault migration

Configuration in DiskXtender.conf file: free_tape_percentage = 20in_use_percentage = 50last_access = 30

Analysis:1. Current percentage of free volumes (1 of 8 = 12.5%) is less than

free_tape_percentage (20%), so the Repack Server will attempt to repack volumes.

2. Volumes 3, 4, 7, and 8 are less than the in_use_percentage (50%) full, and are repack candidates.

3. Since a free volumes (tape 5) was previously assigned to Location 0, Family A, Copy 1 and this is an exact match for the location, family, and copy numbers of volumes 3, 4, 7, and 8, they will be repacked onto tape 5.

4. Location 0 now meets the free_tape_percentage (20%, 4 of 8 - tapes 3, 4, 7 and 8) and the Repack Server’s inspection ends.

Example of Repacking


168



Configuration in DiskXtender.conf file: free_tape_percentage = 50, in_use_percentage = 50, last_access = 30

Analysis:1. Current percentage of free tapes (1 of 9, tape 5) is less than

free_tape_percentage (50%), so the Repack Server will attempt to repack volumes.

2. Tapes 4 and 9 are less than in_use_percentage (50%) full and are repack candidates. However, the combination of free tapes and repack candidates (3 of 9, tapes 4, 5, and 9) is less than the free_tape_percentage. Therefore, vault migration will be initiated.

3. The Repack Server finds all files that are older than the last_access (30 days) that are part of Location 0, Family A, Copy 1.

4. Tapes are then examined sequentially to determine if they would be repack candidates if the files older than last_access were vaulted. These tapes are added to the repack candidate list.

5. Files older than last_access on either set of the repack candidates are vaulted. The remaining files on the repack candidate tapes are repacked.

If repacking does not bring the level of free tapes below the free_tape_percentage threshold, but would produce some repack candidates, then vaulting will occur and the Repack Server will log a warning that the “free_tape_percentage” cannot be met. Vaulting will not occur if there are no repack candidate tapes, and the Repack Server will log an error.

Example of Repacking




Monitoring repacking

Repacking can be a manual operation that occurs only when the administrator invokes the forcepack utility or repacking can be configured to occur automatically based upon the parameters in DiskXtender.conf. If repacking is a manual function, monitoring is necessary to determine when the forcepack utility should be invoked. If repacking is an automatic function, administrative monitoring is necessary to determine if the Repack Server parameters are configured properly.

Use the readmap utility to examine the following:

◆ How many volumes are free and is this an adequate number (for example, the in-use block count is equal to zero). If more volumes need to be free, run forcepack to initiate repacking or add more volumes to DXUL-SM.

◆ Volumes become repack candidates when they are marked for cache (occurs when volumes tape is either full or terminates with an error) and the in-use block count falls below the in_use_percentage value. If the number of volumes that are repack candidates is too high, run forcepack.

◆ Tapes which are currently being used by the Repack Server to consolidate data will have the usage field set to RPKUSE.

The settape utility is used to change the tapemap fields. The administrator can change the location, family, or copy number associated with a free volume. For example, if a family has too many volumes allocated to it, redesignate some of these volumes to the common pool by using settape to change the family information for the free volumes.

For more detailed information on repacking and vault migration, the repacksrvr man page provides information.


170



Family filesDXUL-SM allows the segregation of files into file family designations. Each file in a family resides on a volume with files only of the same family. The <DISKXTENDER>/etc/family file contains family-UID (for FTP) and family-GID (for NFS) mappings.

Family file designation is useful for reducing overall access times for files that are typically used as a group (for example, multiple table files in a relational database, backups, related graphics, and so on). In addition, family file designation automates restricted migration of related files to a specific set of volumes.

Volumes are designated to a particular family or to the free pool upon labeling. Volumes in the free pool have a family_id of -1, which indicates that the volume has not been assigned to a family. The family identifier assigned to a volume can be changed if there is no data on the volume.

Files are assigned to a family before or at file creation time. Once a file has been assigned to a family, its family may be changed through use of the setfam command. An attempt to set a family to a family_id not in the family file, will default to a family_id of 0, or the “common” family.

The family file allows the system administrator to designate file families. Up to 65535 families may be assigned in addition to the “common” family, the default.

Volumes are associated with the family identifier by either:

◆ Use of the settape utility.

◆ Selection of the next available tape from the free pool.

Monitoring families Use the readmap utility with the -f family_num argument to view the volume usage in relation to families:

◆ Most volumes are assigned to a specific family.

◆ The unused volumes are assigned to the common pool or they are assigned to a specific family.

If most of the stored data is allocated to a specific family, assign unused volumes to that family. If there is no established pattern, keep all volumes assigned to the common pool so that they are dedicated to a family only when necessary.




Note: The system administrator should ensure that there are enough active and current volumes available for storing files associated with a particular family. If volumes are allocated for a family, but their status is something other than active (for example, unavailable), then the volume will not be used.

“<DISKXTENDER>/etc/family” on page 111 provides more information on families.

Family files 171

172



Backup proceduresThe Name Server, Disk Server, and Tape Server databases are different from each other and have their own unique procedures for database backup.

Name Server database

Backup of the Name Server database is accomplished through standard UNIX copy utilities such as cp or dd. The copied versions of the database should themselves be backed up whenever the system administrator performs a backup of the local UNIX file system.

When using multiple partitions for the Name Server database, each primary partition should be backed up separately. The size and location of each backup must be saved for restoration.

Note: Name Server database backups can be copied into the DXUL-SM file system, written to tape, and later retrieved for a recovery operation.

For more information, refer to the following script:

<DISKXTENDER>/cs/cpandmailnamebackup

Data The data contained in the Name Server database is the entire DXUL-SM directory structure (name/fileid pairs only). This data is stored on primary and secondary (shadow) partition pairs managed by the Name Server. The Name Server partitions are listed in the <DISKXTENDER>/etc/nsdevs file.

Mechanism No complete database backup utility is provided by the Name Server. Its database must be saved through standard UNIX copy utilities such as cp or dd.

The Name Server has a journaling option, also known as transaction logging. When this feature is enabled, each transaction is written to a journal file before the primary and secondary (shadow) partitions are updated:

◆ When journaling is not enabled, DXUL-SM does provide the ns_quiesce utility to bring the Name Server to a read-only state. This utility is used to prepare for a backup or shutdown of the Name Server. After this command has been issued, no modifications to the Name Server database will be allowed until the ns_restart utility is executed.




◆ When journaling is enabled, the Name Server does not need to be in a read-only state. The ns_rolljournal utility should be run before a backup of the Name Server to generate a new journal set.

Each primary partition in the nsdevs file must be copied onto the backup media.

Procedure When running without journaling, use the following command to prepare the Name Server for backup:

% <DISKXTENDER>/adm/bin/ns_quiesce

When the Name Server is in a quiescent state, use a UNIX copy utility to back up each of the Name Server primary partitions located in the nsdevs file. Refer to the UNIX man pages for more information.

When running with journaling, use the following command to close the current journal file, move it to a time stamped name, and start a new journal file for the new backup set:

% <DISKXTENDER>/adm/bin/ns_rolljournal

When the utility returns, use a UNIX copy utility to back up each of the Name Server primary partitions located in the nsdevs file. Refer to the UNIX man pages for more information.

Considerations When performing the Name Server backups, give attention to the following considerations:

◆ Records

Keep accurate records of the location of each primary partition on the backup media. The records should include the partition pathname, location, and date of the most recent backup. If journaling is enabled, also save prior journal files to ensure these incremental changes can be recovered.

◆ Server availability

Use the ns_quiesce utility when journaling is not running to put the Name Server into a read-only state while its primary partitions are being copied to backup media (backup of the Name Server partitions should be done during an inactive period). Backups of an active system can result in corrupt partition images and may cause the server to crash upon restoration of the database. There is no mechanism to validate the backup image.

Backup procedures 173

174



◆ Journaling cost

The two advantages of journaling are:

• The ability to recover to the last transaction, and not to just the last database backup.

• The ability to perform database backup without putting the database into read-only mode.

However, the disk space used by journal files can become excessive on loaded systems and this mode also causes the Name Server to run more slowly. The journal files must be copied periodically to backup media in case they are lost as part of a disaster. Journaling is normally performed only by sites that cannot afford a read-only period for the Name Server.

◆ Database consistency

Backup of the Name Server's database should be performed in conjunction with the full backup of the Tape Server's database. Performing these two backups as parallel operations reduce the number of dangling pointers and lost objects if a recovery is necessary. Dangling pointers are entries in the Name Server database that point to nonexistent file data in the disk cache. Lost objects are file data for which there is no pointer in the Name Server database.

Disk Cache Backup of the Disk Server's disk cache is performed automatically and continuously through the DXUL-SM migration process. The disk cache partitions are not shadowed. It is important, that the system administrator become thoroughly familiar with the migration procedures.

Data The data backed up by these procedures is the data stored on the disk layer of the DXUL-SM hierarchy.

Mechanism The backup philosophy for the Disk Server's partitions is different from that of the other servers. The partitions are not shadowed. There is no special utility offered to copy the data to separate backup media. Data on the partitions is backed up by migration to the DXUL-SM archive media.

The frequency of migration is controlled by the migration parameters in <DISKXTENDER>/etc/DiskXtender.conf. Migration can also be initiated by the migration utility, forcemig. Chapter 3, “Configuring DXUL-SM,” provides more information on migration.




Procedures Tune the following Migration Server parameters in DiskXtender.conf to control the frequency of migration:

◆ migserver.migrate_fileage

◆ migserver.migrate_threshold

◆ migserver.migrate_wait

◆ migserver.migrate_wakeup

Also tune the following Migration Server parameters in DiskXtender.conf to control the number of copies of a file that will be created upon migration:

◆ migserver.file_copies

◆ migserver.max_filecopies

◆ migserver.min_filecopies

Considerations When you prepare for the event of the loss of disk cache data, pay attention to migration frequency, partition fragmentation, server availability, and database consistency:

◆ Migration frequency

Migration frequency is controlled by the parameters in DiskXtender.conf. Since the primary purpose of migration is to back up the data on the disk layer, migration should occur frequently enough to minimize the loss from a disk failure. Migration also allows files to be purged from the disk layer, creating space for new files and cached files on the disk layer.

◆ Partition fragmentation

To minimize the possibility of files spanning partitions and being lost if a partition fails, avoid disk layer fragmentation. The disk layer can become fragmented, causing new and cached files to span partitions, when existing files cannot be purged from the layer.


The DXUL-SM server must be up for the procedures previously mentioned (migration, purging, caching) to occur. The user interface (FTP and/or NFS) to DXUL-SM should also remain available to users.


176




If files are lost due to partition failure or files never migrated to the archive layer, dangling pointers to the files will exist in the Name Server's database. The ns_edit utility is available to remove dangling pointers from the Name Server's database. This utility is used to perform maintenance functions on the Name Server database.

Tape Server data structures

There are two ways to backup the Tape Server's major data structures:

◆ In the first procedure, the Tape Server backs up part of its data structures to backup tapes automatically. This backup, referred to as “partial backup” or “incremental backup”, occurs periodically after tapeserver.start_partbu sectors are filled with updates to the data structures. Each sector holds 11 transactions, the default tapeserver.start_partbu value is 30. When this value is reached, it will result in a mount request for a partial backup volume.

◆ The second procedure for backing up all the Tape Server data structures is to run the backup utility. The backup utility, referred to as “full backup” copies the Tape Server's file headers and search table to backup volumes. DXUL-SM does not run the utility automatically. It must be executed by the system administrator. Executing the backup utility will result in mount requests for backup tapes.

Data The data backed up by these procedures are the critical data structures stored on the disk partitions managed by the Tape Server. The server writes file headers to header partitions and other critical data structures to search table partitions.

The Tape Server shadows its data on secondary partitions. The <DISKXTENDER>/etc/tddevs file contains the primary and secondary partition pairs allocated to the Tape Server.

Mechanisms The Tape Server database is backed up through the partial (incremental) and full backup processes.

◆ Partial backup

The server logs incremental modifications to the file headers stored on the archive layer. The modifications are written to the Tape Server's search table partitions. Periodically, the server automatically writes the incremental logs and the tapemap to backup volumes.




◆ Full backup

The backup utility performs the backup of the complete file headers written to the server's header partitions. It also backs up the tape map and the search table data structures, written to the server's search table partitions. When the utility is executed, the server writes the data to backup volumes and logs information in the <DISKXTENDER>/adm/log/backup.t file. The information in the backup.t file will be needed to recover data. A separate set of tapes is used for each partition.

Procedures Partial backup: No procedure. This is an automatic process.

Full backup: Type the following command:

<DISKXTENDER>/adm/bin/backup

Considerations The following must be taken into consideration when performing a backup of the Tape Server's data structures:

◆ Backup volume availability

Backup volumes must be labeled and available for the server to use. Even if the backup utility is never executed, the server requires backup volumes for its incremental backup procedure.

◆ Number of copies

Normally, only a single copy is made of each backup volume. By setting tapeserver.num_fullbu_copies and tapeserver.num_partbu_copies, more than one copy may be requested.

The system administrator can designate specific volumes to be used for backup by assigning a range of volume IDs in the tapemap to either FULLBU or PARTBU usage and setting the tapeserver.unused_for_backup parameter to 0 in the <DISKXTENDER>/etc/DiskXtender.conf file. If this is done, the administrator must recycle backup tapes by using the settape command as the free backups are used. The settape man page provides information on how to manipulate the DXUL-SM tape map. The readmap man page provides information on viewing DXUL-SM tapemap information.


178



◆ Drive availability

To prevent the backup process from competing for drive resources with caching, an adequate number of drives must be configured for DXUL-SM. It may be necessary to add more drives to DXUL-SM or change the tapeserver.min_cache_drives parameter in <DISKXTENDER>/etc/DiskXtender.conf or the min_cache_drives in the <DISKXTENDER>/etc/tpset file A drive used for backup is considered a migration drive for the purposes of drive resource allocation.


The DXUL-SM tape processes must be up in order to perform both the partial and full backups.


The backup utility should be executed in conjunction with the backup of the Name Server's database, so that the databases can be as consistent as possible.

Example 17 Locating the last backup set

Use grep on the backup.t file to locate the last backup set:

grep "FULL BACKUP:" <DISKXTENDER>/adm/log/backup.t

Use grep on the backup.t file for the last partial backup:

grep "PARTIAL BACKUP:" <DISKXTENDER>/adm/log/backup.t

If there was a partial backup since the last full backup, then the tapes used in the partial backup will be used with the full backup tapes for the recovery process.

If backup.t appears as follows:

FULL BACKUP:Begun 01/10/30 14:59:43FULL BACKUP:Beginning backup of headersFULL BACKUP:tape AMA209, media type 5, writing 8702 disk sectors logical disk unit 1starting disk sector 2starting tape block 128, number of tape blocks 1106Beginning backup of search table diskFULL BACKUP:tape AMA209, media type 5, writing 2820 disk sectors logical disk unit 3starting disk startsector 1starting tape block 1234, number of tape blocks 359FULL BACKUP:Wrote the above tapes to backupset 1, copy 0FULL BACKUP:finished 01/10/30 15:03:59




PARTIAL BACKUP: Begun 01/10/30 16:10:30PARTIAL BACKUP:tape AMA210, media type 5, writing 33 disk sectors logical disk unit 3starting disk sector 2823starting tape block 128, number of tape blocks 9PARTIAL BACKUP: Wrote the above tapes to backupset 1, copy 0PARTIAL BACKUP:finished 01/10/30 16:15:22

The last full backup to tape AMA209 was followed by a partial backup to tape AMA210. In the recovery process, tapes AMA209 and AMA210 will be used.


180



Volumes (tapes)DXUL-SM does not provide backup of the file data written to the data volumes in the system. Further, the volumes contain only the current version of files in the system. Previous versions of the files are unavailable. Files do not contain version numbers.

Protection for datafiles is provided with the multiple copy feature. DXUL-SM provides the ability to have multiple copies of files stored on different volumes. The copies are created during migration. The Migration Server has parameters in <DISKXTENDER>/etc/DiskXtender.conf, which set the defaults for the multiple copy feature:

◆ migserver.file_copies

◆ migserver.max_filecopies

◆ migserver.min_filecopies

“Migration server configuration” on page 65 provides more details.

Note: The multiple copy feature provides the only backup mechanism for files. If no file copies are created and a tape is lost or destroyed, the lost data is not recoverable.

Backing up the DXUL-SM system tree

Backup the DXUL-SM system tree, <DISKXTENDER>, as a precaution in case the file system is lost. Without the configuration files in the <DISKXTENDER>/etc directory, examination of the raw databases must be performed to reconstruct the configuration. In addition, the <DISKXTENDER>/adm/log/backup.t files contain information necessary for restoration of the tape database, in case the database is lost.

Note: Do not back up the DXUL-SM system tree into the DXUL-SM file system. Since the DXUL-SM file system will not be available after the loss of the DXUL-SM system tree until the system tree has been restored, it is impossible to retrieve the system tree from the DXUL-SM file system.



5


◆ Storage devices dedicated to the system ...................................... 183◆ Name server database ..................................................................... 184◆ Disk cache.......................................................................................... 187◆ Tape header disks............................................................................. 192◆ Tape media ........................................................................................ 202◆ System sizing control....................................................................... 208

Adding and RemovingDevices

Adding and Removing Devices 181

182

Adding and Removing Devices


DXUL-SM is modular and expandable. The system can be configured for a variety of storage devices. The following sections describe how to add and remove:

◆ Dedicated system storage devices (holds DXUL-SM system data)

◆ Storage devices that constitute the various layers of the DXUL-SM hierarchy (holds DXUL-SM user data)

◆ Tape drives

◆ Media




Storage devices dedicated to the systemOn installation, several sets of storage devices were allocated to DiskXtender for UNIX/Linux Storage Manager (DXUL-SM). Three sets of disk partitions are allocated:

1. One set to the Name Server for its database.

2. Second set to the Disk Server for its disk cache.

3. Third set to the Tape Server to store its data structures. Volumes and drives were also allocated for DXUL-SM use.

The Name Server, Disk Server, and Tape Server all have ownership of their own disk partitions where relevant data structures are stored. These datasets are written to disk because they are too large to store in memory. The size of the disk partitions place effective limits on the operational size of DXUL-SM.

All storage devices that are allocated to DXUL-SM, with the exception of tape drives controlled by the Volume Manager, are used exclusively by DXUL-SM. Only DXUL-SM servers may access the disk partitions allocated to the Name Server, the Disk Server, and the Tape Server. The DXUL-SM tape processes can only access volumes and tape drives allocated to DXUL-SM. However, DXUL-SM tape drives can be shared between DXUL-SM and other processes if they are controlled by the Volume Manager or the drives are dynamically managed by using the tpdevdown and tpdevup utilities.

Storage devices dedicated to the system 183

184



Name server databaseThe <DISKXTENDER>/etc/nsdevs file contains the disk partitions allocated to the Name Server. The format of the nsdevs file for partition pairs 1 to n is:

The partition_pathname is the site pathname to the primary partitions in odd-numbered lines and to the secondary partitions in even-numbered lines. The size_of_partition is the number of 4 KB blocks in the partition.

Note: The partitions in each partition pair in nsdevs must be the same size or the Name Server will not start.

Extending the Name Server databaseExtending the Name Server database requires providing disk partitions (up to 128 pairs) or copying the last partition onto a larger disk partition. Extending the database should occur when the space on the current partitions gets low. Space usage for the Name Server database can be monitored with the ns_space utility. The ns_space man page provides details.

To increase the size of the database, follow the steps in either “Procedure 1: Add partitions to the database” on page 185 or “Procedure 2: Copy the database onto a larger partition” on page 186.

primary_partition_pathname_1 size_of_partition

secondary_partition_pathname_1 size_of_partition

primary_partition_pathname_2 size_of_partition

secondary_partition_pathname_2 size_of_partition

........ ........

primary_partition_pathname_n size_of_partition

secondary_partition_pathname_n size_of_partition




Procedure 1: Add partitions to the database1. Choose pairs of disk partitions up to a maximum of 255 total

partition pairs. Each partition in a pair must be the same size. Since the Name Server will do raw I/O on the partitions, it is not necessary to run mkfs or a similar UNIX utility to prepare these partitions.

2. Run the disksize utility on each disk partition to be added:

<DISKXTENDER>/adm/bin/disksize device_pathname block size

The utility returns the size of a partition in blocks. The blocksize parameter defines the units that the returned size value is expressed in. Since the number of blocks must be in 4 KB, set the block size to 4096.

3. Edit the nsdevs file to include the pathnames to the new partitions. For each partition, enter the size returned by disk size. The partitions in a pair must be the same size.

4. Type the DXUL-SM utility nsfmt on each of the new partitions.

<DISKXTENDER>/adm/bin/nsfmt device_path

The nsfmt utility initializes a partition and reports its size in 4 KB blocks.

Note: Do not run nsfmt on the current partitions or the database will be overwritten and lost.

Ensure that the size returned by nsfmt is the same for each partition in a pair. If the size is not the same for each partition, do not proceed with the remaining steps. Instead, go to Step 1 on page 185 and repeat the procedure.

If the partitions are not in the nsdevs file before nsfmt is executed, an error message will be returned.

5. To restart the Name Server, type the command:

kill -HUP pid[namesd]

The server will exit, be restarted immediately by its daemon, namesd, and reread the nsdevs file when it appears.

Note: When extending the Name Server database, do not run the nscr utility. It will reinitialize the entire database.

Name server database 185

186



Procedure 2: Copy the database onto a larger partitionThis procedure may only be used on the last partition. Changing the size of any other partitions will corrupt the name database.

To copy the database onto a larger partition:

1. Choose two disk partitions larger than the currently allocated partitions. Since the Name Server will do raw I/O to the partitions, it is not necessary to run mkfs or a similar UNIX utility to prepare these partitions.

2. Run the DXUL-SM zerodisk utility on each of the new partitions:

<DISKXTENDER>/adm/bin/zerodisk device_path

The zerodisk utility patterns a partition and reports the partition size in 4 KB blocks. Record the size returned by the utility, as it is used in a later step. Do not run zerodisk on any current partitions or the database will be overwritten and lost.

Be sure the size value returned by the zerodisk utility is the same for both partitions. If the size value is not the same for each partition, do not proceed with the remaining steps. Instead, go back to step 1 and repeat the procedure. Bring down namesd, the Name Server’s daemon, and it will bring down the Name Server:

kill pid[namesd]

The Name Server cannot be running during the next two steps or the database copied to the new partitions might be inconsistent. User access to the DXUL-SM directory structure will be denied while the Name Server is down.

3. Copy the data on the current Name Server database partitions to the newly chosen partitions. For example:

4. Change the appropriate lines of the nsdevs file to contain the pathnames of the new primary and secondary partitions along with the new sizes in 4 KB blocks. The sizes entered in this file should be the sizes returned by the zerodisk utility when it patterned the partitions in step 2.

5. Restart the Name Server by running its daemon, namesd: <DISKXTENDER>/adm/bin/namesd

dd if=current_prim_partition of=new_prim_partition

dd if=current_sec_partition of=new_sec_partition




Disk cache

Disk cache contention minimizationThe partitions allocated to the Disk Server are recorded in the Disk Server configuration file, <DISKXTENDER>/etc/diskdevs. Each partition pathname in diskdevs is prepended with a sequential DXUL-SM logical device number, beginning with the number 1. The Disk Server will search the disk cache partitions sequentially by logical device number to find space for file storage, using a first-fit, round-robin algorithm.

If a series of partitions that span more than one disk was dedicated to DXUL-SM at installation, assign the logical device numbers to the partitions across the disks rather than down the disks to minimize disk contention. The round-robin algorithm will put the next write request on a separate device. This method allows operations to be performed in parallel, which increases performance.

Figure 8 Disk cache partitions are accessed

Adding disk partitions to the disk cacheThe partitions allocated to the Disk Server are recorded in the Disk Server configuration file, <DISKXTENDER>/etc/diskdevs. At startup, the Disk Server reads diskdevs to find its disk cache.

The diskdevs file contains one line for each disk partition in the disk cache. The format of each line in diskdevs is:

The Disk Server uses a first-fit, round-robin algorithm to allocate space on the disk cache. The logical_device_number field (an integer

logical_device_number/device_path blocks blocksize

Disk cache 187

188



between 1 and 1024) specifies the order in which the partitions are searched in finding space to allocate. The device_path field is a partition pathname. The blocks field specifies the size of the partition as expressed in multiples of the blocksize field.

To help determine whether to add disk partitions to increase the space on the cache, run the DXUL-SM statall utility. The statall utility reports the current percentage of utilized header space and the current percentage of utilized data space in the cache as a whole. It also reports the current number of files in the cache. The utility reports this information to the screen. While statall is running, it periodically refreshes the screen with updated information.

How to add space to the disk server’s disk cacheTo add space to the Disk Server’s disk cache:

1. Choose partitions for the cache.

2. Run the disksize utility on each disk partition to be added:

<DISKXTENDER>/adm/bin/disksize device_pathname blocksize

The utility returns the size of a partition in blocks. The blocksize parameter defines the units that the returned size value is expressed in. Since the number of blocks must be in 4 KB, set the blocksize to 4096.

3. Edit diskdevs and add the new partitions to the file with their logical numbers and sizes. The partitions must be added to the end of the file. They must also be assigned consecutive logical partition numbers. The blocks field for each partition may be filled in from the 4 KB size returned by the disksize utility. The blocksize field should be set to 4096 (4 KB).

4. Run the disklabel utility on each of the new partitions:

<DISKXTENDER>/adm/bin/disklabel device_path

The disklabel utility labels a single partition with information required by the Disk Server in order to use the partition.

5. Restart the Disk Server:

kill -HUP pid[diskd]

The server will exit, be restarted immediately by its daemon, diskd, and reread the diskdevs file when it comes up.




Although the Disk Server catches the HUP signal to reread other configuration files, it must be restarted to induce it to reread diskdevs. This is because adding partitions to the disk cache requires the server to rebuild many of its data structures, a step taken only at server startup.

Removing disk partitions from the disk cacheDisk partitions are usually removed from the Disk Server’s disk cache when a partition is failing or more space has been allocated to the disk cache than is needed.

As an aid to determine if more space than necessary has been allocated to the disk cache, periodically run the statall utility. The statall utility reports current utilized header and current utilized data space on the cache as a whole. It also reports the current number of files in the cache.

The procedure for removing a partition from the disk cache, described in detail below, involves moving the files from the partition being removed to the remaining partitions in the cache and then disabling the partition to be removed.

To remove a partition from the disk cache:

1. Run the statall utility to determine if there is enough free space in the cache to accept all of the files from the partition to be removed from the cache. If there is enough free space, proceed directly to step 3.

2. If there is not enough free space in the disk cache to accept the data from the partition to be removed, an immediate migration from the disk cache must be forced:

<DISKXTENDER>/adm/bin/forcemig -a

Migration will begin immediately.

To determine when the migration round has completed, read <DISKXTENDER>/adm/log/token_log using the read_log utility. The Migration Server will display a log message when it has successfully completed migrating all of the migratable files off the disk cache.

For example, if there were three migratable files on a disk cache with four disk partitions, the token_log log file would report that the migration was successfully completed.

Disk cache 189

190



The following is an example of the output of read_log when migration has completed:

3. Run the diskdown utility:

<DISKXTENDER>/adm/bin/diskdown logdisk

where logdisk is the logical device number of the partition from the <DISKXTENDER>/etc/diskdevs file.

The utility first changes the access mode on the partition to read-only. It then attempts to move all of the file header and file data on the partition that have not been migrated to tape to other partitions in the cache. The files that have been migrated are purged from the disk cache because they already exist on a lower layer in the hierarchy. If there is enough space for the copy of all data off the failing partition, the diskdown utility completes the copy operation and returns successfully. If diskdown is passed the -c option, it will copy, rather than purge, files that have been migrated.

If the diskdown utility returns with an error, the system administrator must execute the forcemig utility to force another immediate migration from the disk cache. When migration has successfully completed, rerun the diskdown utility.

4. When the diskdown utility returns successfully, edit the diskdevs file and delete the line in the file that references the removed partition. In deleting the line that references the removed partition, do not renumber the logical device numbers of the partitions remaining in diskdevs.

5. To restart the Disk Server, type the command:

kill -HUP pid[diskd]

The server will exit, restart immediately by its daemon, diskd, and reread the diskdevs file when it comes up. At this time, the system administrator can safely use the disk partition for other purposes.

94/01/09 20:30:00 10045 Info migsrvr peso:20134

Mig Completed numfiles = 10

94/01/09 20:30:00 10030 Info migsrvr peso:20134

SLEEP waiting for more files

Mig Sleep numfiles = 0, numdisks = 4




IMPORTANT!Although the Disk Server catches the HUP signal to reread other configuration files, it must be restarted to induce it to reread diskdevs. This is because removing partitions from the disk cache requires the server to rebuild many of its data structures, a step taken only at server startup. “Disk cache” on page 187 provides information if a disk is lost before diskdown and can be used.

Disk cache 191

192



Tape header disks

Adding tape server header disk partitionsAt DXUL-SM installation, a set of disk partitions was dedicated to the Tape Server. The server uses these partitions to store its data structures, including file headers, a search table that locates the file headers and other structures. These data structures are kept on disk partitions because they are too large to store in main memory and because it would take too long to rebuild them at server startup.

Because the Tape Server keeps track of every file in DXUL-SM, except those not yet migrated off the disk cache, its data structures need special care. Therefore, the disk partitions that store them are shadowed to protect against loss of a single partition. Also, the major data structures on the partitions should be periodically backed up to tape. The backup procedure for these partitions is discussed in “Tape Server data structures” on page 176.

The <DISKXTENDER>/etc/tddevs file contains a list of the disk partitions dedicated to the Tape Server. The initial list was inserted into the file at DXUL-SM installation. There are two types of Tape Server disk partitions, header partitions and search table partitions. The search table partitions are the last two listed in tddevs. All other partitions in the file are header partitions.

The number of header partitions dedicated to the Tape Server can be increased from what was allocated at installation. The size of search table partitions can be increased from what was allocated at installation but may require extensive downtime to regenerate the search table from the tape header partitions.

The tdspace utility reports the percentage of available tape headers on the tape header disk partitions. The tdspace man page provides more information.

To add header disk partitions:

1. Choose new disk partitions in multiples of two. Each partition dedicated to the Tape Server has a secondary or shadow copy for redundancy. For each set of new partitions chosen, the shadow partition must be the same size as the primary partition.

2. Run zerodisk once for each of the new partitions:





This patterns the partition and returns its size in 4 KB blocks. Record the partition sizes returned by zerodisk. They will be used in step 3.

3. Edit the tddevs file and add the new partitions to the list of Tape Server disk partitions. Each line in tddevs describes a Tape Server disk partition. The format of each line in tddevs is:

logical_device_number/device_path size

The logical_device_number is used to number the partitions sequentially from 1 to 16. The size is the partition size in 4 KB blocks.

Add the new disk partitions as the last header partitions in tddevs. Insert them just before the search table partitions in the list. The search table partitions are the last two partitions in the list. When inserting the new header partitions, renumber the search table partitions so their logical partition numbers are the last two logical partition numbers in the file. Use the 4 KB block counts returned by the zerodisk utility in the size field for each new header partition entry in tddevs.

Example 18 If the tddevs file contained the following four partitions:

After editing tddevs to add /dev/rrz3a and /dev/rrz4a as two more header partitions of 48,000 4 KB blocks each, the file will look as follows:

1/dev/rrz1a 50000 Primary Search Tape Order Partition

2/dev/rrz2a 50000 Secondary Search Tape Order Partition

3/dev/rrz1b 64000 Primary Search Table Partition

4/dev/rrz2b 64000 Secondary Search Table Partition

1/dev/rrz1a 50000 Primary Search Table Partition

2/dev/rrz2a 50000 Secondary Search Table Partition

3/dev/rrz3a 48000 Primary Search Tape Order partition

Tape header disks 193

194



4. Restart the Tape Server:

kill -HUP pid[taped]

The taped daemon, taped, will restart the Tape Server immediately. At startup, the Tape Server rereads the tddevs file and uses the new header partitions.

Sending the Tape Server a HUP signal will not cause it to reread tddevs. Adding header partitions for the Tape Server requires the server to reinitialize some of its data structures. Rebuilding data structures is performed only at Tape Server startup.

Adding tape drives DXUL-SM can manage manually-mounted and robotically-mounted tape drives, and these drives are controlled either directly by the PVR or by the Volume Manager. Currently, DXUL-SM supports several types of robotic tape libraries and the Volume Manager (LTS): General SCSI robotic devices (SCSI), and the StorageTek Automated Cartridge System (STK). Appendix A, “Robotic Devices and the Volume Manager,” provides information on the Volume Manager and other robotic devices.

Information on editing each of the robot-specific configuration files and the Volume Manager can be found in Appendix A, “Robotic Devices and the Volume Manager.”

How to add tape drivesTo add new manually-mounted or robotically-mounted tape drives controlled by the PVR or by the Volume Manager, perform the following steps:

1. Edit the <DISKXTENDER>/etc/tpdevs file and add the new tape drive to the file in order to make it available to DXUL-SM.

2. Edit <DISKXTENDER>/etc/PVRINFO. The PVR (Physical Volume Repository) configuration file, PVRINFO, is processed by the PVR Server at initialization to determine the devices under its control.

4/dev/rrz4a 48000 Secondary Search Tape Order partition

5/dev/rrz1b 64000 Primary Search Table Partition

6/dev/rrz2b 64000 Secondary Search Table Partition




Note: If a manually-mounted drive directly controlled by the PVR is being added, skip Step 3 on page 199.

3. Edit the appropriate robot-specific configuration file if you are adding a robotically-mounted tape drive that is controlled directly by the PVR. The Volume Manager does not require a configuration file.

For example, if the PVRINFO file specifies the use of a StorageTek (STK) Automated Cartridge System controlled by the PVR, edit the <DISKXTENDER>/etc/STKINFO file to properly configure the system for each STK tape drive.

4. Restart the tape processes. Restarting the taped daemon, will restart all the tape processes, which includes both the Tape Server and the PVR Server.

Editing the tpdevs fileThe first step in the process of adding a new tape drive (manually-mounted or robotically-mounted) to DXUL-SM is to edit the <DISKXTENDER>/etc/tpdevs file, and add the new tape drive to the file. The file contains a list of all tape drives dedicated to DXUL-SM. Each line in the file contains a reference to a drive. The format of each line in tpdevs is:

logical_device_number:device_path:op={m;f;c;l}:set_number:let:aet

The logical_device_number is an integer between 1 and 64, which is sequentially assigned to devices in the tpdevs file. To add the drive to tpdevs, enter the logical_device_number, followed by the device_path operations allowed on the drive, the set_number from the <DISKXTENDER>/etc/tpset command to use, the let is the lazy eject time to use for the drive and aet is the aggressive eject time to use for the drive.

At a minimum, the logical_device_number, the device_path and a single op entry must be provided. Valid op values include: All, Cache, Migrate, Repack, FullBU, and PartBU. m, f, c, l are comma separated lists of the operation allowed on the drive based on media type, family, copy, and location.


196



Example 19 Entry for a tape drive controlled by the PVR:

3:/dev/rmt/3hn:All={12;*;*;*}:0:120:30Entry for a tape drive controlled by the Volume Manager:

1:/<DISKXTENDER>/adm/logicaltape/tape:Migrate={12;*;*;*}:0:-1

Note: Drives controlled by the Volume Manager must appear first in the tpdevs file. The first drive should start with 1 and increment sequentially thereafter until the end of the list of drives controlled by the Volume Manager. Drives controlled directly by the PVR may not be interspersed with tape drives controlled by the Volume Manager in the tpdevs file.

Editing the PVRINFO fileThe second step in adding new tape drives (manually-mounted or robotically-mounted) to DXUL-SM is to edit <DISKXTENDER>/etc/PVRINFO. PVRINFO is processed by the PVR Server at initialization to determine the devices under its control.

If a robotic tape library (SCSI, STK, or MTM) is specified in PVRINFO, the PVR Server will also read the configuration file associated with that robotic device (SCSIINFO or STKINFO). If the Volume Manager (LTS) is specified in PVRINFO, no configuration file is required.

Format of PVRINFO The format of PVRINFO is as follows:

name bitmap

where:

◆ name is the manual mount tape system (OPR), cartridge tape robot system (SCSI, STK, or MTM) or Volume Manager (LTS)

◆ bitmap is the 64 bit (2 X 32 bits) hex bitmap of the drives.

Example 20 tpdevs

The entries in PVRINFO must correspond to the logical number of the tape drive in <DISKXTENDER>/etc/tpdevs. An example tpdevs file showing tape devices controlled by the Volume Manager and directly by the PVR appears below. Devices under the control of the Volume Manager are listed first.




The PVRINFO file bitmap entries must have one bit set for each tape drive in use, represented in hexadecimal starting at the leftmost hex digit. The high-order bit is bit 1. The entries for multiple robots must not conflict. The OPR entry defines manual-mount tape systems, and an OPR entry with a bitmap of zero is required even if no manual-mount tape drives are used.

Editing PVRINFO Edit the PVRINFO file to include one optional configuration line for the Volume Manager (LTS), the required OPR configuration line for manual-mount tape drives, one optional configuration line for all STK cartridge tape drives, one optional line for all SCSI drives, and one optional line for MTM tape drives.

Example 21 PVRINFO

To set up PVRINFO from the example tpdevs file shown above, the Volume Manager line has bits 1 and 2 set, the OPR line has bit 3 set, the STK line has bits 4 and 5 set, the SCSI line has bits 6 and 7 set, and the MTM line has bits 8 and 9 set. The resulting example PVRINFO file entries are shown below:

1:/<DISKXTENDER>/adm/logicaltape/tape1:all={3;*;*;*} #LTS Volume Manager

2:/<DISKXTENDER>/adm/logicaltape/tape2:all={3;*;*;*} #LTS Volume Manager

3:/dev/rmt3h:All={5;*;*;*}:1:-1 #Manual-mount tape drive

4:/dev/rmt4h:All={7;*;*;*}:2:-1 #STK cartridge tape robot

5:/dev/rmt5h:All={7;*;*;*}:2-1 #STK cartridge tape robot

6:/dev/rmt6h:All={3;*;*;*}:3:-1 #SCSI media robot drive

7:/dev/rmt7h:All={3;*;*;*}:3:-1 #SCSI media robot drive

LTS C0000000 00000000

OPR 20000000 00000000

STK 18000000 00000000

SCSI 06000000 00000000

MTM 01800000 00000000


198



Configuration instructions for each robotic device are found in Appendix A, “Robotic Devices and the Volume Manager,”.

Restarting the tape server and the PVR ServerAfter editing the robot-specific configuration files or the Volume Manager configuration file, restart the tape processes. The Tape Server must reread the <DISKXTENDER>/etc/tpdevs file and the PVR Server must reread the PVRINFO file so that DXUL-SM can use any newly added tape drive.

To restart the tape processes:

% kill -HUP pid[taped]

The daemon for the tape processes, taped, will terminate all of the tape processes and restart the processes in the proper order. At startup, the Tape Server will reread the tpdevs file and will use the new tape drive. The PVR Server, at startup, will reread the PVRINFO file so DXUL-SM can use any newly added tape drive. Restarting the PVR Server in this fashion will cause it to reread the robot-specific configuration files.

Sending the Tape Server a HUP signal will not cause it to reread tpdevs. Adding drives to DXUL-SM requires the Tape Server to reinitialize some of its data structures. Rebuilding data structures is done only at Tape Server startup.

Sharing tape drives DXUL-SM can share drives with other processes if the drives are controlled by the Volume Manager. If the Volume Manager is not being used then DXUL-SM does not share tape drives with non-DXUL-SM processes. If a non-DXUL-SM process mounts a volume in a drive listed in the <DISKXTENDER>/etc/tpdevs file, and it is not controlled by the Volume Manager, DXUL-SM will eject the tape from the drive.

Sharing robotic tape librariesRobotic libraries that are controlled by the Volume Manager can be shared between DXUL-SM and other processes.

For robotic tape libraries that are directly controlled by the DXUL-SM PVR, sharing is robot-dependent. Of the libraries currently supported




by DXUL-SM, only the STK robotic tape libraries which are running ACSLS can be shared.

Removing tape drivesDXUL-SM can manage manually-mounted and robotically-mounted tape drives. Currently, DXUL-SM supports several types of robotic libraries and the Volume Manager (LTS): The StorageTek Automated Cartridge System (STK) and the generic SCSI Media Changers (SCSI).

To temporarily remove manually-mounted or robotically-mounted tape drives from DXUL-SM, use the tpdevdown utility. Tapes may be mounted in this downed drive with the mounttape utility and dismounted with the dismounttape utility. The tpdevup command is used to return the downed drive to DXUL-SM.

Information on editing each of the robot-specific configuration files can be found in Appendix A, “Robotic Devices and the Volume Manager.”

How to remove tape drivesTo permanently remove manually-mounted and robotically-mounted tape drives from DXUL-SM:

1. Edit the <DISKXTENDER>/etc/tpdevs file and delete the line in the file that references the drive to be removed from DXUL-SM.

Note: For the Volume Manager, always delete the highest numbered logical pathname assigned to the Volume Manager. Do not renumber the logical device numbers of the remaining drives in the file.

2. Change PVRINFO to take the drive offline (set the appropriate bit in the bitmask to 0).

3. Edit the appropriate robot-specific configuration file. Either set the flag to 0 (zero) or delete the line.

Note: There is no Volume Manager configuration file.

4. To restart the tape processes, type the following command:



200



Editing the tpdevs fileThe first step in removing tape drives (manually-mounted or robotically-mounted) from DXUL-SM is to edit the <DISKXTENDER>/etc/tpdevs file and remove the drive from the file. The file contains a list of all tape drives dedicated to DXUL-SM. Each line in the file contains a reference to a drive.

The format of each line in tpdevs is:

logical_device_number:device_path:op={m;f;c;l}:set_number:let:aet

The logical_device_number is sequentially assigned to devices in the tpdevs file. To remove the drive from tpdevs, delete the line that references the drive to be removed from DXUL-SM. Do not renumber the logical device numbers of the remaining drives in the file.

Note: When deleting a logical drive controlled by the Volume Manager, always delete the highest logical device number assigned to the Volume Manager.

Editing the PVRINFO file

The second step in removing tape drives (manually-mounted or robotically-mounted) from DXUL-SM is to edit the PVR configuration file, <DISKXTENDER>/etc/PVRINFO. PVRINFO is processed by the PVR Server at initialization to determine the devices under its control.

If a robotic library (SCSI, STK, or MTM) is specified in PVRINFO, the PVR Server will also read the configuration file associated with that robotic device (SCSIINFO or STKINFO) There is no configuration file associated with the Volume Manager. “<DISKXTENDER>/etc/PVRINFO” on page 117 provides information on the format of the PVRINFO file.

If a manually-mounted tape drive is in use, to bring it off-line, edit the PVRINFO file to change the bits in the OPR entry to clear the appropriate bit in the bitmap for the drive being removed. For example, to remove drive 3, with bit 3 set as in the OPR entry “OPR 20000000 00000000” in “Editing the PVRINFO file” on page 196, change the entry to:

OPR 00000000 00000000




Note: If the Volume Manager is controlling the manually-mounted drive, the OPR entry in the PVRINFO file should have all bits set to zero.

Restarting the tape processesAfter editing the robot-specific configuration files, restart the tape processes. The Tape Server will reread the <DISKXTENDER>/etc/tpdevs file and the PVR Server will reread the PVRINFO file to remove the drive from DXUL-SM.

To restart the tape processes:


The taped daemon, will restart the tape processes immediately. At startup:

◆ The Tape Server will reread the tpdevs file.

◆ The PVR Server, at startup, will reread the PVRINFO file. Restarting the PVR Server in this fashion will cause it to reread the robot-specific configuration files as well.

Sending the Tape Server a HUP signal will not cause it to reread tpdevs. Removing drives from DXUL-SM requires the Tape Server to reinitialize some of its data structures. Rebuilding data structures is done only at Tape Server startup.


202



Tape media

Adding data volumes to the tape server’s mapData tapes contain user file data, and are labeled internally as well as externally. At DXUL-SM installation, a Tape Server data structure called the tapemap was initialized (through the use of the setmap utility) with references to the data volumes dedicated to the system.

Tape labeling and tapemap field tasks are accomplished as separate operations, through the use of the tapelabel and settape utilities.

Once the tapemap fields are initialized, the Tape Server requests a tape referenced in the map whether or not the tape has been labeled. For more information on the DXUL-SM tape utilities, the man pages for checkmap, readmap, setmap, settape and tapelabel provides information.

The only way to prevent the server from requesting a volume referenced in the tapemap is to mark it as unavailable in the map using the settape utility.

To add data volumes, use the following command:

<DISKXTENDER>/adm/bin/settape -u unavail tapeid

Adding volumes to DXUL-SM is performed by either marking volumes already referenced in the tapemap as available or changing the status of unavailable volumes to available and making sure they are labeled. To internally label volumes for DXUL-SM, use the tapelabel utility:

<DISKXTENDER>/adm/bin/tapelabel -m mediatype dev volumelabel

The mediatype parameter specifies the media type to use from the <DISKXTENDER>/etc/tape.conf file. The dev parameter is the device pathname where the tape is mounted for labeling. If DXUL-SM is running, do not use any of the devices listed in <DISKXTENDER>/etc/tpdevs for labeling. The tapelabel utility rewinds and verifies the internal label, and then unloads the tape. The tapelabel man page provides information on options.




To mark a volumes as available in the tapemap, type the settape utility:

<DISKXTENDER>/adm/bin/settape -m mediatype -u unused volumelabel

where mediatype is the associated media in the <DISKXTENDER>/etc/tape.conf file.

By default, entries in the tapemap are initialized with volume labels starting at 000000. It is possible to change the volume label of an existing entry in the tapemap by using the settape command:

<DISKXTENDER>/adm/bin/settape -r new_volumelabel old_volumelabel

To see the new volume label in the tapemap, type the readmap command:

<DISKXTENDER>/adm/bin/readmap -t new_volumelabel

For StorageTek (STK) users, who are not using the Volume Manager, two scripts are available for labeling tapes. These scripts are for use with tapes in STK cartridge tape robots that use the ACSLS robotic package from STK. The scripts are:

◆ <DISKXTENDER>/adm/bin/stk_label for labeling single tapes.

◆ <DISKXTENDER>/adm/bin/stk_multi_label for labeling a group of tapes.

Use of these scripts is documented within each file.

After the tape label has been written, it may be verified using the readlabel utility:

% <DISKXTENDER>/adm/bin/readlabel device_path

To determine whether tapes have been previously marked as unavailable, run the readmap utility:

% <DISKXTENDER>/adm/bin/readmap -t tape_id

The readmap utility reports the status of each volume by volume label. When used with the -t option, it will show the status of a single volume or a range of volumes. Options also exist to examine tapes based on the fields in the tapemap. The readmap man page provides information.

Tape media 203

204



There are 12 types of status reported by the readmap utility, as shown in Table 25 on page 204.

Note: Unavailable volumes are reactivated by the settape utility.

Table 25 Status types reported by the readmap utility

Status Description Utility Used

TAPEID Volume label settape

MEDTYP Type of volume, from tape.conf file settape

CNT In-use block count0 - volume is empty

settape

LASTBLCK Block where next write will occur settape

USAGE Volume usage:• unused• migration• repack• partial backup• full backup• cache use (read-only)• unavailable

• setmap (used only at initialization)

• settape

FAM Family to which the volume is assigned settape

CPY Copy set which is stored on the volume settape

LOC Location of volume settape

RPKS Number of repacks settape

ERRS Read errors settape

MNTS Mounts settape

LST_ ACCS Last access time settape




Removing data tapesTo remove data volumes from DXUL-SM:

1. (Optional), use the readmap utility to view the current tapemap settings.

2. Use the settape utility to set the usage field on the volume to unavailable:


IMPORTANT!The CNT should not be changed. If the volume is ever put back into the DXUL-SM tape pool, the block count will be preserved and no data will be overwritten.

Data on volumes removed from DXUL-SM are not accessible until the volumes are again added to the system. To reactivate the volume, use settape to set the USAGE field.

Backup volumes Backup volumes contain copies of Tape Server data structures that can be restored in case of catastrophic loss of the Tape Server’s disk partitions. Like data volumes, their status can be checked and set through the DXUL-SM utilities readmap and settape.

Backup volumes must either be explicitly assigned in the tapemap using the settape command or the tapeserver.unused_for_backups parameter in the <DISKXTENDER>/etc/DiskXtender.conf file must be set to 1.

DXUL-SM backup volumes can be recycled. To recycle the backup volumes, use the settape utility to set the last block count (LASTBLK) to 0 on the backup volumes which are to be reused.

<DISKXTENDER>/adm/bin/settape -k blockcount tapeid

Note: When recycling backup volumes, try to save the two most recent sets for disaster recovery purposes. The backup set number is stored in the family field of the tapemap for backup volumes.

To remove a backup volume from DXUL-SM, use the settape utility to set the usage status to unavailable:


Tape media 205

206



If a backup volume is not mounted in response to a DXUL-SM mount request, backup will not be performed and the Tape Server’s data structures will not be preserved for restoration in the event of catastrophic loss of the Tape Server’s Disk partitions.

ACSLS server ACSLS is a feature in DXUL-SM for sharing or separating the data path and control path of the tape library between DXUL-SM and StorakeTek Server Running on Solaris 10.

The stk library is copied to all DXUL-SM supported platforms from Solaris. If the user has configured STK interface, pvrserver will use stk library to communicate with ACSLS server to perform the specified functionality.

To use the ACSLS feature after successful installation of DXUL-SM:

1. Edit tapedev configuration:

Modify the <DISKXTENDER>/etc/tpdevs file based on the drive numbers. During Storage Manager installation, by default the tpdevs file will represent the drive numbers.

To check for correct drive numbers:

• Run the mount command from the ACSLS server side and observe the drive numbers from the GUI.

• Run testrobot on the ACSLS server machine, and based on the sequence numbers (for example 500, 501) update the entries of tpdevs file.

2. Edit PVRINFO file.

<DISKXTENDER>/etc/PVRINFO contains the configuration parameters for the PVR Server. The PVR Server reads this file at startup to determine the type of devices under its control. For STK (StorageTek) robotic device, an entry will be added as STK to the PVRINFO file.

Format of PVRINFO:

name A B C D

where:

• Name is the name of the robot system (such as SCSI, STK).

• A is the highest-order 32 bits of the device bitmap in hex.

• B is the next low-order 32 bits of the device bitmap in hex.




• C is the next low-order 32 bits of the device bitmap in hex.

• D is the lowest -order 32 bits of the device bitmap in hex.

3. Copy STKINFO.default to STKINFO.

Copy the </DISKXTENDER>/etc/stkinfo.default to </DISKXTENDER>/etc/STKINFO and modify the STKINFO file based on your driver numbers.

4. Copy ssi.sh.default to ssi.sh file:

a. Copy the </DISKXTENDER>/etc/ssi.sh.default to </DISKXTENDER>/etc/ssi.sh.

b. Modify or uncomment the LD_LIBRARY_PATH and export LD_LIBRARY_PATH if they are commented.

c. Modify or uncomment the following lines:

– DISKXTENDER_ROOT_PATH="<DISKXTENDER> (/usr/diskx)

– export DISKXTENDER_ROOT_PATH– CSI_HOSTNAME="franc.legato.com" - ACSLS Server

Hostname (Solaris 10)– export CSI_HOSTNAME

d. Change the default permission of ssi.sh to executable (For example UNIX command chmod +x ssi.sh)

5. Edit rc.diskxtender file

Uncomment "taped_args" in <DISKXTENDER>/etc/rc.diskxtender file.

6. Run the rc.diskxtender command to start all the required services.

7. To set the tape label for all the tapes, run the query volume all from ACSLS server.

8. Run the tapelabel command for all the volumes detected by ACSLS server, which builds a volume list in the DXUL-SM.

9. settape

a. Mount the tape from ACSLS server side.

b. Run the tapelabel command from DXUL-SM side.

c. Run the settape command from DXUL-SM.

Tape media 207

208



System sizing controlDXUL-SM restricts the size of the DXUL-SM file system, based on the system size purchased, by examining the encrypted license value. This value sets the maximum allowable size for system storage. The value is then decrypted and checked by the Tape Server each time DXUL-SM migrates a file.

When a specific percentage of this value, as configured in the tapeserver.size_warning_threshold parameter in <DISKXTENDER>/etc/DiskXtender.conf is reached, DXUL-SM will begins to send warning messages to the token_log file.

If the secondary storage is allowed to fill to 100 percent of licensed capacity, DXUL-SM discontinues the migration of files from the disk cache. It is highly recommended that the system administrator make provisions to either purchase DXUL-SM storage space licensing or delete stored files prior to reaching storage capacity.



6


◆ Performing system backups ........................................................... 210◆ Monitoring the CML log and other log files ................................ 211◆ Mounting requested tapes .............................................................. 212◆ Maintaining free volumes in the system ...................................... 213◆ Core files............................................................................................ 214◆ Monitoring space in the DXUL-SM system tree.......................... 215

Scheduled Activities

Scheduled Activities 209

210



Performing system backupsSystem backups are one of the most critical procedures for system preventive maintenance. Recommendations include:

◆ Back up the Name Server once a day if journaling is not enabled.

◆ Run the backup utility at least once a week.

You can automate backups by using a UNIX cron entry.

“Name Server database” on page 172 and “Tape Server data structures” on page 176 provides information on backup procedures.

The DXUL-SM system tree should be periodically backed up. This ensures that if the file system which DXUL-SM is being run on is lost, the current configuration and log file information can be retrieved.




Monitoring the CML log and other log filesAll DXUL-SM log files are located in the <DISKXTENDER>/adm/log directory. The DXUL-SM servers and some utilities accomplish logging by communicating with the Common Message Logger (CML) Server, cmlsrvr, which writes the servers' log messages to a common log file, <DISKXTENDER>/adm/log/token_log. The token_log file is a tokenized log file that contains only a message number and variable data. The read_log utility translates the logged messages into text.

System administrators should examine the token_log at least once a day to ensure that the system is functioning properly. The read_log utility program is used to translate the tokenized log into human-readable form. For example:

read_log -b 2 -s 7

This reports all entries in the log with a brevity of 2 and a severity of 7 or higher. The read_log man page provides information.

The DXUL-SM daemons and some utilities write individual log files that are identified by the name of the daemon or utility that produced them with a .t suffix (for example, diskd.t). If the cmlsrvr is down, all servers will write to their respective .t log files.

Note: The backup.t log records each time a DXUL-SM partial or full backup occurs. This file should be manually backed up daily. In the event of disaster recovery, the backup.t file is used to restore the Tape Server disk partitions.

Monitoring the CML log and other log files 211

212



Mounting requested tapesAn essential task for DXUL-SM is promptly mounting volumes requested by the system. One delay in responding to user read requests is the time taken to manually mount volumes when the file is stored offline. Quick and consistent response to volume mount requests can dramatically reduce this delay and help provide users with satisfactory system performance.

DXUL-SM provides the pvrstats utility to display manual volume mount requests for the system. The utility reports the volume label identifiers of the requested volumes and the length of time in minutes the requests have been pending. The dxsem mount display queue may also be used for monitoring the volumes requested for mounting if an X-window display is available. The DiskXtender for UNIX/Linux Storage Manager Release 2.11 System Environment Manager Guide provides more details on dxsem.




Maintaining free volumes in the systemDXUL-SM should be supplied with enough free volumes so it can accept more user data for storage. Ensuring that the system is supplied with free volumes is critical keeping DXUL-SM operational.

To determine whether the system currently has adequate free volumes or needs volumes, run the readmap utility. The readmap utility reports the status of each tape by tape label.

To determine the number of free tapes, run the readmap utility as follows:

<DISKXTENDER>/adm/bin/readmap -u unused

The number of free volumes in DXUL-SM is the number of volumes reported by the readmap utility that has an in-use block count of 0 (zero) and usage value set to UNUSED.

Once a volume has been assigned to a particular family, location, and copy number, it can retain the assignment even after the volume reverts back to an UNUSED state when there are no more files on it. This behavior may be obtained by adding tunables to the DiskXtender.conf file. These tunables are:

◆ tapeserver.reset_tapemap_fam

◆ tapeserver.reset_tapemap_loc

◆ tapeserver.reset_tapemap_cnum

Setting these tunables to a value of 1, the default, will cause volumes to revert back to the free pool of tapes when there is no data remaining on them.

If DXUL-SM does not have enough free tapes, more tapes must be added. “Adding data volumes to the tape server’s map” on page 202 provides more information.

Maintaining free volumes in the system 213

214



Core filesIf a DXUL-SM process crashes, it will create a core file in the <DISKXTENDER>/adm/cores directory and records an error in the appropriate log file. Each process has its own subdirectory. The core file is located in the subdirectory of the corresponding process.

Examine the cores directory daily. If core files are being created continually, a server or daemon is crashing and the cause should be located. Contact your DXUL-SM support vendor for assistance in resolving crashes. Resolved core files should be deleted in order to conserve system disk space.




Monitoring space in the DXUL-SM system treeLog files and core files use space in the DXUL-SM system tree, <DISKXTENDER>. It is important that free space be maintained in the file system occupied by the system tree so that servers can adequately log activity. Check the <DISKXTENDER>/adm/log and <DISKXTENDER>/adm/cores directories occasionally for disk usage. Old log files can either be removed or stored in an alternate location, such as the DXUL-SM file system itself. Submit the core files to your DXUL-SM support vendor for determination of the problem. Core files may be removed once the cause of the problem has been determined.

Monitoring space in the DXUL-SM system tree 215

216





7


◆ DXUL-SM crashes at startup.......................................................... 218◆ Individual server crashes at startup.............................................. 219◆ DXUL-SM system crashes after startup........................................ 221◆ Individual server crashes after startup ......................................... 222◆ Performance...................................................................................... 223◆ FTP ..................................................................................................... 224◆ NFS..................................................................................................... 225◆ Manually mounted volumes .......................................................... 227

Troubleshooting

Troubleshooting 217

218

Troubleshooting


DXUL-SM crashes at startup

Privileges and permissionsDXUL-SM processes and servers write to devices that require access privileges to be set properly. While the permissions are set properly at install time, some systems reset the permissions when new hardware is added and new device files are created. If DXUL-SM crashes at startup, stop DXUL-SM and examine the permissions on the devices. The devices used are listed in the DXUL-SM configuration files (nsdevs, diskdevs, tddevs, and tpdevs). If the permissions are set improperly, change the permissions and then restart DXUL-SM. Chapter 4, “Routine Management Procedures,” provides more information.

The DXUL-SM servers may crash if the directories defined in the <DISKXTENDER>/etc/DiskXtender.path file are read-only. The results from the DXUL-SM processes attempting to create a log file at startup. If a server cannot create a log file by writing in the <DISKXTENDER>/adm/log directory, it will crash. Avoid this condition by making sure the directories in the <DISKXTENDER>/adm/log path are writable. If the permissions on a directory in the path need to be modified, change the permissions and restart DXUL-SM.

If DXUL-SM is normally run as a non-root user, but was run by root, the RPC communication used by DXUL-SM for interprocess communication may have insufficient permissions and may need to be removed. If servers results are not being able to register with RPC, check the current RPC information by using the rpcinfo command. If the program numbers for the DXUL-SM servers are registered as root, it may be necessary to delete them by using the rpcinfo command and restart the DXUL-SM servers.


Troubleshooting


Individual server crashes at startup

Configuration parametersIf DXUL-SM servers are crashing, they may have been configured incorrectly. For example, one or more of the disk partitions in <DISKXTENDER>/etc/diskdevs may no longer be accessible. If inaccessible partitions are in the diskdevs file, the Disk Server will crash.

Check all configuration files relating to a crashing server to ensure the files contain correct information.

Sockets If DXUL-SM servers are not starting, it may be due to a UNIX socket problem. The servers use sockets as the interface between the DXUL-SM communication protocol and TCP. Each server has a well-known socket address defined in <DISKXTENDER>/etc/DiskXtender.net. If a server is unable to start , check to ensure that another copy of the server is not already running. If it is already running, the running process will have the socket open and the second process will not be able to start.

A server may not be able to start if it is restarted too quickly after it has been shut down. This is due to socket closure delays in the local UNIX operating system. If the socket is still open when the server is restarted, the server will not be able to restart since it cannot open the socket. Restart the server only after its well-known socket has been closed by the operating system.

Example 22 Determining if a socket is open

One way to determine if a socket is still open is to use the netstat utility on the local system (if provided). Follow this procedure:

1. Take the last two numbers of each server's network address from DiskXtender.net and convert them to a port number as described in <DISKXTENDER>/etc/DiskXtender.net.

2. Type:

netstat -an | grep port_number

If a socket is still assigned to the port, wait 30 seconds and try again.

Individual server crashes at startup 219

220

Troubleshooting


NFS Most of the DXUL-SM NFS functionality is implemented in the Disk Server. The Disk Server will not start its NFS daemons if its NFS functionality cannot be executed.

If the Disk Server is reporting that it cannot start NFS, ensure that the portmap or rpcbind process is running.

Startup order of tape processesBefore starting any of the tape processes manually, shut down any tape processes that may be running. Once they are all down, start them in the following order, waiting 10 seconds between each: fake_el and ssi.sh (if the STK robot is in use), tapemovr, pvrsrvr, and tapesrvr. Failure to start the tape processes in this order may cause some problems.

Note: It is recommended that the tape processes be started by using the DXUL-SM persistence daemon, taped. The daemon will start the servers in the correct order with the proper wait time.


Troubleshooting


DXUL-SM system crashes after startup

File descriptors If DXUL-SM crashes after startup, the local UNIX operating system may have run out-of-file descriptors and hence the DXUL-SM servers could not open the necessary sockets for communication. If this is the case, increase the per process limit on file descriptors for the local UNIX operating system. The limits man page provides details on setting the systems configurable number of file descriptors.

UNIX file system full The DXUL-SM processes and utilities write to log files in the <DISKXTENDER>/adm/log directory created at installation. If the UNIX file system where this directory is located fills up, the processes will not be able to continue writing messages to their log files. If several of the servers are not logging after they have been running, ensure that UNIX file system that stores the token_log and other log files is not full.

Nohup On some UNIX systems, if processes are started by a user from a terminal login session, they and their child processes will die when the user logs off unless the processes are started with the nohup command.

DXUL-SM system crashes after startup 221

222

Troubleshooting


Individual server crashes after startup

Log files If an individual DXUL-SM Server continually crashes, begin troubleshooting by running the read_log command. Each server sends its error messages to the CML token_log file. The read_log command is used to extract specific information about the server errors from this token log. Corrective action is often suggested by the error message itself.

For example, if one server fails, its daemon will kill off all servers under its control and then restart them all. The daemon's error messages will indicate which process actually precipitated the daemon's actions and can be viewed in the daemons log file (for example, diskd.t). After determining which server is crashing, examine the token_log file for information specifically related to that server.

Disk processes and bad devicesThe Disk Server will crash if any of the disk partitions in its disk cache fail. If the Disk Server is crashing, check the system console log for UNIX error messages about failed disk partitions. To remove bad partitions from the disk cache, “Removing disk partitions from the disk cache” on page 189 provides more information.


Troubleshooting


Performance

Communication If the DXUL-SM servers are running but are not communicating with each other, check for a postinstallation IP address change in <DISKXTENDER>/etc/DiskXtender.net. If a server's address has been changed, it is necessary to restart the entire DXUL-SM system. Otherwise, the affected DXUL-SM server will be unable to communicate with the other servers or with other processes.

DXUL-SM processes use TCP sockets to communicate with each other. On some systems, the operating system may be slow to close sockets down once they are no longer being used.

The time between the time a socket is closed and the time the operating system actually releases the resources tied to the socket is called the Maximum Segment Length (MSL). The operating system must wait twice the MSL before releasing the resources related to the socket.

Since the MSL on most systems defaults to 120 seconds, this means that a socket’s resources will remain in use for up to 4 minutes after DXUL-SM is done with it.

If the system is heavily loaded, this can cause the system to run out of socket resources or for network performance to degrade. If the operating system allows tuning of the MSL, it is suggested that it be decreased to between 30 and 60 seconds.

Performance 223

224

Troubleshooting


FTPIf DXUL-SM appears to be functioning properly except that some FTP operations fail for some users, the most likely problem is insufficient permissions on certain directories and files accessed by DXUL-SM uftpd. Since uftpd runs with the privileges of the user accessing it, the following permissions must be set as shown below.

Set world run permission on:

◆ <DISKXTENDER>/etc (and all directories underneath)

◆ <DISKXTENDER>/bin (and all directories underneath)

◆ <DISKXTENDER>/bin/ddir

◆ /etc

Set world read permission on:

◆ <DISKXTENDER>/etc/DiskXtender.net

◆ <DISKXTENDER>/etc/DiskXtender.path

These permissions must remain as set. DXUL-SM does not need to be shut down while the permissions on these files and directories are changed. It can continue running since the change only affects uftpd, and it will be noticed the next time uftpd is run.

Occasionally users will experience I/O errors when using the FTP interface to DXUL-SM. The cause of these errors is usually FTP client timeout on the user's machine. FTP clients timeout for a variety of reasons, including heavy network traffic or network gateway crashes.

If users experience a burst of FTP I/O errors, check to determine whether a network delay is causing the FTP client to timeout.


Troubleshooting


NFSIf attempts to mount DXUL-SM fail, ensure that the DXUL-SM mount daemon, <DISKXTENDER>/bin/unfsmntd, is running. Also ensure that the operating systems mount daemon, mountd, is not running. On some systems, mountd is run from the inetd process. Check that inetd is not running mountd when an NFS mount request is received.

Mounts also fail if the <DISKXTENDER>/etc/xtab file is not synchronized with the <DISKXTENDER>/etc/exports file. The Disk Server builds the exports file at startup or when it receives a HUP signal. It converts the data to a format easier for a process to parse, adds some internal linkage information and writes the information to xtab. If xtab is zero length or older than exports, refresh it with:

kill -HUP pid[disksrvr]

It is not necessary to restart or signal unfsmntd, but the client mount request must be retried. To verify that the appropriate directories are being exported to the correct clients, run the systems showmount command with the -e option.

NFS clients experience response delays for a variety of reasons, including heavy network traffic, network gateway crashes, or more frequently, their files are being staged from tape to the disk cache. If NFS V2 users experience “NFS server not responding” errors, check to determine if the user is trying to stage a file.

The NFS client believes it is unable to communicate with the DXUL-SM NFS server because it is not getting responses to requests to read the file. Once the file is on the disk cache, the NFS server will respond to the read requests and the NFS client will report NFS server ok. In NFS V3, the user should receive a message that indicates the file is being retrieved from the archive.

In addition, NFS V2 operations (for example, ls) in directories which have outstanding NFS stage requests (that is, trying to read file which exists only on tape) may also appear to stop responding. This is because the NFS V2 client is queueing the requests for a particular file. Unfortunately, there is no way to cause the NFS V2 client to forward these requests while waiting for the file.

However, operations for other files in the directory, and the directory information itself is typically not queued. (For example, an ls -F will queue, because the ls code is trying to “stat” the staging file.

NFS 225

226

Troubleshooting


However, an ls with no options which only reads the directory will continue to respond. Be aware of aliased ls commands, however. Many users actually have the ls command aliased to a set of ls options which do “stat” the file.)

Sites are encouraged to mount DXUL-SM by using NFS V3 when available because of its superior speed and more flexible handling of stage requests.


Troubleshooting


Manually mounted volumesOne reason for poor performance in DXUL-SM systems that manage files on manually-mounted volumes is the delay in mounting requested tapes. Ensure volumes are mounted promptly, and follow the procedures described in “Mounting requested tapes” on page 212.

Manually mounted volumes 227

228

Troubleshooting




8


◆ Name Server database..................................................................... 230◆ Disk cache.......................................................................................... 234◆ Tape server disks .............................................................................. 236◆ Volumes ............................................................................................. 243

Disaster Recovery

Disaster Recovery 229

230

Disaster Recovery


Name Server database

IMPORTANT!Do not use the nscr utility when recovering from the loss of Name Server partitions. It will overwrite the recovered database, causing loss of all data.

Loss of a single Name Server partition

If one of the disk partitions dedicated to the Name Server fails:

1. Shut down namesd (this action will terminate the Name Server):

kill pid[namesd]

2. Choose a disk partition the same size as the remaining good partition in the pair. To determine the size of the remaining good partition, read its size field in the <DISKXTENDER>/etc/nsdevs file. The format of the file is:

The partition_path field is the site pathname to the primary partitions in odd-numbered lines and to the secondary partitions in even-numbered lines.

Note: The partitions constituting a partition pair in the nsdevs files must be the same size or the Name Server will crash.

3. Run the DXUL-SM utility zerodisk on the new partition:


The zerodisk utility patterns partition device_path and reports the partition size in 4 KB blocks.

Ensure that the size value returned by the zerodisk utility is the same as the value in the size field for the good partition pair in nsdevs. If the size reported by zerodisk is not equal to the size of

primary_partition_path_1 partition_size

secondary_partition_path_1 partition_size

primary_partition_path_n partition_size

secondary_partition_path_n partition_size


Disaster Recovery


the remaining good partition of the pair, do not proceed with the remaining steps. Instead, go to step 2 and choose a partition the same size as the remaining good partition. Then repeat step 3.

4. Edit the Name Server database configuration file, nsdevs, and change only the partition_path field of the failing partition in the file to the pathname of the newly allocated partition. The partition_size field in the line should already be sufficient for the new partition.

5. Copy the data from the remaining good partition in the partition pair onto the new partition by using a UNIX copy command. For example:

dd if=remaining_partition_pathname of=new_partition_pathname

6. Restart the Name Server by running namesd:

<DISKXTENDER>/adm/bin/namesd

Loss of a pair of Name Server partitions

If a pair of Name Server partitions fails simultaneously:

1. Bring down namesd (this action will terminate the Name Server):

kill pid[namesd]

2. Choose two new partitions of the same size as the failed pair. These partitions must be the same size as the failed pair or information in the existing database will be lost. Since the Name Server will perform raw I/O to the partitions, do not run mkfs or any other UNIX utility to prepare the new partitions.

3. Run the DXUL-SM zerodisk utility on each of the new partitions:

% <DISKXTENDER>/adm/bin/zerodisk device_path

The zerodisk utility patterns partition device_path and reports the partition size in 4 KB blocks.

Be sure the size value returned by the zerodisk utility is the same as the value in the size field for the failed partition pair in <DISKXTENDER>/etc/nsdevs. If the size reported by zerodisk is smaller than the size of the failed partition pair, do not proceed with the remaining steps. Instead, go to step 2 and choose a partition the same size as the failed partitions. Then repeat step 3.

Name Server database 231

232

Disaster Recovery


4. Edit the Name Server configuration file, nsdevs. Replace the pathnames of the failed pair with the pathnames of the replacement partitions. The partition sizes must remain the same as the previous size. The format of the nsdevs file is as follows:

The partition_path field is the pathname to the primary partitions in odd-numbered lines and to the secondary partitions in even-numbered lines.

Note: The partitions constituting a partition pair in the nsdevs files must be the same size.

5. Copy onto each new partition the most recent Name Server database backup of the failed primary partition. For example:

dd if=primary_backup of=new_primary_partition_pathname

Backup of the Name Server database is described in “Backup procedures” on page 172.

6. If Name Server journaling was enabled and journal files are available, then run the ns_edit utility. Type the journal command. The utility will then ask for the names of each journal file.

For example:

ns_editns_edit: journal

Type the journal pathname:

/saved/namejournal

7. If journal files were applied to the name data base, then ns_edit needs to be given the ccF command to update the free lists.





primary_partition_path_n partition_size

secondary_partition_path_n partition_size


Disaster Recovery


For example:

ns_editns_edit: ccF

8. Using the UNIX dd command, copy each new primary partition onto each new backup partition.

For example:

dd if=new_primary_partition_pathname \ of=new_secondary_partition_pathname

9. Restart the Name Server, by running namesd:

<DISKXTENDER>/adm/bin/namesd

Note: When restoring a set of partitions from a Name Server backup, restore ALL of the partitions from the backup. This is because there are links between objects on one partition to objects on other partitions. Restoring only one set of partition will result in possible corruption since the unrestored partitions may have links which did not exist when the backup was taken.

Name Server database 233

234

Disaster Recovery


Disk cacheIf a disk partition in the Disk Server’s disk cache fails, all data on the partition that was not previously migrated to tape will be lost. DXUL-SM does not shadow partitions in the disk cache. The system provides migration as the backup mechanism for the disk cache and caching as the retrieval mechanism. All data previously migrated to tape is available upon user request through caching. The system administrator should consider this design when setting set the migration configuration parameters.

If a disk partition dedicated to the Disk Server is failing:

1. Run the diskdown utility:

<DISKXTENDER>/adm/bin/diskdown logdisk

where logdisk is the logical device number of the partition from the <DISKXTENDER>/etc/diskdevs file.

If diskdown fails, it may be because there was not enough free space in the cache to hold the data from the failing partition. If so, run the forcemig utility to migrate files from the cache:

<DISKXTENDER>/adm/bin/forcemig -a

2. Bring down diskd:

Note: This action will terminate all of the disk processes.

kill -TERM pid[diskd]

3. Edit the diskdevs file and comment out with a leading ‘#’ the line describing the failing partition. Do not renumber the other partitions.

4. If the partition is to be replaced instead of removed, complete the steps in “Disk cache partitions are accessed” on page 187.

5. Restart the disk processes:

% <DISKXTENDER>/adm/bin/diskd


Disaster Recovery


If a disk partition dedicated to the Disk Server has failed and cannot be brought up, perform the following steps:

1. Bring down diskd (this action will terminate all of the disk processes):

kill -TERM pid[diskd]

2. Edit the diskdevs file and comment out with a leading ‘#’ the line describing the failed partition. Do not renumber the other partitions.

3. Restart the disk processes:

<DISKXTENDER>/adm/bin/diskd

4. Run the diskdown utility with some special cleanup options:

<DISKXTENDER>/adm/bin/diskdown -l -h logdisk

where logdisk is the logical device number of the failed partition from the <DISKXTENDER>/etc/diskdevs file.

5. The partition may now be replaced, complete the steps in “Disk cache partitions are accessed” on page 187.

Note that any unmigrated files on the partition that failed are now lost. Their name entries may be deleted using the ftp del command.

Disk cache 235

236

Disaster Recovery


Tape server disks

Loss of a single tape server partition

IMPORTANT!Do not use the setmap utility when recovering from the loss of Tape Server partitions. It will overwrite all of the tapemap data, causing a loss of all data.

If a disk partition dedicated to the Tape Server for its data structures fails:

1. Stop all of the tape processes by killing taped:

kill pid[taped]

2. Choose a new partition to replace the failed partition. This partition must be the same size as the failed partition. Do not run mkfs on the partition as the Tape Server will perform raw I/O to the partition.

3. Run the zerodisk utility on the new partition:


The zerodisk utility patterns partition device_path and reports the partition size in 4KB blocks. Remember the size returned by zerodisk as it is used in step 4.

Edit <DISKXTENDER>/etc/tddevs and replace the pathname of the failed partition with the pathname of the new partition. Each line in tddevs describes a Tape Server disk partition and has the format:

logical_device#/partition_pathname block_size

The logical_device# field is used to number the partitions sequentially from 1 through 255. The block_size is the partition size in 4 KB blocks.

Note: The existing logical partition number for the failed partition should be used for the new partition.


Disaster Recovery


4. Copy the data from the remaining good companion partition to the new partition using a UNIX copy command. For example:

dd if=companion_partition_pathname of=new_partition_pathname

The companion partition can be determined from the tddevs file. If the failed partition had an odd-numbered logical_device#, the companion partition is the partition that is one higher than the failed partition in tddevs. For example, if the failed partition has a logical_device# of seven, the companion partition is number 8.

If the failed partition had an even-numbered logical_device#, the companion partition is the partition that is one number lower than the failed partition in tddevs. For example, if the failed partition has a logical_device# of four, the companion partition is 3.

Note: If the block_size field is larger than the value returned by the zerodisk utility, repeat steps 2 through 4 before continuing with step 5.

5. Restart the tape processes by executing the tape daemon, taped:

% <DISKXTENDER>/adm/bin/taped

Loss of a pair of tape server partitionsIf a pair of companion disk partitions fail:

1. Bring down taped (this action will terminate all of the tape processes):

% kill pid[taped]

2. Choose new partitions to replace every partition allocated to the Tape Server in <DISKXTENDER>/etc/tddevs.

If any pair of Tape Server disk partitions fails, every Tape Server partition should be replaced, not just the failed partition pair. The good (non-failing) partition pairs should not be overwritten until it has been verified that the recovery procedure succeeded. At that time, the good partitions will become available for other uses.

Each partition in a pair must be the same size, and the pair must be the same size as the partitions in the pair they are replacing.

Tape server disks 237

238

Disaster Recovery


Note: If there are not enough partitions to replace all the Tape Server disk partitions, just the damaged pair may be replaced. However, all partitions should be backed up (using a UNIX copy command such as dd) before proceeding to step 3.

3. Run the zerodisk utility on each of the new partitions:

% <DISKXTENDER>/adm/bin/zerodisk device_path

The zerodisk utility patterns partition device_path and reports the partition size in 4 KB blocks. Remember the size returned by zerodisk as it is used in steps 9 through 11.

4. Examine the backup log file <DISKXTENDER>/adm/log/backup.t to determine the most recent full backup set of backup volumes written.

Full backups are initiated by the backup utility. “Tape Server data structures” on page 176 provides more information. The Tape Server’s file headers and search table are saved on backup tape.

Each line related to backup tapes contains information with the following format:

Only primary partitions are backed up. The last set in the full backup will always be the primary search table partition. Each primary partition will be written to a tape until the critical tape block or capacity is reached, then the partition will span to the next volume.

5. Examine the Tape Server log file backup.t to determine the transaction backup volumes. They are all of the volumes referred to on the partial backup lines in backup.t. These volumes will be used in step 9.

6. Determine which backup volumes from the most recent full backup hold the data for each primary partition. Only data from primary partitions is written to backup volumes.

Using the example in step 1, data from the first primary partition (primary tape header partition) is on volume, and data from the second primary partition (primary search table partition) is also on volume AMA209. Data from each primary partition starts at the indicated starting tape block of the backup volume.

tapeid #sectors_written logical_unit_copied start_sector start_block


Disaster Recovery


7. Recover the data from the most recent full backup to the new primary partitions, using the tptodsk utility:

% <DISKXTENDER>/adm/bin/tptodsk tapedev media_type \start_block diskdev starting_disk_sector number_of_sectors

where:

• tapedev parameter is the UNIX device where the backup tape is mounted.

• media_type parameter is an integer indicating the type of media mounted on the tape drive (located in the tapemap, and in the tape.conf file).

• start_block is the tape block where the backup begins. The diskdev parameter is the UNIX pathname to the primary partition (located in the tddevs file).

• disk_sector is the “startsector” from backup.t and the number_of_sectors is the “written sectors” from backup.t.

8. Mount each full backup tape and run tptodsk with the matching parameter from backup.t.

While using the example volume in Step 6 as a guide, to recover the Tape Server file headers, search table and tape map (mount AMA209):

tptodsk tapedrive media_type 128 first_primary_partition 2 8702

tptodsk tapedrive media_type 1234 second_primary_partition 1 2820

Note: The secondary partitions will be rebuilt in step 11 after the primary partitions are complete.

9. The transaction (partial) backup volumes (identified in step 5) are used by the logtodsk utility to update the tape header partitions and restore the most recent tape map:

<DISKXTENDER>/adm/bin/logtodsk

This command will prompt for the following:

• Tape Header Disk 1 (path/(e)nd):


240

Disaster Recovery


Enter the header partition pathname for the first primary header partition. When all the header primary partitions have been entered (do not enter the search partition), enter an “e” to end the list.

• Does the configuration appear correct? (y/n)

The header primary partition pathnames are displayed. Enter “y” to continue or “n” to re-enter the list of header partitions.

Example 23 Loss of pair of tape server partitions

• Search Table Disk (path)

Enter the primary search table partition pathname.

• How many search sectors

Enter the search value found in output of the token_log when the tapesrvr is started.

• Does the Search configuration appear correct (y/n)

The search partition and sectors are displayed before the question. Enter “y” to continue or “n” to re-enter the search partitions and sectors again.

• Tape Device containing tape log (path)

Enter the tape drive pathname where the transaction backup tape is mounted. (Using the example for backup.t, the partial backup tape AMA210 is mounted during this step).

• Media type

Enter the media type of the volume which the partial backup is being restored.

• How many disk sectors for partial backup #1 (0 to end)

This value is the number of sectors written as part of the partial backup. It is obtained from the backup.t file.

Disk Pathname

1 /dev/rdsk/602S2

2 /dev/rdsk/603S2

3 /dev/rdsk/604S2


Disaster Recovery


When the utility has updated the tape header partitions specified, a message will be returned:

Done rebuilding tape disks, headers updated xxx

Repeat step 8 for each partial backup in the backup.t file after the last full backup.

Note: For tapes, be sure to use non-rewind devices when running logtodsk.

10. Each file header partition contains a free space header map that maps the free header space for that partition. The diskmap utility will build the map starting at block 1. The format of the diskmap utility is:

<DISKXTENDER>/adm/bin/diskmap device_path hdrsector disksize RWflag

Where the device_path is the header partition pathname, hdrsector is the 4K offset from the beginning of the disk partition where the headers are stored (found in backup.t during step 4 as the start sector). The disksize parameter is the size in 4K blocks of the header partition from zerodisk in step 3. RWflag indicates where to send the output. To write to disk, the RWflag string must be the ASCII string WRITE.

Using the example in step 4, run diskmap for the primary header partition. The example for the first primary partition is as follows:

<DISKXTENDER>/adm/bin/diskmap first_primary_partition 2 8704 WRITE

11. Copy the restored data from each primary partition to its companion secondary partition:

dd if=primary_partition of=companion_partition

12. Edit tddevs to delete all references to the old partitions and insert references to the new partitions. Each line in tddevs describes a partition. The format of each line is:

logical_partition_number/partition_pathname size

The logical_partition_number is used to number the partitions sequentially from 1 through 16. The primary partitions are odd-numbered. The secondary partitions are even-numbered.


242

Disaster Recovery


The size is the partition size in 4KB blocks. The search table partitions must be the last two partitions in tddevs. Use the size value returned by the zerodisk utility in Step 3.

Note: The disksize utility may be used to return the number of blocks on a given partition. The utility takes the parameters dev (device name) and blocksize (the block size that is used to define the number of blocks, always 4096).

13. Restart the tape processes by executing the tape daemon, taped:

<DISKXTENDER>/adm/bin/taped

14. Mark the volumes used in the recovery process as unavailable using the settape utility. This is to prevent premature overwriting of the current backup set. Remove the restore volumes from the system until sufficiently satisfied that the restoration processes have succeeded.


15. Run the checkmap utility to verify and modify, if necessary, the tape block counts in the tape map:

<DISKXTENDER>/adm/bin/checkmap primary_search_partition

The checkmap utility reads the header partitions and calculates the tape block counts based on the header information. These calculated block counts are compared to the tape map block counts. The utility will prompt whether block counts should be changed if a discrepancy is found. Any differences should be changed.

16. Change the usage of all tapes marked for migration and repacking to be cache. The following two commands will automatically reset the MIGRAT and REPACK tapes to become CACHE tapes:

readmap -u migrate | grep MIGRAT | awk ‘{print $1}’ | xargs -n1 \ settape -u cache

readmap -u repack| grep REPACK | awk ‘{print $1}’ \| xargs -n1 settape -u cache

17. Run a full backup:

<DISKXTENDER>/adm/bin/backup


Disaster Recovery


VolumesIf a volume managed by the Tape Server fails, the data on the volume will be lost. DXUL-SM does not shadow data on each volume. Use the multiple file copy feature to accomplish shadowing of files. “Multiple file instances” on page 67 provides more information.

Loss of a volume with multiple file copies running

When duplicate copies are being made, it is easy to re-create the destroyed volume. To do this, mark the tape as unavailable using the settape command. For example:

% <DISKXTENDER>/adm/bin/settape -u unavail tape_id

Then supply a forcepack to the Repack Server with the tape_id as the item to repack. For example:

% <DISKXTENDER>/adm/bin/forcepack -i tape_id

This will cause the Repack Server to find all the files which are on tape_id and issue stage requests for them. Since tape_id has been marked as unavailable, the DXUL-SM system will report this and then the files will be staged from an alternate copy. The files will be remigrated (repacked) onto a new volumes with the same parameters (copy number, family) as tape_id.

Loss of a volume without multiple file copies running

When a volume is lost or damaged and multiple file copies are not being made, most of the data on the volume will probably be lost. If the tape is still available, but reporting errors, first try a forcepack and see if any files can be recoverd from the tape. For example:

% <DISKXTENDER>/adm/bin/forcepack -i tape_id

This will cause the Repack Server to find all the files which are on tape_id and issue stage requests for them. Since this tape is failing, there may be a large number of errors.

The repack server will try to stage each file twice before giving up. Any files that were staged will be remigrated (repacked) onto a new volumes with the same parameters (copy number, family) as tape_id.

Volumes 243

244

Disaster Recovery


After forcepacking the tape, any files that are still on the tape will have to be manually removed from the DXUL-SM system. First set the tape to unavailable so that it is no longer requested by the tape system, for example:

% <DISKXTENDER>/adm/bin/settape -u unavail tape_id

Then run the tphdrdump command to find all of the files that remain on the tape. For example:

% <DISKXTENDER>/adm/bin/tphdrdump -r -t tape_id

The pathnames returned by tphdrdump represent all of the files that are on the lost tape. Each file should be checked to see if it is still on the disk cache. If the file is on the cache, it may be copied and the file’s data has hence been saved. If the file is not on cache, then it must be removed with ftp. This is done by root using the del command.

To read the files and their attributes in the order that they are stored in the tape through an existing tphdrdump utility, use the tphdrdump utility with the o option and the specified tape id (volume id). Option o will work with the tphdrdump options -r and -t. For example:

tphdrdump -o -r -t <target tape id >

Here -r is optional but -t option is must.



9


◆ Replication manager........................................................................ 246◆ Install Replication Manager............................................................ 247◆ Configure the primary DXUL-SM system for the remote RM .. 250

Disaster RecoveryManager

Disaster Recovery Manager 245

246

Disaster Recovery Manager


Replication managerThe Replication Manager (RM), allows a DXUL-SM system to use a robot or drives attached to a remote system. This can assist a site in guaranteeing data safety by locating one copy of the site’s data at a geographically different location than the primary copy. For instance, by having the first copy of each file written to one robot and the second copy going to a remote robot, the data is protected against the loss of a single robot and its media.

The RM uses only a small contingent of the DXUL-SM servers. Only the tapemovr, to move data to and from the secondary storage, and the pvrsrvr, to control the robot, are run on the remote machine. All of the tape databases and file metadata is maintained on the DXUL-SM server and is accessed by the tapesrvr running there. Before setting up an RM, the site should install and test the DXUL-SM system. After the system is up, proceed with installing the RM components.




Install Replication ManagerWhile the Install GUI does not explicitly provide for setting up an RM, the Install GUI may still be used to install and configure an RM system.

Mount the CD-ROM and perform an installation, with the following changes:

1. When the system asks for a License String, do not enter one. Click Next.

The Install GUI will report that the system is running with a 30 day license. However, only the tapesrvr uses the license key, so the limit will not apply.

2. In the System Sizing window, click Next. These values are not needed for setting up an RM.

3. For the DXUL-SM databases, specify dummy files such as /tmpspace/UTtapehb and /tmpspace/UTtapehb.

Set the size of each to 20MB, the system minimum. These will not be used and can be removed after the installation is complete. Do this for the name, tape header, and tape search database and the disk cache.

4. For the Peripheral Device Setup, proceed as normal.

5. For the Storage Volume Setup, proceed as normal, but ensure the labels assigned for the media will not conflict with the labels currently being used by the DXUL-SM system or other RM systems.

6. For DXUL-SM User Authentication, User Setup, FTP Port Setup, NFS Port Setup, and NFS Exporting, do not make any changes and click Next.

The configurations in these screens are not used for RM systems.

7. For the System Configuration Checklist window, ONLY Label storage volumes and Enter DXUL-SM server information in /etc/rpc can be set to Yes. All others must be set to No.

8. In the DXUL-SM Installation Steps window, click Install and let the system configuration happen automatically.

Install Replication Manager 247

248



The installation will complete with the DXUL-SM has been installed popup window. Ignore the information in this window; it is only useful for a standard DXUL-SM installation.

Dismiss this window and make the following changes:

1. Edit the <DISKXTENDER>/etc/DiskXtender.net file so that the following have the IP address of the machine where the DXUL-SM system is running:

• NAMESRVR

• DISKSRVR

• DISKMOVR

• REPACKSRVR

• TAPESRVR

• MIGSRVR

The IP address is stored as the first 4 dot numbers after the server name. They will be set by installation package to 0.0.0.0 (localhost). Change them to the IP address of the machine where the DXUL-SM system is running.

2. Edit the <DISKXTENDER>/etc/DiskXtender.net file so that the following have the IP address of the machine where the RM system is running:

• CMLSRVR

• PVRSRVR

• TAPEMOVR

The IP address is stored as the first 4 dot numbers after the server name. They will be set by installation package to 0.0.0.0 (localhost). Change them to the IP address of the machine where the RM system is running.

Example 24 DiskXtender.net on RM:

# RM is 198.137.240.92, DXUL-SM is 198.41.0.6.NETADDR CMLSRVR198.137.240.92.255.2NETADDR NAMESRVR 198.41.0.6.255.4NETADDR DISKSRVR 198.41.0.6.255.6NETADDR DISKMOVR 198.41.0.6.255.8NETADDR REPACKSRVR 198.41.0.6.255.12NETADDR PVRSRVR 198.137.240.92.255.18NETADDR TAPEMOVR198.137.240.92.255.25NETADDR TAPESRVR 198.41.0.6.255.20




NETADDR MIGSRVR 198.41.0.6.255.32

3. Edit the <DISKXTENDER>/etc/DiskXtender.conf file on the RM machine, turning on the two RM control variables:

pvrserver.IsDTS=1 # zero is off, positive is ontapemover.IsDTS=1 # zero is off, positive is on

4. Modify the robot INFO files (for example, SCSIINFO, STKINFO, and so on.) on the RM machine, so they do not overlap the INFO files on the DXUL-SM system.

For example, if the DXUL-SM and RM machine each had an SCSI controlled robot with four drives, the SCSIINFO file on each machine would, after an install, look like:

SCSI /dev/rsst1 80000000 00000000 1 40000000 00000000 1 20000000 00000000 1 10000000 00000000 1

On the RM system, the drive bitmap must be shifted so its bits do not overlap those of the DXUL-SM system or any other RM system. For example, it could be made to look like the following:

SCSI /dev/rsst1 08000000 00000000 1 04000000 00000000 1 02000000 00000000 1 01000000 00000000 1

The PVRINFO file must also be updated on the RM and DXUL-SM system to reflect the changes to any INFO files.

5. Remove the temporary database and disk cache files which were created during the installation process as they are not needed.

This completes the configuration of the RM. The RM will only run three DXUL-SM servers: the cmlsrvr, the pvrsrvr, and the tapemovr. The cmlsrvr may be started using the persistence daemon cmld. The tapemovr and pvrsrvr may be started using the persistence daemon taped with the -P and -M options.

Do not use <DISKXTENDER>/etc/rc.diskxtender for starting RM as it is not set up for running the RM.

The system can be monitored using read_log, and stopping with the -c option for the cmlsrvr, the -p option for the pvrsrvr, and the -T option for the tapemovr. pvrstats may be used to monitor the RM robot.

Install Replication Manager 249

250



Configure the primary DXUL-SM system for the remote RMThe DXUL-SM system which the RM is part of needs several changes to begin moving data to and from the RM:

1. Add the RM tapemovr and pvrsrvr to the <DISKXTENDER>/etc/DiskXtender.net file:.

TAPEMOVR1 X.X.X.X.255.25TAPEMOVR2 X.X.X.X.255.25...TAPEMOVRN X.X.X.X.255.25

and

PVRSRVR1 X.X.X.X.255.18PVRSRVR2 X.X.X.X.255.18...PVRSRVRN X.X.X.X.255.18

Where N is the total number of RM systems and the X’s are replaced with the IP address of each server where the associated UTDS is running. The tapemovr and pvrsrvr running on the DXUL-SM system are simply known as TAPEMOVR and PVRSRVR and will already exist in the DiskXtender.net file.

2. Configure the network addresses for the DiskXtender DFS system in the <DISKXTENDER>/etc/DiskXtender.net file.

Each SRVR/MOVR should use the explicit IP address of the machine where the RM system is running, not 0.0.0.0 or 127.0.0.1, which is used for localhost.

Example 25 DiskXtender.net on DXUL-SM system

#RM is 198.137.240.92, DXUL-SM is 198.41.0.6NETADDR CMLSRVR 198.41.0.6.255.2 NETADDR NAMESRVR 198.41.0.6.255.4 NETADDR DISKSRVR 198.41.0.6.255.6 NETADDR DISKMOVR 198.41.0.6.255.8NETADDR REPACKSRVR198.41.0.6.255.12NETADDR PVRSRVR 198.41.0.6.255.18NETADDR PVRSRVR1 198.137.240.92.255.18NETADDR TAPEMOVR 198.41.0.6.255.25NETADDR TAPEMOVR1198.137.240.92.255.25NETADDR TAPESRVR 198.41.0.6.255.20NETADDR MIGSRVR 198.41.0.6.255.32




3. Edit the <DISKXTENDER>/etc/tpdevs file to include the remote RM secondary storage drives.

Merge the remote RM tpdevs file into the DXUL-SM system’s tpdevs file. Each drive number must be mapped using the INFO file from each system. The new tpdevs file format is required for this configuration. The tpdevs(7) man page provides detailed information.

For example, if the DXUL-SM and RM tpdevs files both looked like:

1:/dev/rmt/0cn:all={3;*;*;*}:0:602:/dev/rmt/1cn:all={3;*;*;*}:0:603:/dev/rmt/2cn:all={3;*;*;*}:0:604:/dev/rmt/3cn:all={3;*;*;*}:0:60

and the INFO files on the remote RM had been shifted as in the preceding example, the final tpdevs file on the DXUL-SM system would look as follows:

1:/dev/rmt/0cn:all={3;*;*;*}:0:602:/dev/rmt/1cn:all={3;*;*;*}:0:603:/dev/rmt/2cn:all={3;*;*;*}:0:604:/dev/rmt/3cn:all={3;*;*;*}:0:605:/dev/rmt/0cn@tapemover1:all={3;*;*;*}:1:606:/dev/rmt/1cn@tapemover1:all={3;*;*;*}:1:607:/dev/rmt/2cn@tapemover1:all={3;*;*;*}:1:608:/dev/rmt/3cn@tapemover1:all={3;*;*;*}:1:60

The @tapemover1 is required so DXUL-SM can find the machine with these drives using the DiskXtender.net file and the TAPEMOVR1 entry. For clarity, @tapemover0 may be used for drives attached to the system running DXUL-SM.

To control resource allocation, use the tpset(7) capability to distinguish between the DXUL-SM system and each RM. The tpset(7) man page provides details about configuring tape sets.

4. The DXUL-SM system then needs to be restarted so that the new network addresses take effect. It will then know about the remote RM.

5. The DXUL-SM system must be configured with the media available on the RM system. Each tape must be added to the DXUL-SM system’s tapemap using settape.

The RM is now ready to use. When making two copies of files, for example, the first copy may be sent to the DXUL-SM tape system and

Configure the primary DXUL-SM system for the remote RM 251

252



the second copy of files sent to the RM by setting the tpdevs copy field.



10


◆ Volume export and import utilities ............................................... 255◆ Set the DXUL-SM environment ..................................................... 256◆ The export utility.............................................................................. 257◆ The import utility............................................................................. 263◆ The remove utility............................................................................ 269

Volume Export andImport

Volume Export and Import 253

254

Volume Export and Import


DXUL-SM 2.11 release includes Volume Export and Import. Utilities included in this release enable the following:

◆ Selection of a set of archive volumes to export.

◆ Creation of an interchange datafile (IDF) representing the selected export set.

◆ Creation of a remap file, to map current file attributes to new values, for all files included in the IDF.

◆ Export of the volumes, including all data and all relevant metadata, to a new instance of DXUL-SM.

◆ Import of the volumes and metadata described by the IDF into a new DXUL-SM instance.

◆ Additional import options:

• Remap of file attributes, using the remap file.

• Uniform truncation of the pathnames of files as they are imported.

• Addition of new leading pathname segments to files as they are imported.

◆ Removal of all files and all relevant metadata (referred to in an IDF) from the exporting DXUL-SM instance.

The number of archive volumes represented by the IDF can range from one volume to all of the volumes in the system. Volumes included in the IDF are selected by using a variety of user-specified criteria.




Volume export and import utilitiesThe utilities mkidf, applyidf, and delidf are used to perform volume exporting and importing. These utilities are located in the /usr/diskx/adm/bin directory on the DXUL-SM system.

Note: The path segment /usr/diskx represents the full path to the DXUL-SM installation directory.

Volume export and import utilities 255

256



Set the DXUL-SM environmentTo have the volume export and import utilities readily available, as well as all other DXUL-SM tools and the relevant man pages, use one of the two environment setup scripts provided in the /usr/diskx/etc directory:

◆ The diskxtender.login script for an environment using the C shell (csh) command interpreter.

For the C shell, type the command:

source /usr/diskx/etc/diskxtender.login

◆ The diskxtender.profile script for an environment using the Korn shell (ksh) or Bourne shell (sh) command interpreters.

For the Korn or Bourne shells, type the command:

. /usr/diskx/etc/diskxtender.profile

Note: These scripts should only be used to set the environment for a user who has the appropriate device and file permissions.




The export utilityThe DXUL-SM export utility, mkidf, creates a plain ASCII text file, called an interchange datafile (IDF). This file contains all of the information necessary to transfer archive volumes from one instance of DXUL-SM to another. An IDF is created by using the mkidf options to define the group of volumes to be exported.

The mkidf utility is executed from the command line by a user with appropriate device and file permissions. It creates an IDF in the current working directory. By default, the IDF is named dxmmddyy.idf, where mmddyy is the current date. The default name can be changed, but will always include the .idf extension.

To use the mkidf utility the following prerequisites must be met:

◆ Each volume to be included in the IDF must have its Usage field set to CACHE (read-only).

◆ Where a volume included in the IDF contains a file which spans multiple volumes, all volumes containing a part of the file must be included in the IDF.

IMPORTANT!The mkidf utility quits and returns an error message when any file spans more than three volumes. If this occurs, repack each such file onto a media-type that can hold the entirety of the file in three or less volumes.

Syntax The syntax for mkidf is:

mkidf [[-f family] [-c copy] [-l location] [-m media-type] | [[-f family] [-c copy] -n] | [-t volume-label]] [-p] [-R] [-o idf-name]

Options The options for mkidf are described in Table 26 on page 258.

The export utility 257

258



Table 26 mkidf Utility options (page 1 of 2)

Option Description Not compatible

-f family The -f option takes the argument family, where family is the family number of a group of volumes to be included in the IDF. Only one family number can be specified by this option in any IDF. This flag will exclude from the IDF all volumes which do not have the supplied family number.

-t

-c copy The -c option takes the argument copy, where copy is the copy number of a group of volumes to be included in the IDF. Only one copy number can be specified by this option in any IDF. This flag will exclude from the IDF all volumes which do not have the supplied copy number.

-t

-l location The -l option takes the argument location, where location is the location number of a group of volumes to be included in the IDF. Only one location number can be specified by this option in any IDF. This flag will exclude from the IDF all volumes which do not have the supplied location number.

-t

-m media-type The -m option takes the argument media-type, where media-type is the media-type number of a group of volumes to be included in the IDF. Only one media-type index number can be specified by this option in any IDF. This flag will exclude from the IDF all volumes which do not have the supplied media-type index number.

-t

-t volume-label The -t option takes the argument volume-label, where volume-label, is the label assigned to a particular DXUL-SM archive volume. This option can be repeated, as needed, to supply mkidf with the volume labels of all volumes that should be included in the IDF.

-f, -c, -l, -m

-n The -n option instructs mkidf to only include zero length files which are referred to by other options.

-l, -t, -m




How to create an interchange datafile

To create an interchange datafile (IDF):

1. Determine which volumes should be exported.

2. If necessary, use the settape utility, to set all volumes that are to be exported, to the CACHE usage state. Log in as the DXUL-SM user and enter the following command:

/usr/diskx/adm/bin/settape -u cache vol-id

where vol-id is the six-byte volume label for the volume being set.

3. Determine which mkidf option, or combination of options, is required to specify the volumes to be exported.

Note: It may be necessary to create several IDFs to encompass all of the volumes to be exported. If that is the case, be sure to use the -o option to assign a different name to each file. If the default name is used, then each subsequent IDF will overwrite the previous one.

-p The -p option instructs mkidf to display its progress on the screen.

-R The -R option instructs mkidf to generate a remap file. The remap file is created in the current working directory. It is named idf-name.map where idf-name represents the name of the IDF. The default dxmmddyy is used as the idf-name unless the -o option is specified.

-o idf-name The -o option instructs mkidf to name the IDF: idf-name.idf, where idf-name represents a user specified file name. This argument does not accept pathnames.

Table 26 mkidf Utility options (page 2 of 2)

Option Description Not compatible


260



4. Determine whether remapping is appropriate for the user ID, group ID, family, and media values of any of the files referenced in the IDF. If so, use the -R option with mkidf.

5. As a user with the appropriate device and file permissions issue the mkidf command with the appropriate options and arguments, and with the DXUL-SM system running.

6. Use the mkidf command as many times as needed to create IDFs which include all of the volumes to be exported. To avoid having an IDF overwritten by a subsequent one with the same name, always use the -o option when creating multiple IDFs.

Example 26 Generating an IDF for all files in a family and location

To generate an IDF for all files with family number 1 and location number 3, run the mkidf command:

mkidf -f 1 -l 3

Example 27 Generating a uniquely-named IDF and remap file for two volumes

To generate an IDF that accomplishes the following:

◆ Export all files on two tapes (AMA123 and AMA124).

◆ Create a remap file.

◆ Name the resulting IDF "export01.idf", and the resulting remap file "export01.map".

Type the mkidf command:

mkidf -t AMA123 -t AMA124 -R -o export01

Preparing a remap file

When you use the -R option with the mkidf command, a remap file is generated. A remap file consists of three columns which are separated by spaces:

◆ The first column is the FIELD column. This column lists, on each successive row, the file fields that are available for remapping in the volumes which are part of the current IDF.

◆ The second column is the OLD column. It lists the value of each available field before remapping.




◆ The third column is the NEW column. It lists the value of the field after remapping. Until the remap file is edited, the values in the OLD and NEW column are identical.

To prepare the remap file to use during the import process, open it in a text editor, such as vi, and change the value in the NEW column for each field to be remapped. Figure 9 on page 261 shows a typical remap file before any changes are made. Figure 10 on page 261 shows a remap file after editing.

Note: You can remap some values and leave others the way they are.

Figure 9 Remap file before Editing

Figure 10 Remap file after Editing

Field Old NewUID 0 1UID 1090 1090UID 1190 1190GID 1 1GID 5 5GID 1000 1000FAMILY 0 0MEDIA 2 2

Field Old NewUID 0 1UID 1090 100UID 1190 110GID 1 1GID 5 2GID 1000 1000FAMILY 0 0MEDIA 2 150


262



Accommodate tape.conf inconsistencies between two systemsThe ability to remap the media-type of volumes is particularly useful when the tape.conf parameters for a particular media-type are not the same on the exporting and importing systems.

To accommodate inconsistent tape.conf parameters on two systems:

1. Log in as the DXUL-SM user on the importing system.

2. Set the DXUL-SM environment, “Set the DXUL-SM environment” on page 256 provides information.

3. Start the tapeconf utility:

tapeconf

4. Type A to select the Add media-type option.

5. For each parameter, enter the value used by the media-type on the exporting system.

This assigns the parameters that are listed in the exporting system's tape.conf file, for the existing media-type, to the new media-type on the importing system.

6. At the Add/Delete/Modify Entry/Exit prompt, select E to exit.

7. Type Y to save the changes and exit.

8. Use the IDF remap file to remap the index number for media-type on the exporting system to the index number of the new media-type on the importing system.




The import utilityThe import utility, applyidf, runs on the system which hosts the DXUL-SM instance into which the IDF volumes are being imported. The import utility takes as its argument the name of an IDF. The IDF must be copied from the exporting system to the importing system. When the applyidf command is issued, the current working directory must contain the IDF and, if it is being used, the remap file.

The volume labels of all archive volumes referenced in the IDF cannot duplicate volume labels that already exist in the importing DXUL-SM system. To determine whether there are any duplicate label problems, and for information on how to work around the problem, “Duplicate volume labels” on page 264 provides information.

The import utility can be used to change the pathnames of files, as they are imported. To do this, specify a portion of the filepath to truncate from the pathnames of imported files. That specified filepath segment will be removed from all files which have a pathname that begins with it. If appropriate, specify a filepath segment to add to the beginning of all pathnames. The specified filepath segment is added to the beginning of the pathnames of all files that are imported. The filepath addition operation occurs after any pathname truncate operation.

Example 28 Changing pathnames of imported files

The pathnames of files are to be changed, during import of the dx0100103.idf file, as follows:

◆ Remove the path segment /usr/home from the beginning of all pathnames.

◆ Add the path segment /importset01 to the beginning of all pathnames.

Enter the following applyidf command:

applyidf -r /usr/home -a /importset01 dx010103

All pathnames that begin with /usr/home first have that filepath segment removed. Then the filepath segment /importset01 is added to the beginning of every imported file’s pathname.

The import utility 263

264



New directories created during importingWhen new directories are created by the path addition option, the user ID, group ID, and permissions of the new directories are set by using the applyidf utility. If these values are not specified, they are set to their default values. The default values are as follows:

◆ UID = 0

◆ GID = 0

◆ Permissions = 0777

Files which are in a trash can, located in an exported directory are imported by applyidf only:

◆ If a trashcan exists on the same filepath, on the importing system, the files are placed in that trashcan.

◆ If a trashcan does not exist on the same filepath, a directory named .trash is created on the exported filepath and the files are placed in that directory.

Any .trash directory created in this fashion is not a DXUL-SM trashcan. The files in a .trash directory, created by applyidf, are not affected by DXUL-SM trashcan rules.

Duplicate volume labels

Imported archive volumes cannot have a volume label which is already allocated to a volume in the importing DXUL-SM system. Before using the applyidf, utility, determine whether any volume, referred to in the IDF, has the same volume label as any of the volumes which exist in the importing system.

All volumes in an IDF are listed, by volume label, at the beginning of the IDF file. The IDF is an ASCII text file and can be viewed using standard viewing utilities. These labels must be compared with the volume labels allocated in the importing system.

The volume labels which are currently allocated in the importing system can be viewed using the readmap tool on that system. For information on using readmap, refer to the readmap man page.




Remove duplicatevolume labels

To remove duplicate volume labels:

1. Use forcepack to force the volumes on the importing system into an unused usage state.

The forcepack utility transfers all data from the specified volumes back into the disk cache (where it will be migrated to new volumes).

2. Use exporttape to remove the volumes from the importing system:

exporttape -s export-slot volume-label

where:

• export-slot is location where the robot should place the exported media

• volume-label represents the label that is duplicated in the IDF

Note: The -s export-slot option only applies to robot-controlled archive media.

3. Use settape to set the volume label as unavailable:

settape -u unavail volume-label

where volume-label represents the label that is duplicated in the IDF.

After all duplicate volume labels on the importing system have been marked as unavailable, applyidf may be executed.

Syntax The syntax for applyidf is:

applyidf [-r remove-path] [-a add-path] [-u uid] [-g gid] [-p perms] [-R] idf-name

The variable idf-name is the name of the IDF that is imported. The .idf extension need not be supplied as part of the filename argument.

Options The options for applyidf are described in Table 27 on page 266.


266



Table 27 The applyidf utility options

Option Description

-r remove-path The -r option takes the argument remove-path, where remove-path is the pathname segment to truncate from the pathnames of imported files. The pathname segment must begin with a forward slash. Only imported files which begin with remove-path are affected by this option. A file that includes a pathname segment, which matches remove-path, but which is not at the beginning of the file's pathname, is not affected.

-a add-path.

The -a option takes the argument add-path, where add-path is the pathname segment that is to be added to the beginning of the pathnames of all imported files. The pathname segment must begin with a forward slash. This option adds the pathname segment add-path to the beginning of the pathname of every imported file.

Note: The -r option is applied before this option.

-u uid The -u option takes the argument uid, where uid is the user ID to be assigned to all directories created by the -a option.

-g gid The -g option takes the argument gid, where gid is the group ID to be assigned to all directories created by the -a option.

-p perms The -p option takes the argument perms, where perms is the four digit number representing the permissions to be assigned to all directories created by the -a option. For information on using the first digit to set various modes and on using the octal values of the next three digits to assign permissions, refer to the chmod man page.

-R The -R option takes no argument. When this option is used, applyidf looks in the current working directory for a file with the extension .map and the same file name as the IDF. Any such file is parsed, and all remapping rules that it contains are applied to the imported files.




Example 29 Effect of -r Option When Using applyidf

The filepath segment passed to applyidf with the -r option is /home. The original pathname and the pathname that results from this option are shown in this table:

How to import an IDF To import an interchange datafile (IDF):

1. Copy all relevant IDFs and remap files from the exporting system to the importing system.

2. Determine if there are any label conflicts between the volumes referenced by the IDFs and volumes which already exist on the importing system.

3. Issue the applyidf command as a user with appropriate device and file permissions, with the DXUL-SM system running:

applyidf options dxmmddyy

where:

• options represents the appropriate applyidf options and arguments to successfully import the volumes.

• dxmmddyy represents the name of the IDF being imported (with the .idf extension removed).

4. Repeat the applyidf command for each IDF.

The following must be available to the importing system:

◆ Each archive volume that is imported using applyidf, when a user initiates a system call for data located on it.

◆ All archive media, referenced in a successfully imported IDF.

Example 30 Using applyidf with a remap file

To import an IDF named dx070102.idf, and use the remap file, dx070102.map, enter the applyidf command:

applyidf -R dx070102

Original pathname Resulting pathname

/home/bob/personal/big.file /bob/personal/big.file

/home/joe/home/big.file /joe/home/big.file

/local/home/sue/big.file /local/home/sue/big.file


268



Example 31 Using applyidf with the -r, -a, -u, -g, and -p options

The applyidf utility is to be used to perform the following tasks:

◆ Import an IDF named x02.idf.

◆ Truncate all files that begin with the filepath segment /home.

◆ Add the filepath segment /xset01 to all pathnames.

◆ Assign the user ID of 50 to the /xset01 directory.

◆ Assign the group ID 100 to the /xset01 directory.

◆ Assign the permissions values of 0777 to the /xset01 directory.

Enter the following applyidf command:

applyidf -r /home -a /xset01 -u 50 -g 100 -p 0777 x02




The remove utilityThe remove utility, delidf, is designed to remove, from an exporting system, all file and volume metadata referenced by an IDF.

The remove utility only removes the metadata for the copies of a file which are listed in the IDF. When an IDF contains all copies of a file, the file is completely removed from the exporting system. When the IDF does not reference all copies of a file, the copies of the file not in the IDF remain on the exporting system.

The remove utility should only be used after a successful volume export and import operation. Once delidf has been executed on an exporting system, the file metadata contained in the IDF is completely removed from that system. If the volumes referenced in the IDF have not been successfully imported and the IDF is lost or corrupted, the data is unrecoverable.

The remove utility performs a literal remove operation of each file referred to in the IDF. A literal remove operation moves a file to the appropriate trashcan. To fully delete the files exported in an IDF, turn off the trashcan feature before running the delidf command. This prevents a large volume of file data from being transferred to the system’s trashcans.

Syntax The syntax for delidf is:

delidf idf-name

where idf-name is the name of the IDF that contains the metadata to be removed. The .idf extension should not be supplied as part of the filename argument.

Remove IDF files,volumes and

metadata

To remove the files, volumes, and metadata referred to by an IDF:

1. Select an IDF which has been successfully imported into a new instance of DXUL-SM.

2. Log in to the exporting system as a user with appropriate device and file permissions.

3. Turn off the trashcan feature on the exporting system as follows:

a. Edit DiskXtender.conf on the exporting system, changing the parameter nameserver.run_trashcan from 1 to 0.

The remove utility 269

270



b. Force the Name Server to reread the DiskXtender.conf file by issuing the command:

kill -HUP nameserver-pid

where nameserver-pid is the process ID of the Name Server process.

4. With the DXUL-SM system running, issue the delidf command:

delidf idf-name

where idf-name is the name of the IDF that refers to the data and metadata to be deleted.

5. Turn the trashcan feature back on as follows:

a. Edit DiskXtender.conf on the exporting system, changing the parameter nameserver.run_trashcan from 0 to 1.

b. Force the name server to reread the DiskXtender.conf file by typing the command:

kill -HUP nameserver-pid

where nameserver-pid is the process ID of the name server process.



A


◆ Overview........................................................................................... 272◆ SCSI robotics and the SCSIINFO file............................................. 273◆ Adding a robotically-mounted SCSI tape drive .......................... 274◆ STK robot and STKINFO file.......................................................... 275◆ SGEN driver...................................................................................... 279◆ The Volume Manager ...................................................................... 280

Robotic Devices andthe Volume Manager

Robotic Devices and the Volume Manager 271

272

Robotic Devices and the Volume Manager


OverviewDXUL-SM supports several robotic devices: generic SCSI (SCSI) media libraries and the StorageTek (STK) Automated Cartridge System. DXUL-SM also provides support for the Volume Manager (LTS) and a general callout scheme using the LTS interface.

These devices are all controlled by the DXUL-SM PVR Server process. The PVR reads its configuration file, <DISKXTENDER>/etc/PVRINFO, to determine which of these are configured. The PVRINFO format is described in “<DISKXTENDER>/etc/PVRINFO” on page 117.




SCSI robotics and the SCSIINFO fileThe <DISKXTENDER>/etc/SCSIINFO file defines the specific device path to the SCSI robot and the bitmap for each of the drives. The PVR Server reads the PVRINFO file at startup to determine the devices under its control. If an SCSI media library is specified in PVRINFO, the PVR Server will also read its configuration file, SCSIINFO.

Format of SCSIINFO

where:

◆ SCSI is the robot system type. Must remain SCSI.dev is the robot control device name. This is typically an entry in the /dev directory.

◆ bitmap is the 64-bit (2 x 32-bits) hex bitmap of the drives. This bitmap must have a single bit set to define one SCSI drive corresponding to one entry in the <DISKXTENDER>/etc/tpdevs file. The corresponding bit must also be set in the SCSI bitmap entry of the PVRINFO file.

◆ flag is set to to 1 if the drive is up, or to 0 if the drive is down.

The bits starting from the left end of the bitmap (leftmost bit is defined to be bit 1) must correlate with the logical drive number as defined in <DISKXTENDER>/etc/tpdevs. For example, if a particular logical drive defined in tpdevs is 9, the bitmap entry for that drive is:

00800000 00000000

To change parameter values (if the drives have been added or removed), edit the SCSIINFO and PVRINFO files to reflect the change. Once these files have been edited, the PVR Server must be signaled to reread the files. Send a HUP signal to the PVR Server.

% kill -HUP pid[pvrsrvr]

SCSI dev bitmap_a flag_a bitmap_b flag_b ....... bitmap_n flag_n

SCSI robotics and the SCSIINFO fileOverview 273

274



Adding a robotically-mounted SCSI tape drive If the <DISKXTENDER>/etc/PVRINFO file specifies a SCSI media library, edit the <DISKXTENDER>/etc/SCSIINFO file to configure the system for each SCSI drive.

Example 32 SCSIINFO

A SCSIINFO file corresponding to the tpdevs and PVRINFO files would have entries for two SCSI cartridge drives with logical numbers 10 and 11.

An example of the file is shown below:

Removing a robotically-mounted SCSI tape drive Edit the <DISKXTENDER>/etc/SCSIINFO file and set the flag corresponding to the drive to be removed from DXUL-SM to 0. The values in the flag column are either 0 or 1, depending on whether the drive is available to DXUL-SM

Example 33 SCSIINFO

If drive 11 is to be removed in the robotic library, set the flag corresponding to that drive in SCSIINFO:

#name scsi device bitmap_a flag_a bitmap_b flag_b

SCSI /dev/scsi/c0t1d0s1

00400000 00000000

1 00200000 00000000

1

#name scsi device bitmap_a flag_a bitmap_b flag_b

SCSI /dev/scsi/c0t1d0s1

00400000 00000000

1 00200000 00000000

1




STK robot and STKINFO fileThe <DISKXTENDER>/etc/STKINFO file defines the specific tape drive addressing for the drives in the STK robot. The PVR Server reads the STKINFO file at startup to determine the devices under its control. If the STK is specified in <DISKXTENDER>/etc/PVRINFO, the PVR Server will also read its configuration file, STKINFO.

Format of STKINFO

where:

◆ acs is the Automated Cartridge System number (0-126).

◆ lsm is the logical Silo Module number (0-15).

◆ panel is the Panel number (0-19).

◆ drive is the Drive number (0-9).

◆ bitmap is the 32 hexadecimal digits (four 8-digit parts) representing 1 binary bit set corresponding to the logical drive number of each STK drive entered in <DISKXTENDER>/etc/tpdevs.

◆ flag is set to 1 if the drive is up, or to 0 if the drive is down.

The bits starting from the left end of the bitmap (leftmost bit is defined to be bit 1) must correlate with the logical drive number as defined in <DISKXTENDER>/etc/tpdevs. For example, if a particular logical drive defined in tpdevs is 4, the bitmap entry for that drive is:

10000000 00000000 00000000 00000000

To change parameter values (if the tape drives have been added or removed), edit the STKINFO and PVRINFO files to reflect the change. Once these files have been edited, the PVR Server must be signaled to reread the files. Send a HUP signal to the PVR Server.

% kill -HUP pid[pvrsrvr]

Refer to the STKINFO man page for more information.

acs lsm panel drive bitmap flag

STK robot and STKINFO fileOverview 275

276



Adding arobotically-mounted

STK tape drive

The <DISKXTENDER>/etc/PVRINFO file does not specify the STK robot by default. Edit the <DISKXTENDER>/etc/STKINFO file to properly configure the system for each STK tape drive.

Example 34 STKINFO for 64 bit

Copy file :

<DISKXTENDER>/etc/stkinfo.default to <DISKXTENDER>/etc/STKINFO.

Note: The actual values of acs, lsm, panel and drive should be obtained from the ACSLS server connected to the SM host.

These files would have entries for two STK cartridge tape drives with logical numbers 4 and 5. This example file is shown below:


Note: The actual values of acs, lsm, panel and drive should be obtained from the ACSLS server connected to the SM host.

Editing PVRINFO file The <DISKXTENDER>/etc/PVRINFO contains the configuration parameters for the PVR Server. The PVR Server reads this file at start-up to determine the type of devices under its control. For STK (storageTek) robotic device, an entry will be added as STK to the PVRINFO file.

#acs lsm panel drive bitmap flag

0 0 0 0 10000000 00000000 1

0 0 0 1 08000000 00000000 1


0 0 0 0 10000000 00000000 00000000 00000000

1

0 0 0 1 08000000 00000000 00000000 00000000

1




Example 36 PVRINFO file 64 bit

OPR 0000000 00000000

STK C0000000 00000000

Example 37 PVRINFO file 128 bit

OPR 0000000 00000000 0000000 00000000

STK C0000000 00000000 0000000 00000000

Configuring ssi.sh Once the STKINFO file has been properly configured, the <DISKXTENDER>/bin/ssi.sh must be configured for use with the STK robot. ssi.sh is a shell script that contains the <DISKXTENDER> pathname and the host name of the machine that controls the STK robot.

Copy the default ssi.sh file from <DISKXTENDER>/etc/ssi.sh.default to <DISKXTENDER>/bin/ssi.sh, provide execute permissions and change the two command lines shown below:

DISKXTENDER_ROOT_PATH=”<DISKXTENDER>”

CSI_HOSTNAME =<NAME_OF_SUN_CONTROLLING_STK_ROBOT>

Replace the two placeholder entries.

Replace <DISKXTENDER> with the DISKXTENDER_ROOT_PATH pathname and replace NAME_OF_SUN_CONTROLLING_STK_ROBOT with the host name of the Sun machine where ACSLS is running that controls the STK robot.

Configuring rc.diskxtenderWhile using an STK network, uncomment the following line from rc.diskxtender file and restart the services.

#taped_args="$taped_args -s"

Editing tpdevs During SM installation, by default tpdevs file will represent the drive numbers. Edit the <DISKXTENDER>/etc/tpdevs file based on the drive numbers.

To identify the drive numbers, observe the dxsm GUI display.

STK robot and STKINFO fileOverview 277

278



Run the mount command from the ACSLS server and observe the drive to which the tape is mounted and edit the tpdevs if required.

tapelabel To label the tapes, run the command from the ACSLS server.

Example 38 <ACSLS> query volume all

1. Mount the tape from ACSLS server.

2. Run the tapelabel command from DXUL-SM.

Note: Label tapes allotted only by the administrator for the SM host. In AIX, ensure the block size for the drives is zero.

settape Run the settape command from DXUL-SM.

Removing a robotically-mounted STK tape drive Edit the <DISKXTENDER>/etc/STKINFO file and either set the flag corresponding to the drive to be removed to 0 or delete that line completely. The values in the flag column are either 0 or 1, depending on whether the drive is available to DXUL-SM.


If logical tape drive 5 is to be removed in the robotic library, set the flag corresponding to that drive in STKINFO to 0 or delete that line:



0 0 0 0 10000000 00000000 1

0 0 0 1 08000000 00000000 0


0 0 0 0 10000000 00000000 00000000 00000000

1

0 0 0 1 08000000 00000000 00000000 00000000

0




SGEN driverDXUL-SM tape server uses the Solaris 10 standard SGEN driver to communicate with the tape library for data movement between disk and tape. This driver is used both by the pvrsrvr and tapesrvr for both control path and data path communications with the external connected tape library.

Upgrade from existing SST driver to SGEN driverSGEN driver should be installed and associated with the media changer before upgradation. During upgrade, upgrade Dx script displays a message asking if the user has already installed sgen driver and is associated to the media changer. Upgrade will continue only if the user clicks y to the message.

During upgrade from the existing installed DXUL -SM to DXUL- SM 2.11, pre-existing SST driver will be uninstalled.

For information on installing SGEN driver, the EMC DiskXtender for UNIX/Linux Storage Manager Release 2.11 Installation Guide. provides information.

SGEN driverOverview 279

280



The Volume Manager DXUL-SM includes support for the Volume Manager, a process that is accessed through the Physical Volume Repository (PVR), to manually mount and unmount tapes and to robotically mount and unmount tapes.

There are two important files that must be edited in order for a device to be controlled by the Volume Manager and two important directories that the Volume Manager uses. The files to be edited are <DISKXTENDER>/etc/PVRINFO and <DISKXTENDER>/etc/tpdevs.

“Adding tape drives” on page 194 provides more information the procedure. The two directories, critical to the operation of the Volume Manager, are <DISKXTENDER>/adm/logicaltape and <DISKXTENDER>/adm/requesttape. The Volume Manager does not use a configuration file.

An explanation of how the Volume Manager is used to mount and unmount tapes in DXUL-SM is provided next.

Mounting tapes When the DXUL-SM Tape Server requests a tape to be mounted by the Volume Manager, the request is sent to the PVR. The PVR forks the command lts_mntpgm which communicates with the Volume Manager.

The lts_mntpgm command causes a file to be created in the <DISKXTENDER>/adm/requesttape directory. When the tape is mounted successfully, a link is created in the <DISKXTENDER>/adm/logicaltape directory to the requested file in the requesttape directory. The Tape Server polls the files defined in the <DISKXTENDER>/etc/tpdevs file. When the link is placed in the logicaltape directory, the tape label is recognized and data is read or written.

Unmounting tapes When the Tape Server is ready to unmount a tape using the Volume Manager, it makes a request to the PVR to unmount the tape. The PVR forks the command lts_dismnt which cleans up the directories (deletes any links or files contained in <DISKXTENDER>/adm/logicaltape or <DISKXTENDER>/adm/requesttape) and commands the Volume Manager to unmount the tape.




requesttape and logicaltape directoriesWhen DXUL-SM is started, these directories should be empty. If links exist in the <DISKXTENDER>/adm/logicaltape directory, they should be removed with the rm command. The files in the <DISKXTENDER>/adm/requesttape directory must be removed with the tpunmount command, an internal Volume Manager command.

If files cannot be removed, this means that some DXUL-SM process is still running. Use the ps and kill commands to identify and terminate the process.

Files are created in the requesttape directory when the tape is requested by the lts_mntpgm command. Files are removed from this directory (with tpunmount) by the lts_dismnt command.

When a tape is successfully mounted, the lts_mntpgm command creates a link in the logicaltape directory to files in the requesttape directory. The links have the format:

tapen

Where n is a number from 1 through 64.

The pathname to the links is placed in the <DISKXTENDER>/etc/tpdevs file, which the Tape Server polls. When the link is created, the tape server begins accessing the tape.

The links in the logicaltape directory are removed by the lts_dismnt command.

Files must always be removed from the requesttape directory with the tpunmount command. Using the rm command will confuse the Volume Manager.

The lts_dismnt and lts_mntpgm commands use a lock file in the logicaltape directory to synchronize directory changes. This lock file is called LOCKED. The PID of the process holding the lock is written into this file. Certain situations may arise which cause this lock file not to be removed. If tapes are not being mounted, check to see if this file is present.

The Volume ManagerOverview 281

282





B

This chapter contains the following section:

◆ Understanding device bitmaps...................................................... 284◆ The Hex Value of a drive................................................................. 286

Device Bitmaps

Device Bitmaps 283

284

Device Bitmaps


Understanding device bitmapsA device bitmap consists of a 16-digit string. Each digit of the string must be a hexadecimal (hex) number between 0 and F inclusive. Each digit represents a drive group of four drives, resulting in a limit of 64 drives that can be represented by the bitmap (4 drives times 16 digits).

tpdevs unit numbers The tpdevs unit number (TUN) that is listed for each drive in the tpdevs file represents that drive when creating a bitmap. The TUN for a drive is the first integer on the line in tpdevs that lists the drive. This integer is a number from 1 to 64 inclusive. The TUN determines which digit of the hex string represents the drive group that a drive is in and which of the possible hex values for that digit represent the specific drive.

Significance of the device bitmap digits

The device bitmap hex string is read from left to right. Each digit of the bitmap represents a drive group of four drives, Table 28 on page 284 provides information. The left-most digit of the hex string represents the drive group with TUNs 1-4. The next digit to the right represents drive group with TUNs 4-8. Moving to the right, each digit represents the drive group with the next higher four TUNs. The right-most digit represents the drive group with TUNs 61-64.

Table 28 Bitmap Digit Position of Drive TUNs (page 1 of 2)

Drive TUNs Bitmap digit position Drive Group and Bitmap digit number

1-4 X0000000 00000000 1

5-8 0X000000 00000000 2

9-12 00X00000 00000000 3

13-16 000X0000 00000000 4

17-2 00000X000 00000000 5

21-24 00000X00 00000000 6

25-28 000000X0 00000000 7

29-32 0000000X 00000000 8

33-36 00000000 X0000000 9


Device Bitmaps


37-40 00000000 0X000000 10

41-44 00000000 00X00000 11

45-48 00000000 000X0000 12

49-52 00000000 0000X000 13

53-56 00000000 00000X00 14

57-60 00000000 000000X0 15

61-64 00000000 0000000X 16

Table 28 Bitmap Digit Position of Drive TUNs (page 2 of 2)

Drive TUNs Bitmap digit position Drive Group and Bitmap digit number

Understanding device bitmaps 285

286

Device Bitmaps


The Hex Value of a driveThe drive with the lowest TUN in each drive group is referred to by the highest hex value. This is derived from a binary representation of the drive group. A drive group of four drives is represented by four bits (binary digits). Each bit is either 1 (meaning the drive is on the device bitmap) or 0 (the drive is off the device bitmap). The four bits are read from the left, with the left most bit representing the drive in the drive group with the lowest TUN.

If the first drive in the drive group is on and all others are off, the binary representation is 1000. If the second drive in the drive group is on and all others are off the binary representation is 0100. If the third drive in the drive group is on and all others are off the binary representation is 0010. If the fourth drive in the drive group is on and all others are off the binary representation is 0001. If all four drives in the drive group are on the binary representation is 1111. If all four drives in the drive group are off the binary representation is 0000.

When one drive in the drive group is on, its binary representation is converted into its single digit hex equivalent. The single digit hex equivalents of the binary numbers representing that a drive in a drive group is on the bitmap are shown in Table 29 on page 286.

From Table 29 on page 286 we can determine that to represent that the drive with TUN 1 is on the bitmap we use the hex character 8. From Table 28 on page 284 , we can determine that the “8” representing the drive in the bitmap, must be in the left-most digit position of the bitmap string. The hex character 8 is placed in the first digit position of the bitmap:

80000000 00000000

Table 29 TUNs with Binary and Hex Equivalents

TUNs Binary Hex

1;5;9;13;17;21;25;29;33;37;41;45;49;53;57;61 1000 8

2;6;10;14;18;22;26;30;34;38;42;46;50;54;58;62 0100 4

3;7;11;15;19;23;27;31;35;39;43;47;51;55;59;63 0010 3

4;8;12;16;20;24;28;32;36;40;44;48;52;56;60;64 0001 1


Device Bitmaps


To represent that the drive with TUN 2 is on the bitmap, the hex character 4 is placed in the first digit position of the hex string:

40000000 00000000


20000000 00000000


10000000 00000000

The same method is used to determine the device bitmap for any one of the 64 possible drives. The only difference is that the hex number must be placed in the correct position in the device bitmap string for the drive’s group, Table 28 on page 284 provides information.

The Hex Value of a driveUnderstanding device bitmaps 287

288

Device Bitmaps


Representing morethan one drive in a

drive group

What happens when more than one drive in a drive group is on the bitmap? The binary representations of all drives in a drive group are on the bitmap are added together. The resulting binary number is converted to its hex equivalent and that character is placed into the bitmap string in the appropriate location for the drive group.

Using binary addition there are 16 possible combinations for each drive group. The binary representations of these 16 possible combinations convert to the 16 possible characters of a hex digit. Table 30 on page 288 describes the binary and hexadecimal values.

Example 41 Two drives in the same drive group are on the bitmap.

Create a device bitmap representing the drives with TUNs 1 and 3.

Table 30 Binary and Hexadecimal Equivalents

Binary Hex

0000 0

0001 0

0010 2

0011 3

0100 4

0101 5

0110 6

0111 7

1000 8

1001 9

1010 A

1011 B

1100 C

1101 D

1110 E

1111 F


Device Bitmaps


The drive with TUN 1 is represented by the binary number 1000, Table 30 on page 288 provides information. The drive with TUN 3 is represented by the binary number 0010.

Add the two binary numbers:

1000 + 0010 = 1010The resulting binary number, 1010, is equivalent to the hex number A, Table 30 on page 288 provides information. Place this hex number in the correct position in the bitmap string.

Since these drives are in the first drive group, the hex number is the first digit of the string, Table 28 on page 284 provides information. There are no other drive groups with drives represented by this bitmap so all other digits are 0.

The bitmap is:

A0000000 00000000

Example 42 All drives in the same drive group are on the bitmap.

Create a device bitmap representing all of the drives in the second drive group.

TUN 5 = 1000; TUN 6 = 0100; TUN 7 = 0010; TUN 8 = 0001

1000 + 0100 + 0010 + 0001 = 1111 = 0xF

Drives in the second drive group are represented by the second digit of the bitmap string. The bitmap is:

0F000000 00000000

Representing morethan one Drive group

When drives from more than one drive group are represented by the device bitmap the hex representation for each drive group is determined separately. Each resulting hex number is inserted into the device bitmap in the appropriate location for the drive group it represents.

Example 43 Example

Create a device bitmap representing the drives with TUNs 3, 7, 8 and 22.

Drive group 1: TUN 3 = 0010 = 0x2

The Hex Value of a driveUnderstanding device bitmaps 289

290

Device Bitmaps


Drive group 2: TUN 7 = 0010 = 0x2; TUN 8 = 0001 = 0x1

0010 + 0001 = 0011 = 0x3

Drive group 6: TUN 22 = 0100 = 0x4

The device bitmap is:

23000400 00000000


dell · emc diskxtender for unix/linux storage manager release 2.11 administration guide 3 preface...

Documents