Media-specific processes (MSPs) and library servers (LSs) migrate files from one media to another:
The file transfer protocol (FTP) MSP allows the DMF daemon to manage data by moving it to a remote machine.
The disk MSP migrates data to a directory that is accessible on the current systems and would be a cache disk if used in disk cache manager (DCM) mode.
The tape LS copies files from a disk to a tape or from a tape to a disk. The LS can manage multiple active copies of a migrated file. The LS contains of one or more volume groups. When a file is migrated from disk to tape, the selection policy can specify that it be copied to more than one volume group. Each volume group can manage at most one copy of a migrated file. Each volume group has an associated pool of tapes. Data from more than one volume group is never mixed on a tape.
This chapter discusses the following:
The LS consists of the following programs:
dmatls
dmatwc
dmatrc
The DMF daemon executes dmatls as a child process. In turn, dmatls executes dmatwc (the write child) to write data to tape and dmatrc (the read child) to read data from tape.
The dmatls program maintains the following types of records in its database:
The database is not a text file and cannot be updated by standard utility programs. Detailed information about the database and its associated utilities is provided in “CAT Database Records”, and “VOL Database Records”.
The LS provides a mechanism for copying active data from volumes that contain largely obsolete data to volumes that contain mostly active data. This process is referred to as volume merging or compression. Data on LS volumes becomes obsolete when users delete or modify their files. Volume merging can be configured to occur automatically (see “Configuring Maintenance Tasks for the LS” in Chapter 2). It can also be triggered by marking LS volumes as sparse with the dmvoladm(8) command.
The LS provides two utilities that read LS volumes directly:
Each instance of the LS needs three types of directories, one for each of the following:
Databases
Database journal files
Log files
Sites define the location of these directories by editing the base object configuration file parameters HOME_DIR, JOURNAL_DIR, and SPOOL_DIR, whose values are referred to as HOME_DIR, JOURNAL_DIR, and SPOOL_DIR in this document. A given instance of the LS creates a subdirectory named after itself in each of these three directories.
For example, if an instance of the LS is called cart1, its database files reside in directory HOME_DIR /cart1. If another instance of the LS is called cart2, its database files reside in HOME_DIR /cart2. If an instance of the LS is called cart3, its database files reside in HOME_DIR /cart3.
Similarly, LS cart1 stores its journal files in directory JOURNAL_DIR/cart1 and its log files and other working files in SPOOL_DIR /cart1.
The LS takes full advantage of the capabilities of modern tape devices, including data compression and fast media positioning. To accommodate these capabilities and to provide recovery from surface or other media defects, dmatls uses a number of structural concepts built on top of traditional tape structure.
The components are as follows:
The block is the basic structural component of most tape technologies. It is the physical unit of I/O to and from the media. The optimal block size varies with the device type. For example, the default block size for a 3480/3490 device is 65,536 bytes.
A chunk is as much or as little of a user file as fits on the remainder of the tape (see Figure 6-1). Thus, every migrated file has at least one, and sometimes many, chunks. Such a concept is necessary because the capacity of a volume is unknown until written, both because of natural variation in the medium itself and because the effect of data compression varies with the data contents.
A zone is a logical block containing several physical blocks ending with a tape mark. A zone has a target size that is configurable by media type. The default zone target size is 50 MB.
The volume group writes chunks into the zone until one of three conditions occurs:
The zone size is exceeded
The volume group exhausts chunks to write
The end of tape is encountered
Thus, the actual zone size can vary from well below the target size to the entire tape volume. A zone never spans physical volumes.
The zone plays several roles:
The zone size is the amount of data that triggers dmatls to start a process to write files to tape.
The LS records the position of the beginning of each zone in its database so that it can use fast hardware positioning functions to return there to restore the chunks in that zone.
When a tape volume develops a defect, the data loss usually will be restricted to the zone.
Because getting the tape position and writing a tape mark can be very costly, the concept of a zone and the target size provides a way to control the trade offs between write performance, safety, and recall speed.
Figure 6-1 illustrates the way files are distributed over chunks, zones, and volumes, depending upon the file size. The tape with volume serial number (VSN) VOL001 has two zones and contains six files and part of a seventh. The tapes with VSNs VOL002 and VOL003 contain the rest of file g. Notice that on VOL001 file g is associated with chunk 7, while on the other two tapes it is associated with chunk 1. File g has three VSNs associated with it, and each tape associates the file with a chunk and zone unique to that tape.
Records in the tape catalog (CAT), tpcrdm, store the location of each file chunk in terms of its volume, zone, and chunk number. The key for these records is the file's bit file identifier (BFID).
You do not explicitly create CAT records in the database. They are created when files migrate.
The CAT portion of the LS database consists of the following files:
The database definition file (in the same directory) that describes these files and their record structure is named named libsrv_db.dbd .
All files are non-ASCII and cannot be maintained by standard utility programs. The dmcatadm command provides facilities to create, query, and modify CAT database records (see “dmcatadm Command”).
 | Note:: The ability to create or modify CAT database records with dmcatadm is provided primarily for testing purposes. In the normal course of operations, you would never use this capability. |
Records in the tape volume (VOL) portion of the LS database, tpvrdm, contain information about each volume that exists in the pool of tapes to be used by dmatls. These records are indexed by the volume serial number (VSN) of each volume and contain information such as the following:
Volume's type
Estimated capacity
Label type
A number of flags indicating the state of the volume
Volume group or allocation group
Unlike the CAT records, you must create the VOL records in the database before using dmatls for the first time.
The VOL portion of the LS database consists of the following files:
The database definition file (in the same directory) that describes these files and their record structure is named named libsrv_db.dbd .
Both files contain binary data and require special maintenance utilities. The dmvoladm command, described in more detail in “dmvoladm Command”, provides facilities to create, query, and modify VOL records in the database. Additional database maintenance utilities are described in “Database Recovery” in Chapter 7.
| Note:: If you have more than one instance of a volume group, you must ensure that the volume sets for each are mutually exclusive. |
Each instance of dmatls protects its database by recording every transaction in a journal file. Journal file pathnames have the following format:
JOURNAL_DIR/ls_name/libsrv_db.yyyymmdd[.hhmmss] |
The LS creates journal files automatically.
Existing journal files are closed and new ones created in two circumstances:
When the first transaction after midnight occurs
When the journal file reaches the size defined by the JOURNAL_SIZE configuration parameter
When the first transaction after midnight occurs, the existing open journal file is closed and the suffix .235959 is appended to the current file name no matter what the time (or date) of closing. The closed file represents the last (or only) transaction log of the date yyyymmdd. A new journal file with the current date is then created.
When the journal file reaches JOURNAL_SIZE, the file is closed and the suffix .hhmmss is added to the name; hh, mm, and ss represent the hour, minute, and second of file closing. A new journal file with the same date but no time is then created.
For example, the following shows the contents of a JOURNAL_DIR/ls_name directory on 15 June 2004:
libsrv_db.20040527.235959 libsrv_db.20040606.235959 libsrv_db.20040528.235959 libsrv_db.20040607.235959 libsrv_db.20040529.235959 libsrv_db.20040608.235959 libsrv_db.20040530.235959 libsrv_db.20040609.235959 libsrv_db.20040531.235959 libsrv_db.20040610.235959 libsrv_db.20040601.235959 libsrv_db.20040611.235959 libsrv_db.20040602.235959 libsrv_db.20040612.235959 libsrv_db.20040603.235959 libsrv_db.20040613.235959 libsrv_db.20040604.235959 libsrv_db.20040614.235959 libsrv_db.20040605.235959 libsrv_db.20040615 |
For every date on which database transactions occurred, there will exist a file with that date and the suffix .235959, with the exception of an existing open journal file. Some dates may have additional files because the transaction log reached JOURNAL_SIZE at a specified time and the file was closed.
You can configure daemon_tasks parameters to remove old journal files (using the run_remove_journals.sh task and the JOURNAL_RETENTION parameter. For more information, see “Configuring Daemon Maintenance Tasks” in Chapter 2.
If an LS database becomes corrupt, recovery consists of applying the journal files to a backup copy of the database.
All DMF MSPs and LSs maintain log files named msplog.yyyymmdd in the MSP/LS spool directory which, by default, is SPOOL_DIR/mspname . SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP/LS in the daemon object of the configuration file; yyyymmdd is the current year, month, and day.
These log files are distinct from the logs maintained by the DMF daemon; however, some of the messages that occur in the daemon log are responses that the MSP/LS generates. The content of the log is controlled by the MESSAGE_LEVEL configuration parameter. For a description of the levels of logging available, see the dmf.conf(5) man page.
The msplog.yyyymmdd file is the primary log for the LS and contains most of the messages. This file is written by dmatls, dmatrc, and dmatwc. A new msplog.yyyymmdd is created for each day.
This section describes informational statistics provided by the tape log files. These messages appear in the SPOOL_DIR /msp_name/msplog. yymmdd files. Timing information provided (such as MB transferred per second) should not be used as an accurate benchmark of actual data transfer rates. This information is provided for monitoring DMF and should only be used in comparison to similar data provided by DMF. Text in all uppercase references a parameter defined in the DMF configuration file. You can reference the comments in the sample configuration file or in the dmf.conf(5) man page for a more detailed definition of these parameters.
| Note: Because the LS will continue to create log files and journal files without limit, you must remove obsolete files periodically by configuring the run_remove_logs.sh and run_remove_journals.sh tasks in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2. |
Example 6-1. LS Statistics Messages
The following is an example of LS statistics messages taken from an msplog.yyyymmdd file. These messages are automatically and periodically issued by the LS.
00:02:00-I 13902144-dmatls vg9a16.stats: children=1/0/0/7, btp=28098297/0/0, wc=0/7, cwc=0 00:02:00-I 13902144-dmatls vg9a17.stats: children=1/0/0/7, btp=59032803/0/0, wc=0/7, cwc=0 00:02:00-I 13902144-dmatls vg9a16.stats: data put=608.607 mb, data recalled=114.270 mb 00:02:00-I 13902144-dmatls vg9a17.stats: data put=1068.423 mb, data recalled=210.575 mb 00:02:01-I 13902144-dmatls vg9a16.stats: Put_File - 10 172 0 12 00:02:01-I 13902144-dmatls vg9a16.stats: Get_File - 0 1 0 0 00:02:01-I 13902144-dmatls vg9a16.stats: Delete_File - 0 130 0 0 00:02:01-I 13902144-dmatls vg9a16.stats: Cancel_Req - 0 12 0 0 00:02:01-I 13902144-dmatls vg9a16.stats: Flushall - 0 2 0 0 00:02:01-I 13902144-dmatls vg9a16.stats: Merge - 45 25 0 16 00:02:01-I 13902144-dmatls vg9a17.stats: Put_File - 14 210 0 8 00:02:01-I 13902144-dmatls vg9a17.stats: Get_File - 0 1 0 0 00:02:01-I 13902144-dmatls vg9a17.stats: Delete_File - 0 178 0 0 00:02:01-I 13902144-dmatls vg9a17.stats: Cancel_Req - 0 8 0 0 00:02:01-I 13902144-dmatls vg9a17.stats: Flushall - 0 2 0 0 00:02:01-I 13902144-dmatls vg9a17.stats: Merge - 18 28 0 22 00:02:01-I 13902144-dmatls vg9a16.stats: mc=7, ms=500000000, mu=133107712, sm=0 00:02:01-I 13902144-dmatls vg9a17.stats: mc=7, ms=500000000, mu=73105408, sm=0 |
The information provided by these entries is defined as follows:
children=1/0/0/7 represents the total child processes (1), the active child processes (0), the clean processes running (0), and the current maximum number of children the volume group may have (7). Clean children are used when a dmatrc or dmatwc process dies without cleaning up.
btp=28098297/0/0 represents the bytes queued for putting (28098297), the threshold at which to start the next put child (0), and the bytes assigned to socket I/O (0)
wc=0/7 represents the active write child processes (0) and the configured value of MAX_PUT_CHILDREN (7)
cwc=0 represents the process ID of the current write child (that is, the write child that is accepting data to write). 0 represents none.
The next set of lines give the total amount of data put (such as 608.607 MB) and recalled (such as 114.270 MB).
The next set of six lines provide statistics for each type of volume group request. Statistics information is provided only for requests that have been issued since the LS was started. These lines have the following format:
request_name active successful errors canceled |
active represents the number of requests not yet completed; successful represents the number of successfully completed requests; error represents the number of requests that completed with errors; canceled represents the number of canceled requests.
The last set of lines provide the following information:
mc is the configured value for MERGE_CUTOFF, the cutoff to stop scheduling tapes for merging (such as 7)
ms is the configured value for CACHE_SPACE, the merge cache space available (such as 500000000 bytes)
mu is the merge cache space used (such as 133107712 bytes)
sm is the number of socket merge children (0)
The LS write child (dmatwc) and read child ( dmatrc) also produce statistics messages in the LS log file. These messages contain timing statistics whose format changes from release to release, and they are not documented in this manual.
When users delete or modify their migrated files, the copy on tape becomes obsolete. Over time, some volumes will become entirely empty and can be reused. However, most volumes experience a gradual increase in the ratio of obsolete data to active data; such volumes are said to be sparsely populated or sparse. To reclaim the unused space on these volumes, DMF provides a volume merge facility, which copies the active data from several sparse volumes to a new volume, thus freeing the sparse volumes for reuse. Volume merging can be configured to occur automatically by using the run_merge_tapes.sh or run_merge_mgr.sh tasks (see “Configuring Maintenance Tasks for the LS” in Chapter 2).
Volume merging can also be done manually. dmatls performs merge operations whenever sparse volumes and the necessary resources exist at the same time. Use the dmvoladm select directive to mark volume group volumes as sparse. (The select directive is described in “dmvoladm Command”.) Because the merge processing occurs simultaneously with other DMF activities, it is easiest to configure DMF to automatically perform merges at night or during other periods of relatively low activity.
The dmatls utility can perform volume-to-volume merging. Volume-to-volume merging is accomplished by moving data across a socket connection between the LS tape read-child and the LS tape write-child. The benefit of using a socket to transfer data between volumes is that you do not have to reserve disk space. The drawback to using a socket for data transfer is the cost of linking the process that performs the read with the process that performs the write.
In busy environments that have heavy contention for tape drives, the close coupling between the socket's tape reader and tape writer can be costly, especially when short files are being transferred. For large files, the overhead and possible delays in waiting for both tapes to be mounted is small compared to the benefit of rapid transfer and zero impact on free disk space. For this reason, you can move small files through a disk cache and big files through a socket. This process is mediated by the following configuration parameters:
Using a small amount of disk space to hold small chunks can have a significant impact on the total time required to perform merges. The default configuration options are set to move 100% of merge data across sockets.
| Note: It is important to avoid volume merging on more than one volume
group simultaneously if they share a tape device. If you initiate a merge
process on more than one volume group on the same device at the same time
(either by entering the same time in the DMF configuration file or by
triggering the process manually), both processes will compete for tape
transports. When a limited number of tape transports are available, a
deadlock can occur. If you chose not to configure DMF to perform merges
automatically by configuring the run_merge_tape.sh
or run_merge_mgr.sh tasks, ensure that your
cron jobs that automatically initiate volume merging refrain
from initiating a second merge process until after all previously initiated
merges are complete. You can accomplish this by using the dmvoladm
command within the cron job to check for
tapes that have the hsparse flag, as shown in the following
example for an LS with two volume groups:
|
The dmcatadm(8) command provides maintenance services for CAT records in the LS database.
When you are inside the dmcatadm interface (that is, when you see the adm command_number > prompt), the command has a 30-minute timeout associated with it. If you do not enter a response within 30 minutes of the prompt having been displayed, the dmcatadm session terminates with a descriptive message. This behavior on all the database administrative commands limits the amount of time that an administrator can lock the daemon and LS databases from updates.
| Note:: Most of these facilities, especially the ability to create and modify CAT database records, are intended primarily for testing purposes. |
The dmcatadm command executes directives from stdin or from the command line when you use the -c option. All directives start with a directive name followed by one or more parameters. Parameters may be positional or keyword-value pairs, depending on the command. White space separates the directive name, keywords, and values.
The dmcatadm directives are as follows:
The first parameter of most directives specifies the database records to manipulate, and the remaining parameters are keyword-value pairs.
The syntax for the dmcatadm directives is summarized as follows:
count selection [limit] create bfid settings ... delete selection [limit] dump selection [limit] help list selection [limit] [format] load filename quit (or q or exit) set [format] update selection [limit] to settings... verify selection [entries] [vgnames] [limit] |
The parameters are as follows:
The selection parameter specifies the records to be acted upon. The value for selection can be one of the following:
A bfid or range of bfids in the form bfid [-] [ bfid]. bfid- specifies all records starting with bfid, and -bfid specifies all records up to bfid.
The keyword all
A period (.), which recalls the previous selection
An expression involving any of the above, field value comparisons, and, or, or parentheses.
A field value comparison may use the following to compare a field keyword to an appropriate value:
< (less than), > (greater than) = (equal to) != (not equal to) <= (less than or equal to) >= (greater than or equal to) The syntax for selection is as follows:
selection ::= or-expr or-expr ::= and-expr [ or or-expr ] and-expr ::= nested-expr [ and or-expr ] nested-expr ::= comparison | ( or-expr ) comparison ::= key-range | field-keyword op field-value op ::= < | > | = | != | <= | >= bfid-range ::= bfid [ - bfid] | [bfid - [bfid]] | key-macro key-macro ::= all field-keyword ::= name or abbreviation of the record field field-value ::= appropriate value for the field key ::= character representation of the record bfid
Thus valid selections could be any of the following:
305c74b200000010-305c74b200000029 7fffffff000f4411- -305c74b2000004c8 all chunkoffset>0 chunknumber>0 and writeage<5d . and writeage>4d vsn=S07638
The limit parameter restricts the records acted upon.
The bfid parameter for the create directive specifies the bit-file-identifier (BFID) for the record being created. The value for bfid may be a bit file identifier (BFID) designator in the form of a hexadecimal number.
The settings parameter for the create and update directives specify one or more fields and their values.
The format parameter selects the way in which output is displayed. Any program or script that parses the output from this command should explicitly specify a format; otherwise the default is used, which may change from release to release.
The entries parameter specifies a file of daemon database entries.
The vgnames parameter specifies the names of the volume groups associated with the records.
You can use the field keywords listed below as part of a selection parameter to select records, in a format parameter, or in a settings parameter to specify new values for a field; in that case, you must specify a keyword-value pair. A keyword-value pair consists of a keyword followed by white space and then a value. When specifying new values for fields, some of the keywords are valid only if you also specify the -u (unsafe) option. The abbreviation for each of the keywords is given in parenthesis following its name.
The date field keywords (readdate and writedate) have a value of either now or raw UNIX time (seconds since January 1, 1970). These keywords display their value as raw UNIX time. The value comparison > used with the date keywords means newer than the value given. For example, >36000 is newer than 10AM on January 1, 1970, and >852081200 is newer than 10AM on January 1, 1997.
The age field keywords (readage and writeage) let you express time as age in a string in a form. They display their value as an integer followed by the following:
| w (weeks) |
| d (days) |
| h ( hours) |
| m ( minutes) |
| s (seconds) |
For example, 8w12d7h16m20s means 8 weeks, 12 days, 7 hours, 16 minutes, and 20 seconds old.
The comparison > used with the age keywords means older than the value given (that is, >5d is older than 5 days).
The limit parameter in a directive limits the records acted upon. It consists of one of the following keywords followed by white space and then a value:
The following keywords specify files of daemon database entries:
The format parameter in a directive consists of the word format followed by white space and then either the word default, the word keyword, or a list of field keywords.
The keyword form, intended for parsing by a program or script, suppresses the headings.
If a list of field keywords is used in the format parameter, they may be delimited by colons or spaces, but spaces will require the use of quoting.
| Note: The BFID is always included as the first field and need not be specified. |
For any field that takes a byte count, you may append the letter k, m, or g (in either uppercase or lowercase) to the integer to indicate that the value is to be multiplied by one thousand, one million, or one billion, respectively.
For information about the role of the dmcatadm (8) command in database recovery, see “Database Recovery” in Chapter 7.
Example 6-2. dmcatadm list Directive
The following is sample output from the dmcatadm list directive. The file with key 3273d5420001e244 has two chunks because it spans two physical tape volumes; the first chunk contains bytes 0 through 24821759, and the second chunk bytes 24821760 (the CHUNK OFFSET) to the end of the file.
adm 3>list 3273d5420001e242- recordlimit 10
WRITE CHUNK CHUNK CHUNK
KEY AGE OFFSET LENGTH NUM VSN
-----------------------------------------------------------------------
3273d5420001e242 61d 0 77863935 13 S12940
3273d5420001e244 61d 0 24821760 168 S12936
3273d5420001e244 61d 24821760 23543808 1 S12945
3273d5420001e245 61d 0 51019776 2 S12945
3273d5420001e246 61d 0 45629440 59 S12938
3273d5420001e247 61d 0 35586048 60 S12938
3273d5420001e248 61d 0 9568256 3 S12944
3273d5420001e249 61d 0 14221312 4 S12944
3273d5420001e24a 61d 0 458752 5 S12944
3273d5420001e24b 61d 0 14155776 6 S12944 |
The following is sample output from the dmcatadm list directive for an LS. The file with key 3b4b28f2000000000000ae80 has 2 chunks because it was migrated to two different volume groups within this LS. The output from the dmvoladm list directive that follows shows that VSN 000700 is assigned to the volume group named vg8a15, and VSN 00727 is assigned to the volume group named vg8a05 .
# dmcatadm -m ls1
adm 1>list 3b4b28f2000000000000ae80- recordlimit 4
WRITE CHUNK CHUNK CHUNK
KEY AGE OFFSET LENGTH NUM VSN
--------------------------------------------------------------------
3b4b28f2000000000000ae80 1d 0 2305938 120 000700
3b4b28f2000000000000ae80 4d 0 2305938 32 000727
3b4b28f2000000000000ae82 1d 0 234277 247 003171
3b4b28f2000000000000ae82 1d 0 234277 186 003176
adm 2> quit
# dmvoladm -m ls1
adm 1>list vsn=000700
DATA EOT EOT WR/FR
VSN VOLGRP LB DATA LEFT WRITTEN CHUNK ZONE HFLAGS AGE
-------------------------------------------------------------------------------
000700 vg8a15 al 150.280473 233.786093 123 9 ------u-- 1d
adm 2>list vsn=000727
DATA EOT EOT WR/FR
VSN VOLGRP LB DATA LEFT WRITTEN CHUNK ZONE HFLAGS AGE
-------------------------------------------------------------------------------
000727 vg8a05 al 159.107337 200.443980 102 6 --------- 1d
|
The text field order for chunk records generated by the dmdump(8), dmdumpj(8), and the dump directive in dmcatadm is listed below. This is the format expected by the load directives in dmcatadm:
C (indicates the chunk record type)
bfid (hexadecimal digits)
filesize
writedata
readdate
readcount
chunkoffset
chunklength
chunkdata
chunknumber
flags (in octal)
zoneposition ( zonenumber/zoneblockid) (in hexadecimal)
vsn
chunkpos (in hexadecimal)
The dmvoladm(8) command provides maintenance services for VOL records in the LS database. In addition to the creation and modification of volume records, dmvoladm has an important role in the recovery of VOL records from a database checkpoint and is the mechanism that triggers volume merge activity.
When you are inside the dmvoladm interface (that is, when you see the adm command_number > prompt), the command has a 30-minute timeout associated with it. If you do not enter a response within 30 minutes of the prompt having been displayed, the dmvoladm session terminates with a descriptive message. This behavior on all the database administrative commands limits the amount of time that an administrator can lock the daemon and LS databases from updates.
The dmvoladm command executes directives from stdin or from the command line when you use the -c option. The syntax is the same as for dmcatadm: a directive name followed by parameters or paired keywords and values, all separated by white space.
The syntax for the dmvoladm directives is summarized as follows:
count [limit] create vsnlist volgrpspec [settings] delete selection [limit] dump selection [limit] help list selection [limit] [format] load filename quit (or q, or exit) repair selection select selection [limit] set format update selection [limit] to settings verify selection |
The volgrpspec parameter consists of the keyword volgrp (or vg), followed by a value for that keyword.
The value for vsnlist may be a single 6-character volume serial number (VSN) or a range of VSNs separated by the hyphen (-) character. A VSN string is case insensitive and may consist entirely of letters, entirely of digits, or a series of letters followed by digits. In a range of VSNs, the first must be lexically less than the second.
The value for selection may be one of the following:
A vsnlist or range of VSNs in the form vsn[-vsn ]. vsn- specifies all records starting with vsn, and -vsn specifies all records up to vsn.
A period (.), which recalls the previous selection
The name of one of the flags in the keyword list that follows in this section.
One of the words all, used , empty, or partial or any of the hflags, whose meanings are as follows:
Flag Description
all Specifies all volumes in the database
empty Specifies all volumes in which data written is 0
partial Specifies used volumes in which hfull is off
used Specifies all volumes in which data written is not 0
An expression involving vsnlists, field-value comparisons, and, or, or parentheses.
A field value comparison may use the following to compare a field keyword to an appropriate value:
< (less than) > (greater than) = (equal) != (not equal) <= (less than or equal to) >= (greater than or equal to)
The syntax for selection is as follows:
selection ::= or-expr or-expr ::= and-expr [ or or-expr ] and-expr ::= nested-expr [ and or-expr ] nested-expr ::= comparison | ( or-expr ) comparison ::= vsnlist | field-keyword op field-value op ::= < | > | = | != | >= | <= vsn-range ::= vsn [ - vsn] | [vsn - [vsn]] | key-macro key-macro ::= all | empty | used | partial | flag(s) field-keyword ::= name or abbreviation of the record field field-value ::= appropriate value for the field vsnlist ::= character representation of the volume serial number |
Thus valid selections could be any of the following:
tape01-tape02 tape50- -vsn900 all hoa or hro used and hfull=off datawritten>0 and hfull=off . and eotchunk>3000 and (eotchunk<3500 or hfree=on) hfull and threshold<30 |
You can use the field keywords listed below as part of a selection parameter to select records, in a format parameter, or in a settings parameter to specify new values for a field; in that case, a keyword-value pair must be specified. A keyword-value pair consists of a keyword followed by white space and then a value. When specifying new values for fields, some of the keywords are valid only if you also specify the -u (unsafe) option:
The date field keywords (update and wfdate) have a value of either now or raw UNIX time (seconds since January 1, 1970). These keywords display their value as raw UNIX time. The value comparison > used with the date keywords means newer than the value given. For example, >36000 is newer than 10AM on January 1, 1970, and >852081200 is newer than 10AM on January 1, 1997.
The age field keywords (upage and wfage ) let you express time as age as a string.
The age keywords display their value as an integer followed by the following:
| w (weeks) |
| d (days) |
| h ( hours) |
| m ( minutes) |
| s (seconds) |
For example, 8w12d7h16m20s means 8 weeks, 12 days, 7 hours, 16 minutes, and 20 seconds old.
The comparison > used with the age keywords means older than the value given (that is, >5d is older than 5 days).
The limit parameter in a directive limits the records acted upon. It consists of one of the following keywords followed by white space and then a value. The abbreviation for the keyword is given in parentheses following its name, if one exists:
The format parameter in a directive consists of the word format followed by white space and then either the word default, the word keyword , or a list of field and or flag keywords.
The keyword form, intended for parsing by a program or script, suppresses the headings.
If a list of field or flag keywords is used in the format expression, they may be delimited by colons or spaces, but spaces will require the use of quoting. The VSN is always included as the first field and need not be specified.
The flag keywords change the settings of hold flags:
For any field that takes a byte count, you may append the letter k, m, or g (in either uppercase or lowercase) to the integer to indicate that the value is to be multiplied by one thousand, one million, or one billion, respectively.
For information about the role of the dmvoladm command in database recovery, see “Database Recovery” in Chapter 7. For details about dmvoladm syntax, see the man page.
Example 6-3. dmvoladm list Directives
The following example illustrates the default format for the list directive when using an LS. The column marked HFLAGS uses a format similar to the ls -l command in that each letter has an assigned position and its presence indicates that the flag is “on”. The positions spell out the string eforvlus , representing herr, hfree, hoa, hro, hvfy, hlock, hfull, and hsparse.
adm 1> list 000683-000703
DATA EOT EOT WR/FR
VSN VOLGRP LB DATA LEFT WRITTEN CHUNK ZONE HFLAGS AGE
-------------------------------------------------------------------------------
000683 vg8a01 al 0.000000 0.000000 1 1 --------- 3d
000700 vg8a00 al 267.539255 287.610294 124 7 ------u-- 2d
000701 vg8a00 al 288.342795 308.147798 136 8 ------u-- 2d
000702 vg8a00 al 255.718902 288.302830 120 7 ------u-- 2d
000703 ag8 al 0.000000 0.000000 1 1 --------- 3d
|
The following example illustrates using the list command to show only volumes meeting some criterion (in this case, those having their hfull flag set):
adm 1>list hfull
DATA EOT EOT WR/FR
VSN VOLGRP LB DATA LEFT WRITTEN CHUNK ZONE HFLAGS AGE
-------------------------------------------------------------------------------
000701 vg8a00 al 288.342795 308.147798 136 8 ------u-- 2d
000702 vg8a00 al 255.718902 288.302830 120 7 ------u-- 2d
000704 vg8a00 al 252.294122 292.271410 119 7 ------u-- 2d
000705 vg8a00 al 250.207666 304.603059 143 7 ------u-- 2d
000706 vg8a00 al 265.213875 289.200534 144 7 ------u-- 2d
000707 vg8a00 al 278.744448 310.408119 140 7 ------u-- 2d
000708 vg8a00 al 260.827748 295.956588 136 7 ------u-- 2d
000709 vg8a00 al 253.481897 283.615678 138 8 ------u-- 2d
000710 vg8a00 al 265.100985 291.243235 141 7 ------u-- 2d
000711 vg8a00 al 276.288446 305.782035 144 7 ------u-- 2d
000712 vg8a00 al 250.415786 275.606243 138 7 ------u-- 2d
000716 vg8a00 al 287.964765 304.321543 144 7 ------u-- 2d
000717 vg8a00 al 280.795058 287.084534 144 7 ------u-- 2d
000718 vg8a00 al 0.000415 300.852018 180 27 ------u-- 3d
003127 vg9a01 al 417.383784 461.535047 209 10 ------u-- 2d
003128 vg9a01 al 427.773679 460.716741 229 11 ------u-- 2d
|
The following example shows one way you can customize the list format to show only the fields that you want to see. The other way is to use the set format command with the same keyword list.
adm 21>list S03232-S03254 format "eotchunk eotzone eotpos"
EOT EOT
VSN CHUNK ZONE EOTPOS
-------------------------------
S03232 10 2 2/4294967295
S03233 2 2 2/4294967295
S03234 598 2 2/4294967295
S03235 18 2 2/4294967295
S03236 38 2 2/4294967295
S03237 92 2 2/4294967295
S03238 1 1 1/4294967295
S03239 1 1 1/4294967295
S03240 1 1 1/4294967295
S03241 325 2 2/4294967295
S03242 81 2 2/4294967295
S03243 26 2 2/4294967295
S03244 1 1 1/4294967295
S03245 26 2 2/4294967295
S03246 5 2 2/4294967295
S03247 186 2 2/4294967295
S03248 17 2 2/4294967295
S03249 526 2 2/4294967295
S03250 1 1 1/4294967295
S03251 533 2 2/4294967295
S03252 157 17 17/2147483648
S03253 636 2 2/4294967295
S03254 38 2 2/4294967295 |
The following example gives a convenient way to show the several flag bits in a way different from their usual representation.
adm 23>list 003232-003254 format "hfree hfull hlock hoa hro"
hfree hfull hlock hoa hro
VSN
--------------------------------
003232 off on off off off
003233 off off off off off
003234 off off off off off
003235 off off off off off
003236 off on off off off
003237 off on off off off
003238 off on off off off
003239 off on off off off
003240 off off off off off
003241 off on off off off
003242 off on off off off
003243 off off off off off
003244 off off off off off
003245 off on off off off
003246 off off off off off
003247 off on off off off
003248 off on off off on
003249 on off off off on
003250 on off off off on
003251 on off off off on
003252 on off off off on
003253 off on off off on
003254 off on off off on |
The following example shows how to display only those tapes assigned to the volume group named vg9a00.
adm 3>list vg=vg9a00
DATA EOT EOT WR/FR
VSN VOLGRP LB DATA LEFT WRITTEN CHUNK ZONE HFLAGS AGE
-------------------------------------------------------------------------------
003210 vg9a00 al 1.048576 1.048576 3 2 --------- 11d
003282 vg9a00 al 11.534336 11.534336 13 2 --------- 7d |
The text field order for volume records generated by the dmdump(8), dmdumpj(8), and the dump directive in dmvoladm is listed below. This is the format expected by the load directives in dmvoladm:
V (indicates the volume record type)
vsn
volgrp
lbtype
capacity
blocksize
hflags (in octal)
version
datawritten
eotchunk
eotposition (eotzone /eotblockid) (in hexadecimal)
dataleft
chunksleft
wfdate
update
id (in octal). This field indicates the type of process that last updated the record.
Use the dmatread(8) command to copy all or part of the data from a migrated file back to disk. You might want to do this if, for example, a user accidentally deleted a file and did not discover that the deletion had occurred until after the database entries had been removed by the hard delete procedure. Using backup copies of the databases from before the hard delete was performed, dmatread can restore the data to disk, assuming that the tape volume has not been reused in the meantime.
Example 6-4. Restoring Hard-deleted Files Using dmatread
To copy migrated files back to disk, perform the following steps:
Determine the BFID of the file you want to restore. You can use backup copies of dmdlog or your dbrec.dat files, or a restored dump copy of the deleted file's inode (and the dmattr command).
Using backup copies of LS databases, use a dmatread(8) command similar to the following:
dmatread -p /a/dmbackup -B 342984C50000000000084155
342984C50000000000084155 is the BFID of the file to be restored, and /a/dmbackup is the directory containing the backup copies of the LS databases. Your file will be restored to the current directory as B342984C50000000000084155
DMF does not know the original name of the file; you must manually move the restored data to the appropriate file.
If you have access to chunk and VSN information for the file to be restored, you can use the dmatread -c and -v options and avoid using backup copies of the LS database. In this case, dmatread will issue messages indicating that the chunk is not found in the current database, but it will continue with the request and restore the file as described in this example.
Use the dmatsnf(8) command to verify the readability of or to audit the contents of LS volumes. You may also generate text database records that can be applied to the LS databases (using the load directive in dmcatadm and dmvoladm, respectively), in order to add the contents of a volume to the LS database (although this is impractical for large numbers of volumes).
dmatsnf can be used to verify one or more tape volumes against the LS databases. It also can be used to generate journal entries, which can be added to the LS databases by using the load directive in dmvoladm and dmcatadm.
Use the verifymsp option of the dmaudit(8) command to check the consistency of the DMF daemon and LS databases after an MSP, LS, DMF, or system failure. This command captures the database files and compares the contents of the daemon database with each LS database. Any problems are reported to standard output, but no attempt is made to repair them.
This function can also be done directly using dmatvfy(8) after a snapshot has been taken.
The FTP MSP allows the DMF daemon to manage data by moving it to a remote machine. Data is moved to and from the remote machine with the protocol described in RFC 959 (FTP). The remote machine must understand this specific protocol.
| Note:: It is desirable that the remote machine run an operating system based on UNIX, so that the MSP can create subdirectories to organize the offline data. However, this is not a requirement. |
The FTP MSP does not need a private database to operate; all information necessary to retrieve offline files is kept in the daemon database, DMF configuration file, and login information file. The login information file contains configuration information, such as passwords, that must be kept private. As a safeguard, the MSP will not operate if the login information file is readable by anyone other than the system administrator.
The FTP MSP is always waiting for requests to arrive from the DMF daemon, but, to improve efficiency, it holds PUT and DELETE requests briefly and groups similar requests together into a single FTP session. No PUT request will be held longer than 60 seconds. No DELETE request will be held longer than 5 seconds. GET requests are not held. The MSP will stop holding requests if it has a large amount of work to do (more than 1024 individual files or 8 MB of data). The FTP MSP also limits the number of FTP sessions that can be active at once and the rate at which new sessions can be initiated.
After a request has been held for the appropriate amount of time, it enters a ready state. Processing usually begins immediately, but may be delayed if resources are not available.
The following limits affect the maximum number of requests that can be processed:
An administrator-controlled limit on the maximum number of concurrent FTP sessions per MSP (CHILD_MAXIMUM).
An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing delete requests (GUARANTEED_DELETES).
An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing dmget(1) requests (GUARANTEED_GETS).
A system-imposed limit of 85 FTP sessions in any 60-second period. This limit is seldom a concern because of the MSP's ability to transfer many files in one session. Because requests are grouped into batches only when resources are immediately available, GET requests (which are not normally held) are batched when resources are in short supply.
Requests are processed by forking off a child process. The parent process immediately resumes waiting for requests to arrive from the DMF daemon. The child process attempts to initiate an FTP session on the remote FTP server. If the remote machine has multiple Internet Protocol (IP) addresses, all of them are tried before giving up. If the child process cannot connect, it waits 5 minutes and tries again until it succeeds.
Once a connection is established, the child process provides any required user name, password, account, and default directory information to the remote FTP server. PUT, GET, or DELETE operations are then performed as requested by the DMF daemon. PUT, GET, or DELETE operations are not intermixed within a batch. If an individual request does not complete successfully, it does not necessarily cause other requests in the same batch to fail. Binary transfer mode is used for all data transfer.
The stored files are not verbatim copies of the user files. They are stored using the same format used to write tapes, and you can use MSP utilities such as dmatread and dmatsnf to access the data in them.
All DMF MSPs maintain log files named msplog.yyyymmdd in the MSP spool directory which, by default, is SPOOL_DIR/ mspname. SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP in the daemon object of the configuration file; yyyymmdd is the current year, month, and day.
The activity log shows the arrival of new requests, the successful completion of requests, failed requests, creation and deletion of child processes, and all FTP transactions. Sensitive information (passwords and account information) does not appear in the activity log. In addition, the MSP lists the contents of its internal queues in its activity log if it is given an INTERRUPT signal.
| Note: Because the FTP MSP will continue to create log files files without limit, you must remove obsolete files periodically by configuring the run_remove_logs task in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2. |
The MSP also recognizes and handles the following messages issued from the DMF daemon:
 | Caution: If the remote filesystem must be restored to a previous state, inconsistencies may arise: remote files that reappear after being deleted are never removed, and remote files that disappear unexpectedly result in data loss. There is presently no way to detect these inconsistencies. You should avoid situations that require the remote filesystem to be restored to a previous state. |
The disk MSP (dmdskmsp) migrates data into a directory that is accessed on the current system. It uses POSIX file interfaces to open, read, write, and close files. The directory may be NFS-mounted, unless the disk MSP is configured as a disk cache manager (see “Disk MSP and Disk Cache Manager (DCM)”). The data is read and written with root (UID 0) privileges. By default, dmdskmsp stores the data in DMF-blocked format, which allows the MSP to do the following:
Keep metadata with a file
Keep sparse files sparse when they are recalled
Verify that a file is intact on recall
The disk MSP does not need a private database to operate; all information necessary to retrieve offline files is kept in the daemon database and DMF configuration file.
The disk MSP may also be used as an import MSP. In this case, it only permits recalls and copies the data unchanged for a recall.
The disk MSP is always waiting for requests to arrive from the DMF daemon, but, to improve efficiency, it holds PUT and DELETE requests briefly and groups similar requests together into a single session. No PUT request will be held longer than 60 seconds. No DELETE request will be held longer than 5 seconds. GET requests are not held. The MSP will stop holding requests if it has a large amount of work to do (more than 1024 individual files or 8 MB of data).
After a request has been held for the appropriate amount of time, it enters a ready state. Processing usually begins immediately, but may be delayed if resources are not available.
The following limits affect the maximum number of requests that can be processed:
An administrator-controlled limit on the maximum number of concurrent operations per MSP (CHILD_MAXIMUM).
An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing delete requests (GUARANTEED_DELETES).
An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing dmget(1) requests (GUARANTEED_GETS).
Requests are processed by forking off a child process. The parent process immediately resumes waiting for requests to arrive from the DMF daemon.
PUT, GET, or DELETE operations are performed as requested by the DMF daemon. PUT, GET, or DELETE operations are not intermixed within a batch. If an individual request does not complete successfully, it does not necessarily cause other requests in the same batch to fail. Binary transfer mode is used for all data transfer.
The stored files are not verbatim copies of the user files. They are stored using the same format used to write tapes, and you can use MSP utilities such as dmatread and dmatsnf to access the data in them.
All DMF MSPs maintain log files named msplog.yyyymmdd in the MSP spool directory which, by default, is SPOOL_DIR/mspname . SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP in the daemon object of the configuration file; yyyymmdd is the current year, month, and day).
The log file shows the arrival of new requests, the successful completion of requests, failed requests, and creation and deletion of child processes. In addition, the MSP lists the contents of its internal queues in its activity log if it is given an INTERRUPT signal.
| Note: Because the disk MSP will continue to create log files without limit, you must remove obsolete files periodically by configuring the run_remove_logs task in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2. |
The disk cache manager (DCM) lets you configure the disk MSP to manage data on secondary disk storage, allowing you to further migrate the data to tape as needed. The DCM provides an automated method of using secondary (slower and less-expensive) disk as a fast-access DMF cache for files whose activity levels remain high, while also providing migration to tape for those files requiring less frequent access.
To allow the disk store that is managed by the disk MSP to function as a dynamically managed cache (as opposed to a static store), DCM creates and maintains a filesystem attribute on each file that is created in the MSP STORE_DIRECTORY. This attribute is used by the dmdskfree process to evaluate files for downward migration and for possible removal from the disk cache. For this reason, the DCM STORE_DIRECTORY must be a local XFS or CXFS filesystem mount point with DMAPI enabled.
The DCM supports dual-resident state, in which files reside in the cache and also in a lower volume group. This provides the access speed of a disk file, but allows that cache file to be quickly released without the need to first write it to tape. This is directly analogous to the concept of a dual-state file in the standard DMF-managed filesystem.
Automated movement in the opposite direction (from tape back to the cache) is not available. Any recalls of files that no longer have copies held in the cache will come directly from tape; they are not recalled via the cache and they can only be restored to the cache by an explicit dmmove(8) command.
The dmdskvfy command verifies that copies of migrated files in disk MSPs are consistent with the dmfdaemon database entries that refer to them. This command applies both to regular disk MSPs and to those running in DCM mode.
DMF provides a mechanism to move copies of offline or dual-state files from one MSP or volume group to another. The dmmove(8) command takes a list of such files and moves them to a specified set of MSPs or volume groups. The list of MSPs or volume groups specified to the dmmove command indicates which MSPs or volume groups are to contain migrated copies of a file after the move process is completed. All other migrated copies are hard-deleted unless the dmmove -d option is used to select which copies are to be hard-deleted.
If a file's migrated state is offline, dmmove recalls the file to disk and then remigrates it to the specified MSPs or volume groups. (The one exception to this is that if a disk cache manager disk MSP copy exists, the file will be moved directly from that file copy.) When the migration process is complete, the online copy is removed. The file is recalled to a scratch filesystem that is specified by the MOVE_FS configuration parameter. If the file is dual-state, dmmove does not need to recall the file first, but instead uses the existing online copy.
The dmselect(8) command can be used to determine which files you want to move. dmselect selects files based on age, size, ownership, and MSP criteria. The output from the dmselect command can be used with the dmmove command. The dmmove command also accepts a list of pathnames as input.
See the man pages for dmselect and dmmove for all the possible options and further information.
| Note: If you have a tape MSP, you must first convert it to a volume group in an LS while still on IRIX, using dmmsptols, and then convert to Linux as a second and independent step. (The tape MSP is not available in the Linux DMF release.) For more information, see the 3.0 version of the DMF Administrator's Guide for SGI InfiniteStorage (007-3681-008). |
You can convert IRIX DMF to Linux DMF and also convert Linux DMF to IRIX DMF. This section describes the necessary steps to convert an IRIX DMF to a Linux DMF.
DMF databases on IRIX machines cannot be copied to Linux machines because of binary incompatibility. Instead, they must be dumped to text on the IRIX machine, and the resulting text file must be loaded into the database on the Linux machine. DMF-managed filesystems, that is, filesystems containing user files that DMF has migrated, can be moved from an IRIX machine to a Linux machine.
It is assumed that sites converting DMF from an IRIX to a Linux machine (or vice versa) will obtain the help of SGI customer support; the following documentation is offered to familiarize you with the necessary steps. This procedure assumes the filesystems will be moved, and that this is done before the last step. It does not describe the steps required to move a filesystem.
Procedure 6-1. IRIX to Linux Conversion
Use dmaudit to verify that the DMF databases are valid. For more information, see the dmaudit (8) man page and the DMF Administrator's Guide for SGI InfiniteStorage and DMF Filesystem Audit Guide for SGI InfiniteStorage. To verify the databases that will actually be moved, you should change the filesystem migration levels in the dmf.conf file to none, run dmdidle, and then ascertain that all DMF activity has stopped before beginning this step. You should also use dmsnap to back up your databases.
Stop DMF on the IRIX system. If DMF is started again on the IRIX system during or after this procedure, the databases captured during step 3 might not reflect reality, and loss of data might result if you use them. To verify the consistency of the DMF databases, use the dmdbcheck(8) command.
Dump all of the DMF databases to text on the IRIX system. This should include the daemon database and the CAT and VOL databases for all LSs. For more information, see the dmdump (8) man page.
Set up the /etc/dmf/dmf.conf file on the Linux system. The conversion will be simpler if you name all of the FTP MSPs, disk MSPs, tape volume groups, and LSs with the same names used on IRIX. This assumes that you do not already have MSPs, LSs, or volume groups with these names on your Linux system.
If you do change the name of an MSP or volume group, you must convert the daemon database. For more information on how to perform this conversion, see the documentation in the dmconvertdaemon script.
Use dmcheck to ensure that your new /etc/dmf/dmf.conf file is valid on the Linux system.
Copy the text versions of the databases that you created in step 3 to the Linux machine.
(Optional) Sort the daemon and CAT text database records after they have been dumped to text for better overall performance of the text-record load process. (The time to sort and load will be less than the time to load unsorted text records when the number of records is in the millions.)
To sort the daemon text record file, use a command similar to the following, where tmpdir is a directory in a filesystem with sufficient free space for sort(1) to complete the sort:
# /bin/sort -t"|" -y -T tmpdir -k 1,1 -o daemontext daemontext
To sort the CAT text record file, use a command similar to the following, where tmpdir is a directory in a filesystem with sufficient free space for sort(1) to complete the sort:
# /bin/sort -t"|" -y -T tmpdir -k 2,2 -o cattext cattext
For more information, see the sort(1) man page.
Load the database files from the text files on the Linux machine. Use dmdadm to load the daemon database file. Use dmcatadm to load the CAT database for each of the LSs. Use dmvoladm to load the VOL database for each of the LSs.
Use dmdbcheck to check the consistency of databases on the Linux machine.
Make sure all DMF filesystems are resident on the Linux machine.
Start DMF on the Linux machine and run dmaudit.
Example 6-5. IRIX to Linux Conversion (Single LS)
In the following example, the IRIX machine has a single LS named ls1. The example assumes that the /tmp/dmfdatabases directory has been created, is initially empty, and contains enough space to accommodate the text versions of the databases. The example also assumes that the HOME_DIR configuration parameter is set to /dmf/home on both systems. After completing steps 1 and 2 of Procedure 6-1, the daemon database and the LS databases are dumped to text, as follows:
$ dmdump -c /dmf/home/daemon > /tmp/dmfdatabases/daemon_txt $ dmdump /dmf/home/ls1/tpcrdm.dat > /tmp/dmfdatabases/ls1_cat_txt $ dmdump /dmf/home/ls1/tpvrdm.dat > /tmp/dmfdatabases/ls1_vol_txt |
Next, the files in /tmp/dmfdatabases on the IRIX system are copied to /tmp/dmftxtdb on the Linux system. After creating the DMF configuration file on the Linux system, the databases are loaded on the Linux system, as follows:
$ dmdadm -u -c "load /tmp/dmftxtdb/daemon_txt" $ dmcatadm -m ls1 -u -c "load /tmp/dmftxtdb/ls1_cat_txt" $ dmvoldadm -m ls1 -u -c "load /tmp/dmftxtdb/ls1_vol_txt" |
Now dmdbcheck is run to verify the consistency of the databases, as follows:
$ cd /dmf/home/daemon; dmdbcheck -a dmd_db $ cd /dmf/home/ls1; dmdbcheck -a libsrv_db |
The drive group component of the LS monitors tape use, analyzes failures, and usinges this information to avoid future errors.
The drive group component can react to some failures without looking for any patterns of behavior. Among these are the following:
Mounting service failure. If the mounting service is TMF, by default, DMF makes one attempt to restart it. If this attempt does not succeed, DMF notifies the administrator by e-mail and waits for the administrator's intervention. When TMF is back again, DMF resets the auto-restart flag so that if TMF fails again, it will once again make one attempt to restart it.
If OpenVault is the mounting service, by default, no attempt is made to restart it. Instead, an e-mail is sent to the administrator.
A site can set the number of automatic restart attempts by using the drive group's MAX_MS_RESTARTS configuration parameter, but caution and thorough testing are advised. There are many possible failure modes for a mounting service, and automated restarts might not always be appropriate.
Tape volume is not in the tape library. Obviously, this problem will not be fixed by trying again. To prevent further access, the volume is locked by setting the HLOCK flag, as described below, and the user requests that triggered the access attempt are retried on another tape, if possible; otherwise, they are aborted. The administrator is notified by e-mail.
For TMF only, a tape mount was cancelled by an operator or administrator. Although the user requests are retried or aborted, the volume is not disabled. If the volume were disabled, it would be inaccessible for a period of time (default 24 hours) unless dmvoladm were used to preempt this delay. All operators do not necessarily have access to the dmvoladm command.
Because the reason for the cancellation is unknown to DMF, repeated requests for the same volume are quite possible, and the operator might have to cancel each one.
The drive group handles other types of failure by examining the recent history of the tape volume and the tape drive that was used. The drive group maintains records of past tape I/O errors, and uses these to control the way it reacts to future errors.
For example, if a tape has been unusable several times in a row, even though different tape drives were used, the drive group concludes that the problem most likely involves the tape volume rather than the drive. Therefore, it suspends use of that tape for a while, forcing DMF to migrate to a different tape in that volume group, or to recall the file from another tape held by a different volume group. This suspension is usually done by setting the HLOCK flag in the tape's entry in the volume database. This makes the tape inaccessible to the volume group for both reading and writing until it is automatically cleared after REINSTATE_VOLUME_DELAY minutes.
If a variety of volumes fail on a specific drive but are usable on other drives, a drive problem is likely, and the tape drive can be automatically configured down if permitted by the administrator's setting of DRIVES_TO_DOWN to a value higher than its default of zero. When a drive is configured down in this way, it is configured up again after REINSTATE_DRIVE_DELAY minutes.
The analyses of drive and volume errors are performed independently of each other; it is possible for one additional error to result in both the drive and the volume being disabled.
There are several reasons for reinstating drives and volumes after a delay. The most important is that the analyses of previous failures might lead to a faulty conclusion in some situations, such as when DMF is under a very light load, or when multiple failures occur concurrently. A wrong diagnosis might impact DMF's performance, and should not be accepted indefinitely. Disabling a suspected drive or volume for a while is usually enough to break any repetitive cycles of failure. If such patterns re-establish themselves when the reinstatement occurs, the drive group will again analyze the behavior, possibly reaching a different conclusion, and again try to prevent it.
There are some variations from these general reactions. For example, if a tape volume with existing data on it is diagnosed as faulty when appending new data, instead of setting the HLOCK flag, the drive group sets HVFY, which results in the tape being used in a read-only mode until eventually emptied by merges or hard deletion of its files. At that time, the administrator may choose to test it and possibly replace or delete it. If it is to be returned to service, the HVFY flag should be cleared by using dmvoladm. Full details of these procedures are included in the email sent to the administrator at the time of the error.
If it is considered desirable to return a volume or drive to service earlier than defined in the DMF configuration, the appropriate command (dmvoladm, tmconfig, or ov_drive) can be safely used.
When multiple volume groups are requesting the use of more tape drives than exist in the drive group, the resource scheduler is used to decide which volume groups should wait and which should be assigned the use of the drives.
The resource scheduler is unaware of non-volume-group activity on the drives in its drive group. Such activity includes XFS dumps any direct tape use by the system's users; it does not prevent the LS from working properly, though it might be less than optimal.
By default, the resource scheduler uses a round-robin based algorithm, but a site can assign different weightings to different volume groups to meet local requirements. (For more information, see “Resource Scheduler Objects” in Chapter 2).
Some sites will have requirements that cannot be met by a general purpose algorithm. Such sites can write their own resource scheduler algorithms in C++, to be used in place of the supplied one. Instructions can be found in the /usr/share/doc/dmf-version_number/info/sample/RSA.readme file.
You can observe the performance of the LS in two ways:
Monitor its log file with a tool like tail -f , which allows an experienced administrator to follow the flow of events as they happen
Use the resource watcher component, when enabled by use of the WATCHER parameter in the libraryserver configuration stanza
The resource watcher is intended to give the administrator a view of the status of an LS and some of its components. It maintains a set of text files on disk that are rewritten as events happen. These files can be found in the SPOOL_DIR/lsname/_rwname directory, where SPOOL_DIR is defined in the DMF configuration file, as are the names of the LS and resource watcher; for example, lsname and rwname. The easiest way to find the precise path is to look in the LS log file for messages like the following:
rwname.config_changed: URL of home page is file:/dmf/spool/lsname/_rwname/lsname.html |
This message is issued at DMF startup or whenever the configuration file is altered or its modification time changes; for example, by using the touch(1) command.
The SPOOL_DIR/lsname/_rwname directory contains files with names ending in .html, which are automatically refreshing HTML files. You can access these files by using a browser running on the same machine. The following example shows an LS page that contains links to drive group pages, and they in turn have links to volume group pages, if the volume groups are active at the time:
netscape file:/dmf/spool/lsname/_rwname/lsname.html |
If running the browser on the DMF machine is inconvenient, you can include the directory in your HTTP server configuration to allow those same pages to be accessed via the web.
This directory also contains files whose names end in .txt, designed to be parsed with programs like awk . The data format is described by comments within those files and can be compared with the equivalent HTML files.
If the format of the text ever changes, the version number will change. If the changes are incompatible with previous usage, the number before the decimal point is altered. If they are compatible, the number after the decimal point is altered.
An example of compatibility is adding extra fields to the end of existing lines or adding new lines. Programs using these files should check the version number to ensure compatibility. Also, it might be useful to check the following:
DMF version shown by dmversion (1)
IRIX version shown by uname(1)
Linux kernel version shown by uname(1)
Linux distribution version shown by head /etc/*release