This chapter describes how to configure DMF, verify the configuration, and perform some periodic maintenance tasks:
To configure DMF, you will perform the following steps. Before starting, read “Configuration Considerations”.
Procedure 2-1. Configuration Steps
Install DMF according to the platform-specific instructions in the /CDROM/platform/DMF.Install file.
Determine how you want to complete periodic maintenance tasks. See “Automated Maintenance Tasks”.
Invoke dmmaint(8) (see “Overview of dmmaint”) to do the following:
Install the license on each DMF server. (DMF clients do not require a license.)
Create or modify your configuration file and define the following objects:
Base object
Daemon object
Daemon maintenance tasks
Automated space management
Media-specific process (MSP) or library server (LS)
You must also define the object for MSP/LS maintenance tasks, set up the MSPs and/or LSs, and configure your mounting service. See “Configuration Objects”.
Verify the configuration by clicking the Inspect button, which runs the dmcheck(8) script. See “Verifying the Configuration”.
If there are errors, fix them by clicking the Configure button to edit the configuration file. Repeat these steps until there are no errors.
Start DMF. See “Initializing DMF”.
This section discusses the configuration considerations that will affect your system:
The DMF server uses a set of pathnames in which it stores databases, log and journal files, and temporary file directories. These filesystems have the following requirements:
HOME_DIR is the base pathname for DMF directories in which databases reside. It must be a separate filesystem.
JOURNAL_DIR is the base pathname for DMF directories in which the daemon and LS database journal files reside. It must be a separate filesystem on a different disk from HOME_DIR .
SPOOL_DIR is the base pathname used to construct the directory names for DMF directories in which DMF log files reside. It must be a separate filesystem.
TMP_DIR is the base pathname used to construct the directory names for DMF directories in which DMF puts temporary files such as pipes. It should exist, but does not necessarily need to be a separate filesystem.
MOVE_FS is the base pathname for the scratch filesystem used to move files between MSPs or volume groups. This is a requirement only if you configure more than one MSP or volume group. If you have more than one MSP or volume group, MOVE_FS must be a separate filesystem, and it must be mounted to enable the Data Management API (DMAPI) interface.
All of these configuration requirements are checked by the dmcheck(8) command, which can be invoked with the dmmaint GUI's Inspect button.
| Note: When an MSP, LS, daemon, or configuration file object (such as dump_tasks) obtains a path such as HOME_DIR from the configuration file, the actual path used is the value of HOME_DIR plus the MSP/LS/daemon/object name appended as a subdirectory. For example, if the value of HOME_DIR was set to /dmf/home in the configuration file, and the object named dump_tasks used a value of HOME_DIR/tapes for the DUMP_TAPES parameter, then the actual path for DUMP_TAPES would be resolved to /dmf/home/dump_tasks/tapes. |
DMAPI is the mechanism between the kernel and the XFS or CXFS filesystem for passing file management requests between the kernel and DMF. Ensure that you have installed DMAPI and the appropriate patches as listed in the files accessed by the News button on the dmmaint(8) GUI.
| Caution: For filesystems to be managed by DMF, they must be mounted with the DMAPI interface enabled. Failure to enable DMAPI for DMF-managed user filesystems will result in a configuration error. See “DMAPI Requirement” in Chapter 1. |
Tape mounting services are available through OpenVault or the Tape Management Facility (TMF). The LS checks the availability of the mounting service when it is started and after each occurrence in which an LS write child or read child was unable to reserve its drive. If the mounting service is found to be unavailable, the LS does not start any new child processes until the mounting service is once again available.
If the unavailable mounting service is OpenVault, the LS sends an e-mail message to the administrator, asking that OpenVault be started, and then periodically polls OpenVault until it becomes available, at which time child processes are again allowed to run. For LS, this is the default procedure. You can use MAX_MS_RESTARTS to configure the number of automatic restarts.
If the unavailable mounting service is TMF, the LS not only attempts to initiate tmdaemon if it is not up (based on the exit status of tmstat), but it waits until a TMF device in the configuration pending state is configured up before it resumes processing. If TMF cannot be started or if no devices are configured up, the LS sends e-mail to the administrator and polls TMF until a drive becomes available. For LS, this is the default procedure. You can use MAX_MS_RESTARTS to configure the number of automatic restarts.
DMF state information is kept within a filesystem structure called an extended attribute . Extended attributes can be either inside the inode or in attribute blocks associated with the inode. DMF runs much faster when the extended attribute is inside the inode, because this minimizes the number of disk references that are required to determine DMF information. In certain circumstances, there can be a large performance difference between an inode-resident extended attribute and a non-resident extended attribute.
SGI recommends that you configure your filesystems so that the extended attribute is always inode-resident by using the IRIX mkfs_xfs command or the Linux mkfs.xfs command. Declare the inode size to be 512 bytes (-i size=512). Filesystems that already exist must be dumped, recreated, and restored.
A daemon database entry is composed of one or more fixed-length records: a base record ( dbrec) and zero or more path segment extension (pathseg ) records. The dbrec consists of several fields, including the path field.
If the value that is returned to the daemon by the MSP/LS (such as the pathname resulting from the NAME_FORMAT value template in an ftp or dsk MSP definition) can fit into the path field of the daemon's dbrec record, DMF does not require pathseg records. If the MSP/LS supplies a path value that is longer than the path field, DMF creates one or more pathseg records to accommodate the extra space.
The default size of the path field of the dbrec is 34 characters. This size allows the default paths returned by dmatls, dmdskmsp, and dmftpmsp to fit in the path field of dbrec as long as the user name portion of the dmftpmsp or dmdskmsp default path ( username/bit_file_identifier) is 8 characters or fewer. If you choose to use a value for NAME_FORMAT that results in longer pathnames, you may want to resize the path field in dbrec in order to increase performance.
The default size of the path field in the pathseg record is 64. For MSP path values that are just slightly over the size of the dbrec path field, this will result in a large amount of wasted space for each record that overflows into the pathseg record. The ideal situation would be to have as few pathseg records as possible.
The advantage of having very few pathseg records lies in increased efficiency for retrieving daemon database records. There is no need to access the pathseg key and data files to retrieve a complete daemon database record.
The size of the path field in the daemon dbrec record can be configured at any time before or after installation. (The same holds true for any installation that might be using the dmftpmsp or dmdskmsp with a different path-generating algorithm or any other MSP that supplies a path longer than 34 characters to the daemon.)
Procedure 2-2. Daemon Database Record Length Configuration
The steps to configure the database entry length are as follows:
If the dmfdaemon is running, use the following command to halt processing:
/etc/init.d/dmf stop |
If a daemon database already exists, perform the following commands:
cd HOME_DIR/daemon dmdump -c . > textfile cp dbrec* pathseg* dmd_db.dbd backup_dir rm dbrec* pathseg* dmd_db.dbd |
Where:
HOME_DIR is the value of HOME_DIR returned by the dmconfig base command
textfile is the name of a file that will contain the text representation of the current database
backup_dir is the name of the directory that will hold the old version of the database
Change to the rdm directory:
cd /usr/lib/dmf/rdm |
Back up the dmd_db.dbd and dmd_db.ddl files that reside in /usr/lib/dmf/rdm . This will aid in disaster recovery should something go wrong.
Edit dmd_db.ddl to set the new path field lengths for the dbrec and/or pathseg records.
Regenerate the new database definition, as follows:
/usr/lib/dmf/support/dmddlp -drsx dmd_db.ddl |
Back up the new versions of dmd_db.dbd and dmd_db.ddl for future reference or disaster recovery.
If the daemon database was dumped to text in step 2, enter the following commands:
cd HOME_DIR/daemon dmdadm -u -c "load textfile" |
(textfile was created in step 2)
If the daemon was running in step 1, restart it by executing the following command:
/etc/init.d/dmf start |
Ensure that the following interprocess communication kernel configuration parameters are set equal to or greater than the default before running DMF:
DMF lets you configure parameters for completing periodic maintenance tasks such as the following:
Making backups (full or partial) of user filesystems to tape
Making backups of DMF databases to disk
Removing old log files and old journal files
Monitoring DMF logs for errors
Running hard deletes
Running dmaudit(8)
Monitoring the status of tapes in LSs
Merging tapes that have become sparse (and stopping this process at a specified time)
Each of these tasks can be configured in the DMF configuration file through the use of TASK_GROUPS parameters for the DMF daemon and the LS. The tasks are then defined as objects.
For each task you configure, a time expression defines when the task should be done and a script file is executed at that time. The tasks are provided for you in the /usr/lib/dmf directory.
The automated tasks are described in “Configuring Daemon Maintenance Tasks”. Table 2-1 provides a summary of the automated maintenance tasks.
Table 2-1. Automated Maintenance Task Summary
Object Type | Task | Purpose | Parameters |
|---|---|---|---|
Daemon | run_audit | Audit databases |
|
| run_copy_databases | Backup DMF databases | DATABASE_COPIES |
| run_full_dump | Full backup of filesystems For restores, see dmxfsrestore(8) | DUMP_DEVICE DUMP_FILE_SYSTEMS DUMP_FLUSH_DCM_FIRST DUMP_INVENTORY_COPY DUMP_MAX_FILESPACE DUMP_MIGRATE_FIRST DUMP_RETENTION DUMP_TAPES DUMP_VSNS_USED DUMP_XFSDUMP_PARAMS |
| run_hard_deletes | Hard-delete files | Uses DUMP_RETENTION |
| run_partial_dump | Partial backup of filesystems | Uses parameters set for run_full_dump |
| run_remove_journals | Remove old journal files | JOURNAL_RETENTION |
| run_remove_logs | Remove old log files | LOG_RETENTION |
| run_scan_logs | Scan log files for errors |
|
| |||
LS | run_compact_tape_report | Create tape reports |
|
| run_merge_stop | Stop tape merges |
|
| run_tape_merge | Merge sparse tapes | DATA_LIMIT THRESHOLD VOLUME_LIMIT |
| run_tape_report | Create tape reports |
|
| run_merge_mgr | Merge sparse tapes | DATA_LIMIT THRESHOLD VOLUME_LIMIT |
DCM-mode disk MSP | run_dcm_admin | Routine disk cache manager (DCM) administration |
|
On DMF servers, you can use the dmmaint utility to view DMF release-specific news and to view information related to the dependencies you should be aware of before you start DMF. (You can also view these files directly from the CD-ROM by using an editor such as vi on the /CDROM/ platform/DMF.News and /CDROM/ platform/DMF.Readme files.)
You can also use dmmaint to install your DMF licenses and edit the DMF configuration file. The advantage to using dmmaint rather than a text editor such as vi is that you can edit the configuration file and apply your changes atomically. dmmaint also allows you to verify your changes.
To use the dmmaint graphical user interface (GUI), ensure that your DISPLAY environment variable is defined, and then enter the following command:
# /usr/sbin/dmmaint & |
| Note: If DISPLAY is not defined, dmmaint reverts to line mode, which has menu selections that are equivalent to the fields and buttons on the graphic user interface. Line mode is provided for remote log in, and is not recommended for general use. |
The GUI displays the installed version of DMF. The Help menu provides access to the dmmaint and dmf.conf man pages. The GUI buttons are as follows:
| Button | Description |
| Configure | Lets you customize the DMF configuration file for the selected version of DMF. If this is the first time you have configured DMF, a window appears telling you that there is no configuration file. You are asked which file you would like to use as a basis for the new configuration. You may choose an existing file or one of several sample files that are preconfigured for different types of MSP or the LS. If a configuration file exists, a window appears that asks if you would like to modify the existing file or use an alternate file. If you choose an alternate file, you see the same window that you would see if this were a new configuration. After you choose a file to use as a basis, an editing session is started (in a new window) that displays a copy of that configuration file. You can make changes as desired. After exiting from the editor, you are prompted for confirmation before the original configuration file is replaced with the edited copy. For more information on configuration parameters, see Chapter 2, “Configuring DMF”, and the dmf.conf(5) man page (available from the Help button). |
| Inspect | Runs the dmcheck(8) program to report errors. You should run this program after you have created a configuration file. If there are errors, you can click the Configure button, make changes, and continue to alternate between Configure and Inspect until you are satisfied that the configuration is correct. |
| Dependencies | Displays the dependencies file, which contains information such as supported releases, patch requirements, and so on. The file is installed on the server platform in the following file:
|
| News | Displays the news file, which contains information such as new DMF features, changes in the products, descriptions of fixed bugs, and future product plans. The file is installed on the server platform in the following file:
|
| License Info | Displays the host name and unique system identifier (which you need to obtain a DMF server license), the name of the license file, and a short description of the state of any DMF license within the file. |
| Update License | Lets you make changes to the license file. An editing session is started in a new window displaying a copy of the contents of the license file. You can add or delete licenses as desired. After you exit the editor, positive confirmation is requested before the original license file is replaced by the modified copy. For more information, see “Licensing Requirement” in Chapter 1. |
The following procedure uses dmmaint to complete the initial configuration of DMF:
Procedure 2-3. Running dmmaint
Select Dependencies to read about all the hardware and software requirements that must be fulfilled before running DMF.
Select News to read about what is new with this revision of DMF.
If needed, select the Update License button and use the mouse to copy and paste your license into the file. Close the window. Select License Info and examine the output to verify that the license is installed correctly.
Select Configure to edit the configuration file. The first time that you select this button, dmmaint will prompt you for the file you want to use as a basis for the configuration. Choose to use your existing configuration file or one of the sample files provided. If you choose to use your existing configuration, you may need to add new parameters to implement new features.
If a configuration file exists, a window appears that asks if you would like to modify the existing configuration file or use an alternate file. If you choose an alternate file, you see the same window that you would see if this were a new configuration.
dmmaint then opens an editing window containing the configuration file, allowing you to modify the configuration to suit your needs.
When you exit the window, dmmaint will ask if you want to make your changes permanent. If so, click OK.
Click the Inspect button, which runs dmcheck to report any errors in that configuration. If there are errors, you can click the Configure button, make changes, and continue to alternate between Configure and Inspect until you are satisfied that the configuration is correct.
If you do not want DMF to be automatically started and stopped, enter the following command (you must be running as root):
chkconfig dmf off |
For information about how to start and stop DMF, see “Initializing DMF” and the dmfdaemon(8) and dmdstop(8) man pages.
The configuration file consists of configuration objects and parameters. The file uses the following types of configuration objects:
The base object, which defines pathname and file size parameters necessary for DMF operation.
The daemon object, which defines parameters necessary for dmfdaemon(8) operation.
The device objects, which define parameters necessary for automatic use of tape devices. Normally, the backup scripts would refer to a DMF drive group to define parameters necessary for accessing tape drives. But if they are to use drives not in use by DMF, a device object may be used to define these parameters.
Device objects are not used by tape LSs; instead, LSs reference drive group objects.
The filesystem object, which defines parameters necessary for migrating files in that filesystem.
The policy objects, which specify parameters to determine MSP or volume group selection, automated space-management policies, and/or file weight calculations in automatic space management.
The MSP objects, which define parameters necessary for that MSP's operation.
The task group objects, which define parameters necessary for automatic completion of specific maintenance tasks.
The library server (LS) object, which defines parameters relating to a tape library.
The drive group object, which defines parameters relating to a pool of tape devices in a specific library.
The volume group object, which defines parameters relating to a pool of tape volumes mountable on the drives of a specific drive group, capable of holding, at most, one copy of user files.
The resource scheduler object, which defines parameters relating to scheduling of tape devices in a drive group when requests from volume groups exceed the number of devices available.
The resource watcher object, which defines parameters relating to the production of files informing the administrator about the status of the LS and its components.
DMF configuration objects and parameters are also defined in the dmf.conf(5) man page and in Table 2-5.
Each object is configured by a sequence of lines called a configuration stanza. These have the following general form:
define object_name
TYPE object_type
parameter-1 values
...
parameter-n values
enddef |
For filesystems, object_name is the mount point. Otherwise, it is chosen by the administrator. object_type identifies the type (detailed in the following subsections). The parameters and their values depend on the type of the object. These stanzas are case-sensitive and can be indented for readability. The fields can be separated by spaces and/or tabs. Blank lines and all commentary text between a hash character (#) and the end of that line are ignored. Except for comments, any line ending in a back-slash (\) continues onto the next line. Before placing a new configuration into production, it is important to check it by running dmcheck(8).
The base configuration parameters define pathnames and file sizes necessary for DMF operation. It is expected that you will modify the pathnames, although those provided will work without modification. All pathnames must be unique.
| Warning: Do not change the directory names while DMF is running (changing the directory names can result in data corruption or loss). |
If you intend to run the OpenVault library management facility as the mounting service for DMF, you must configure the OV_KEY_FILE and OV_SERVER parameters. If you are running a different mounting service, you do not need these parameters. More configuration steps are necessary to configure DMF to use OpenVault; see “Using OpenVault for LS Drive Groups”.
Procedure 2-4. Base Object Configuration
The following example defines a base object:
define base
TYPE base
ADMIN_EMAIL root@dmfserver
HOME_DIR /dmf/home
TMP_DIR /tmp/dmf
SPOOL_DIR /dmf/spool/
JOURNAL_DIR /dmf/journals
JOURNAL_SIZE 10m
OV_KEY_FILE /dmf/home/ovkeys
OV_SERVER localhost
enddef |
| Note: Do not use automated space management to manage the HOME_DIR , SPOOL_DIR, or JOURNAL_DIR directories because DMF daemon processes will deadlock if files that they are actively using within these directories are migrated. dmcheck(8) reports an error if any of the HOME_DIR, SPOOL_DIR, or JOURNAL_DIR parameters are also configured as DMF-managed filesystems. Configure the daemon_tasks object to manage old log files and journal files in these directories (you can change the namedaemon_tasks to be anything you prefer). See “Configuring Daemon Maintenance Tasks”, for more information. |
The following steps explain pertinent information for configuring the base object:
Ensure that TYPE is set to base .
Configure the e-mail address specified by the ADMIN_EMAIL parameter to be the user to whom you want to send the output of the configured tasks described in “Automated Maintenance Tasks”.
Configure the filesystem specified by the HOME_DIR configuration parameter (referred to as HOME_DIR ) as a separate filesystem, and restrict its contents to DMF databases and relatively static files such as DMF scripts.
DMF cannot run if HOME_DIR runs out of space, and such an event is more likely to happen if it is another directory in /usr.
Set TMP_DIR to be any filesystem that can store temporary files. /tmp or a directory below /tmp is a common choice.
Configure the log file directory (referred to as SPOOL_DIR) as a separate filesystem so that log file growth does not impact the rest of the system.
Ensure that the journal file directory (referred to as JOURNAL_DIR) resides on a physical device completely separate from the one on which HOME_DIR resides. Backup copies of DMF databases should also be stored on the JOURNAL_DIR filesystem.
Configure the JOURNAL_SIZE parameter to be the maximum size allowable for a journal file before DMF closes it.
If you plan to run OpenVault, do the following:
Configure the OV_KEY_FILE parameter to be the name of the key file that holds security information for OpenVault.
Configure the OV_SERVER parameter to the name of the server that runs OpenVault.
For more information, see Procedure 2-12.
The daemon object defines configuration parameters necessary for the DMF daemon operation. It is expected that you will modify the values for the pathnames and MSP names.
| Parameter | |||
Description | |||
| TYPE | |||
dmdaemon (required name for this type of object)
| |||
| EXPORT_QUEUE | |||
Instructs the daemon to export details of its internal request queue to SPOOL_DIR/daemon_exports every two minutes, for use by dmstat(8) and other utilities. On a busy system, the responsiveness of the daemon may be improved by disabling this feature. This parameter may be set to OFF, ON, NO, or YES. The default is OFF. | |||
| MESSAGE_LEVEL | |||
Specifies the highest message level number that will be written to the daemon log. It must be an integer in the range 0-6; the higher the number, the more messages written to the log file. The default is 2. For more information on message levels, see “General Message Log File Format”. | |||
| MIGRATION_LEVEL | |||
Sets the highest level of migration service allowed on all DMF filesystems (you can configure a lower service level for a specific filesystem). The value can be:
| |||
| MOVE_FS | |||
Names the scratch filesystem used by dmmove(8) to move files between MSPs or volume groups. The filesystem specified must have been mounted with DMAPI enabled. There is no default. Necessary only if you wish to use dmmove. | |||
| LS_NAMES or MSP_NAMES | |||
Names the LSs or MSPs used by the DMF daemon. You must specify either LS_NAMES or MSP_NAMES, but not both (however, the value of either parameter can be a mixture of both forms). There is no default. The order of the values specified for this parameter is integral to the determination of the MSP or volume group from which the DMF daemon attempts to recall an offline file. If the offline file has more than one copy, DMF uses a specific order when it attempts to recall the file. It searches for a good copy of the offline file in MSP or LS order, from the dmdaemon object's MSP_NAMES or LS_NAMES parameter. If one of those names refers to an LS, it searches for the copy in drive group order, from the LS object's DRIVE_GROUPS parameter. It then searches for the copy in volume group order from the drive group object's VOLUME_GROUPS parameter.
| |||
| TASK_GROUPS | |||
Names the task groups that contain tasks the daemon should run. They are configured as objects of TYPE taskgroup. There is no default. For more information, see “Configuring Daemon Maintenance Tasks”. SGI recommends that you use the task groups specified in the sample configuration file, changing the parameters as necessary for your site. | |||
| RECALL_NOTIFICATION_RATE | |||
Specifies the approximate rate, in seconds, at which regions of a file being recalled are put online. This allows for access to part of a file before the entire file is recalled. The default is 30 seconds. Specify a value of 0 if you want the user process to be blocked until the entire recall is complete. The optimum setting of this parameter is dependent on many factors and must be determined by trial and error. The actual rate at which regions being recalled are put online may vary from the value of RECALL_NOTIFICATION_RATE. | |||
| PARTIAL_STATE_FILES | |||
Enables or disables the DMF daemon's ability to produce partial-state files. If this parameter is set to on or yes, the daemon will correctly process put and get requests that would result in a partial-state file. If this parameter is set to off or no, all put and get requests that require a change to the online status of the file will result in a file that is completely online or offline. That is, any put request that makes any part of the file offline will result in the entire file being made offline. Any get request that would result in any part of the file being brought back online will result in the entire file being brought back online. The default is on. | |||
| ENABLE_KRC | |||
Activates checks made by the DMF daemon to work around a known CXFS bug by enabling the kernel recall cache. See the “PSF and CXFS in DMF 3.2.0.0” section of the DMF.News file for more information about the problem. The value can be yes or on to enable the checks or no or off to disable the checks. The default is off. | |||
| MAX_VIRTUAL_MEMORY | |||
Specifies the maximum number of bytes to which the DMF daemon's virtual memory size is allowed to grow. This parameter is meant to prevent the DMF daemon's memory from growing so large that it overflows its virtual memory addressing limits and aborts. When the daemon has grown to this maximum size, the daemon will disable reading new requests from its existing connections that have already issued more than 50 requests. This throttling will remain in effect until the overall memory usage decreases by 10% as the result of request completions, at which time all connections will be reinstated for input. While the throttling is active, new commands are free to connect to the daemon and issue requests up to the point where they have issued the lower threshold number of 50 requests. This allows commands such as dmdidle(8), dmdstop(8), dmstat(8), dmput(1), and dmget(1) to be serviced by the daemon while the commands that are flooding the daemon with requests, such as dmmigrate(8) or dmfsfree (8), are throttled. Legal values are in the range 1 GB through 2 GB. The default is 2.0 GB, or roughly the address space of 32-bit addressing. You can use this parameter to limit the daemon's virtual memory if the default virtual memory size of 2.0 GB causes memory swapping or other problems. Once the daemon has grown to a particular size, it will not shrink in size even when memory usage, as defined by heap space allocated, decreases. As a result, modifying this parameter downward will require a DMF restart to take effect. | |||
Procedure 2-5. Daemon Configuration
The following example defines a daemon object:
define daemon
TYPE dmdaemon
MOVE_FS /move_fs
MIGRATION_LEVEL auto
LS_NAMES lib1 ftp2
TASK_GROUPS daemon_tasks dump_tasks
enddef |
The following steps explain pertinent information for configuring the daemon object.
Ensure that TYPE is set to dmdaemon . There is no default.
| Note: This cannot be set to dmfdaemon. It must be dmdaemon. |
If you have more than one MSP or volume group, ensure that the MOVE_FS parameter is set to a filesystem that can accept temporary files. This must be the root of a DMAPI filesystem. There is no default.
The MIGRATION_LEVEL parameter determines the level of service for migration to offline media. Migration from offline media (either automatic or manual recall) is not affected by the value of MIGRATION_LEVEL .
Configure MIGRATION_LEVEL to be one of the following:
none (no migration will take place on any DMF filesystem)
user (users/administrators can perform dmput(1) or dmmigrate(8) commands and no other migration will take place)
auto (automated space management on at least one DMF filesystem)
This value is the highest level you want to allow anywhere in your DMF environment. The default is auto. See “Configuring DMF Policies”, for information about configuring automated space management.
Configure MSP_NAMES or LS_NAMES to be the names of the MSPs or LSs to be used by this daemon. You will use these names when defining the MSP/LS objects and, for MSPs only, in SELECT_MSP parameters within policies. You must specify a value for LS_NAMES or MSP_NAMES (but not both); there is no default.
Configure the TASK_GROUPS parameter to the names of the objects used to define how periodic maintenance tasks are completed. In the example, daemon_tasks defines the tasks such as scanning and managing log files and journal files. The dump_tasks object defines tasks that back up DMF-managed filesystems. You can change the object names themselves (dump_tasks and daemon_tasks) to be any name you like. There is no default value for the object. See “Configuring Daemon Maintenance Tasks” for more information.
You can configure daemon_tasks parameters to manage how the DMF daemon performs the following maintenance tasks:
Running dmscanfs(8) on filesystems to collect file information for subsequent use by other scripts and programs (the run_filesystem_scan.sh task)
Creating a regular report (the run_daily_report.sh task)
Scanning recent log files for errors (the run_scan_logs.sh task)
Removing old log files (the run_remove_logs.sh task and the LOG_RETENTION parameter)
Removing old journal files (the run_remove_journals.sh task and the JOURNAL_RETENTION parameter)
Backing up DMF databases (the run_copy_databases.sh task and the DATABASE_COPIES parameter)
For each of these tasks, you can configure when the task should be run. For some of the tasks, you must provide more information such as destinations or retention times for output.
You can configure dump_tasks parameters to manage how the daemon completes the following tasks to back up the DMF-managed filesystems:
Fully backing up DMF-managed filesystems (the run_full_dump.sh task)
Partially backing up DMF-managed filesystems (the run_partial_dump.sh task)
Hard-deleting files no longer on backup tape (the run_hard_deletes.sh task)
Managing the data from the filesystem dumps (the DUMP_TAPES, DUMP_RETENTION, DUMP_DEVICE , DUMP_MIGRATE_FIRST, DUMP_INVENTORY_COPY , DUMP_FILE_SYSTEMS, and DUMP_VSNS_USED parameters)
For each of these tasks, you can configure when the task is run. To manage the tapes, you must provide information such as tape and device names, retention times for output, whether to migrate files before dumping the filesystem, and locations for inventory files. Table 2-1 provides a summary of automated maintenance tasks.
Procedure 2-6. Configuring the daemon_tasks Object
The following steps explain how to define a daemon_tasks object. You can change the object name itself (daemon_tasks ) to be any name you like. Do not change the script names. You may comment out the RUN_TASK parameters for any tasks you do not want to run. The following example configures a daemon_tasks object:
define daemon_tasks
TYPE taskgroup
RUN_TASK $ADMINDIR/run_filesystem_scan.sh at 2:00
SCAN_FAST yes
RUN_TASK $ADMINDIR/run_daily_report.sh at 3:00
RUN_TASK $ADMINDIR/run_audit.sh every day \
at 23:00
RUN_TASK $ADMINDIR/run_scan_logs.sh at 00:01
RUN_TASK $ADMINDIR/run_remove_logs.sh every \
day at 1:00
LOG_RETENTION 4w
RUN_TASK $ADMINDIR/run_remove_journals.sh every \
day at 1:00
JOURNAL_RETENTION 4w
RUN_TASK $ADMINDIR/run_copy_databases.sh \
every day at 3:00 12:00 21:00
DATABASE_COPIES /save/dmf_home /alt/dmf_home
enddef |
Define the object to have the same name that you provided for the TASK_GROUPS parameter of the daemon object. In the example it is daemon_tasks.
Ensure that TYPE is set to taskgroup . There is no default.
Configure the RUN_TASK parameters. DMF substitutes $ADMINDIR in the path with the actual directory containing auxiliary programs and scripts (that is, /usr/lib/dmf). When the task is run, it is given the name of the object that requested the task as the first parameter and the name of the task group (in this case daemon_tasks) as the second parameter. The task itself may use the dmconfig(8) command to obtain further parameters from either of these objects.
All of the RUN_TASK parameters require that you provide a time_expression.
The time_expression defines when a task should be done. It is a schedule expression that has the following form:
[every n period] [at hh:mm[:ss] ...] [on day ...] |
period is one of minute[s], hour[s], day[s], week[s], or month[s].
n is an integer.
day is a day of the month (1 through 31) or day of the week (sunday through saturday ).
The following are examples of valid time expressions:
at 2:00 every 5 minutes at 1:00 on tuesday |
Some of the tasks defined by the RUN_TASK parameters require more information. You must provide the following:
The run_filesystem_scan.sh task runs dmscanfs(8) on filesystems specified by SCAN_FILESYSTEMS (by default, all DMF-managed filesystems) writing the output to a file specified by SCAN_OUTPUT (by default /tmp/dmscanfs.output).
This file, if it exists, is used by run_daily_report.sh and dmstat(8) and may be of use to site-written scripts or programs. Although DMF does not require this file, the output from run_daily_report.sh and dmstat will be incomplete if it is unavailable.
If SCAN_FAST is set to no or off, dmscanfs will use its recursive option, which is much slower but results in pathnames being included in the output file. The default is yes.
By default, another output file is written to the bfid2path file in the daemon's SPOOL_DIR directory, optimized for use by dmstat; setting SCAN_FAST or SCAN_FOR_DMSTAT to no will suppress this.
The run_daily_report.sh task reports on DCM MSPs and managed filesystems (if run_filesystem_scan.sh has been run recently) and on all LSs, and has superseded run_tape_report.sh and run_compact_tape_report.sh.
The run_audit.sh task runs dmaudit. For this task, provide a time_expression . If it detects any errors, the run_audit.sh task mails the errors to the e-mail address defined by the ADMIN_EMAIL parameter of the base object (described in “Configuring the Base Object”).
The run_scan_logs.sh task scans the DMF log files for errors. For this task, provide a time_expression . If the task finds any errors, it sends e-mail to the e-mail address defined by the ADMIN_EMAIL parameter of the base object.
The run_remove_logs.sh task removes logs that are older than the value you provide by specifying the LOG_RETENTION parameter. You also provide a time_expression to specify when you want the run_remove_logs.sh to run. In the example, log files more than 4 weeks old are deleted each day at 1:00 A.M. Valid values for LOG_RETENTION are a number followed by m[inutes], h[ours], d[ays], or w[eeks].
The run_remove_journals.sh task removes journals that are older than the value you provide by specifying the JOURNAL_RETENTION parameter. You also provide a time_expression to specify when you want the run_remove_journal.sh to run. In the example, journal files more than 4 weeks old are deleted each day at 1:00 A.M. Valid values for JOURNAL_RETENTION are a number followed by m[inutes] , h[ours], d[ays], or w[eeks].
| Note: The run_remove_journals.sh and run_remove_logs.sh tasks are not limited to the daemon logs and journals; they also clear the logs and journals for MSPs and LSs. |
The run_copy_databases.sh task makes a copy of the DMF databases. For this task, in addition to a value for time_expression, provide a value for the DATABASE_COPIES parameter that specifies one or more directories. If you specify multiple directories, spreading the directories among multiple disk devices minimizes the chance of losing all the copies of the database.
The task copies a snapshot of the current DMF databases to the directory with the oldest copy. Integrity checks are done on the databases before the copy is saved. If the checks fail, the copy is not saved, and the task sends e-mail to the e-mail address defined by the ADMIN_EMAIL parameter of the base object.
Procedure 2-7. Configuring the dump_tasks Object
The following steps explain how to define a dump_tasks object. You can change the object name itself (dump_tasks ) to be any name you like.
Do not change the script names.
You may comment out the RUN_TASK parameters for any tasks you do not want to run.
The following example would configure a dump_tasks object:
define dump_tasks
TYPE taskgroup
RUN_TASK $ADMINDIR/run_full_dump.sh on \
sunday at 00:01
RUN_TASK $ADMINDIR/run_partial_dump.sh on \
monday tuesday wednesday thursday \
friday saturday at 00:01
RUN_TASK $ADMINDIR/run_hard_deletes.sh
at 23:00
#
DUMP_TAPES HOME_DIR/tapes
DUMP_RETENTION 4w
DUMP_DEVICE SILO_2
DUMP_MIGRATE_FIRST yes
DUMP_INVENTORY_COPY /save/dump_inventory
enddef |
Define the object to have the same name that you provided for the TASK_GROUPS parameter of the daemon object. In the example it is dump_tasks.
Ensure that TYPE is set to taskgroup . There is no default.
Configure the RUN_TASK parameters. See step 3 in Procedure 2-6, for information about $ADMINDIR and time_expression.
The following steps specify the information you must provide for the tasks to run correctly:
The run_full_dump.sh task runs a full backup of DMF-managed filesystems at intervals specified by the time_expression. In the example, the full backup is run each week on Sunday morning one minute after midnight.
The run_partial_dump.sh task backs up only those files in DMF-managed filesystems that have changed since the time a full backup was completed. The backups are run at intervals specified by the time_expression. In the example, it is run each day of the week except Sunday, at one minute after midnight.
The run_hard_deletes.sh task removes from the database any files that have been deleted but can no longer be restored because the backup tapes have been recycled (that is, it hard-deletes the files). The backup tapes are recycled at the time interval set by the DUMP_RETENTION parameter described in the next step. For more information on hard-deleting files, see “Soft- and Hard-Deletes” in Chapter 7.
Manage the data from the filesystem dumps by configuring the parameters listed below.
The parameters specified in the task group include:
Normally, a drive group object is used to define the tape devices to be used by a dump_tasks task, with the DMF library server and the backup scripts sharing the same devices. However, if backups are to use different drives from those in use by DMF, they should be defined by a device object. The parameters you define are based on the mounting service you intend to use.
The following parameters are common to all device objects:
| Option | Description | |
| TYPE | device (required name for this type of object) | |
| MOUNT_SERVICE | Specifies the mounting service to use. Supported values are openvault and tmf. This parameter is required; there is no default. | |
| MOUNT_SERVICE_GROUP | Specifies the name by which the object's devices are known to the mounting service. In the case of TMF, this is the device group name that would be used with the -g option on the tmmnt command. For OpenVault, this is the OpenVault drivegroup name that would be listed by the ov_drivegroup command. If this parameter is not specified, the device object's name is used. | |
| OV_ACCESS_MODES | Specifies a list of access mode names that control how data is written to tape. The default value is readwrite when migrating and readonly when recalling. This parameter is optional. | |
| OV_INTERCHANGE_MODES | Specifies a list of interchange mode names that control how data is written to tape. This can be used to control whether the device compresses data as it is written. This optional parameter is applied when a tape is mounted or rewritten. | |
| TMF_TMMNT_OPTIONS | Specifies command options that should be added to the tmmnt command when mounting a tape. DMF uses the -Z option to tmmnt, so options controlling block size and label parameters are ignored. Use -g if the group name is different from the device object's name. Use -i to request compression. |
You must have a filesystem object for each filesystem that can migrate files.
The filesystem object parameters are as follows:
| Parameter | Value | ||||||||||||||||||
| TYPE | |||||||||||||||||||
| BUFFERED_IO_SIZE | Specifies the size of I/O requests when reading from this filesystem using buffered I/O. The legal range of values is 4096 through 16777216. The default is 262144. | ||||||||||||||||||
| DIRECT_IO_SIZE | Specifies the size of I/O requests when reading from this filesystem using direct I/O (see O_DIRECT in the open (2) man page for a description of direct I/O). The legal range of values is 65536 through 18446744073709551615 . The default value depends on the filesystem's configuration, but will not exceed the value of DIRECT_IO_MAXIMUM_SIZE defined in the base object. | ||||||||||||||||||
| MAX_MANAGED_REGIONS | Sets the maximum number of managed regions that DMF will assign to a file on a per-filesystem basis. You can set MAX_MANAGED_REGIONS to any number that is less than the actual number of regions that will fit in a filesystem attribute. For XFS filesystems, that number is 3275. By default, DMF allows a DMF attribute to contain the maximum number of managed regions that will still allow the attribute to fit completely inside the inode, based on inode size and attr type. The default value for a filesystem that does not have a MAX_MANAGED_REGIONS parameter in its configuration file stanza is calculated at filesystem mount time. This value is chosen to ensure that the DMF attribute will fit inside the inode, assuming that no other attribute (such as an ACL or a parent inode pointer) is already occupying the inode's attribute space. Table 2-2 lists the default maximum file regions for XFS filesystems.
Table 2-2. Default Maximum File Regions for XFS Filesystems
For information about setting the attr type, see the mkfs(1M) or mount(1M) man pages. | ||||||||||||||||||
| MESSAGE_LEVEL | Specifies the highest message level number that will be written to the automated space management log (autolog). It must be an integer in the range 0-6; the higher the number, the more messages written to the log file. The default is 2. For more information on message levels, see “General Message Log File Format”. | ||||||||||||||||||
| MIGRATION_LEVEL | Sets the level of migration service for the filesystem. Valid values are:
The migration level actually used for the filesystem is the lesser of the MIGRATION_LEVEL of the daemon object and this value. The default is auto. | ||||||||||||||||||
| MIN_DIRECT_SIZE | Determines whether direct or buffered I/O is used when reading from this filesystem (see O_DIRECT in the open(2) man page for a description of direct I/O). If the number of bytes to be read is smaller than the value specified, buffered I/O is used, otherwise direct I/O is used. The legal range of values is 0 (direct I/O is always used) through 18446744073709551615 (direct I/O is never used). The default is 0.
| ||||||||||||||||||
| POLICIES | Specifies the names of the configuration objects defining policies for this filesystem. | ||||||||||||||||||
| TASK_GROUPS | Names the task groups that contain tasks the daemon should run. They are configured as objects of TYPE taskgroup. There is no default. Currently there are no defined tasks for filesystems. |
The following example defines a filesystem object:
define /c
TYPE filesystem
MIGRATION_LEVEL user
POLICIES fs_msp
enddef |
Procedure 2-8. Configuring filesystem Objects
The following steps explain pertinent information for configuring the above filesystem object:
Ensure that define has a value that is the mount point of the filesystem you want DMF to manage. Do not use the name of a symbolic link. There is no default.
Ensure that TYPE is set to filesystem . There is no default.
The MIGRATION_LEVEL parameter determines the level of service for migration to offline media. Migration from offline media (either automatic or manual recall) is not affected by the value of MIGRATION_LEVEL .
Configure MIGRATION_LEVEL to be one of the following:
none (no migration will take place on this filesystem)
user (users/administrators can perform dmput(1) or dmmigrate(8) commands but no other migration will take place)
auto (automated space management will be used on this filesystem)
The default is auto.
See “Configuring DMF Policies” and Procedure 2-9, for information about configuring automated space-management policies.
| Note: user is the highest migration level that can be associated with a real-time partition. |
Use the POLICIES parameter to declare one or more migration policies that will be associated with this filesystem. Policies are defined with policy objects (see “Configuring DMF Policies”). The POLICIES parameter is required; there is no default value. A policy can be unique to each DMF-managed filesystem, or it can be reused numerous times.
A policy object is used to specify a migration policy. The following types of migration policies can be defined:
Automated space management
File weighting
MSP or volume group selection
Disk cache manager (DCM) use (see “DCM Policies”)
The following rules govern the use of policy objects with the POLICIES parameter of the filesystem object:
The POLICIES parameter for a filesystem must specify one and only one MSP or volume group selection policy.
If the MIGRATION_LEVEL for a filesystem is auto, the POLICIES parameter for that filesystem must specify one and only one space-management policy.
You do not need to specify a weighting policy if the default values are acceptable.
You can configure one policy that defines all three groups of policy parameters (space management, file weight, and MSP or volume group selection) and share that policy among all the filesystems. Alternatively, you might create an MSP or volume group selection policy for all filesystems and a space-management policy (including weighting parameters) for all filesystems.
The policy object parameters described below are grouped by function.
DMF lets you automatically monitor filesystems and migrate data as needed to prevent filesystems from filling. This capability is implemented in DMF with a daemon called dmfsmon(8). After the dmfsmon daemon has been initiated, it will begin to monitor the DMF-managed filesystem to maintain the level of free space configured (in the configuration file).
Chapter 3, “Automated Space Management”, describes automated space management in more detail.
The following are parameters that control automated space management on a filesystem:
| Note: Ideal values for these parameters are highly site-specific, based largely on filesystem sizes and typical file sizes. |
| Parameter | Description |
| TYPE | |
| FREE_DUALSTATE_FIRST | When set to on, specifies that dmfsmon will first free dual-state and partial-state files before freeing files it must migrate. The default is off. |
| FREE_SPACE_DECREMENT | Specifies the percentage of filesystem space by which dmfsmon will decrement FREE_SPACE_MINIMUM if it cannot find enough files to migrate so that the value is reached. The decrement is applied until a value is found that dmfsmon can achieve. If space later frees up, the FREE_SPACE_MINIMUM is reset to its original value. Valid values are in the range 1 through the value of FREE_SPACE_TARGET. The default is 2. |
| FREE_SPACE_MINIMUM | Specifies the minimum percentage of free filesystem space that dmfsmon maintains. dmfsmon will begin to migrate files when the available free space for the filesystem falls below this percentage value. This parameter is required; there is no default. |
| FREE_SPACE_TARGET | Specifies the percentage of free filesystem space that dmfsmon will try to achieve if free space reaches or falls below FREE_SPACE_MINIMUM . This parameter is required; there is no default. |
| MIGRATION_TARGET | Specifies the percentage of filesystem capacity that DMF maintains as a reserve of dual-state files whose online space can be freed if free space reaches or falls below FREE_SPACE_MINIMUM. dmfsmon tries to make sure that this percentage of the filesystem is migrated, migrating, or free after it runs to make space available. This parameter is required; there is no default. |
An important part of automatic space management is selecting files to migrate and determining where to migrate them. When DMF is conducting automated space management, it derives an ordered list of files (called a candidate list) and migrates or frees files starting at the top of the list. The ordering of the candidate list is determined by weighting factors that are defined by using weighting-factor parameters in the configuration file.
DMF can be configured to have many MSPs or volume groups. Each MSP or volume group manages its own set of volumes. The MSP or volume group selection parameters allow you to direct DMF to migrate files with different characteristics to different MSPs or volume groups.
The file weighting and MSP or volume group selection parameters can be used more than once to specify that different files should have different weighting or MSP or volume group selection values.
The policy parameters for file weighting are as follows:
| Parameter | Description | ||
| AGE_WEIGHT | Specifies a floating point constant and floating point multiplier to use to calculate the weight given to a file's age. AGE_WEIGHT is calculated as follows:
If DMF cannot locate values for this parameter, it uses a floating point constant of 1 and a floating point multiplier of 1. This parameter accepts an optional when clause, which contains a conditional expression. This parameter also accepts an optional ranges clause, which specifies the ranges of a file for which the parameter applies. | ||
| SPACE_WEIGHT | Specifies a floating point constant and floating point multiplier to use to calculate the weight given to a file's size. SPACE_WEIGHT is calculated as follows:
If DMF cannot locate values for this parameter, it uses a floating point constant of 0 and a floating point multiplier of 0. For a partial-state (PAR) file, file_disk_space_in_bytes is the amount of space occupied by the file at the time of evaluation. This parameter accepts an optional when clause, which contains a conditional expression. This parameter also accepts an optional ranges clause, which specifies the ranges of a file for which the parameter applies. |
The parameter for MSP or volume group selection follows:
| Parameter | Description |
| SELECT_MSP or SELECT_VG | Specifies the MSPs and volume groups to use for migrating a file. (It is not used for defining which MSP or volume group to use for recalls; for that, see the definitions of the LS_NAMES, MSP_NAMES , DRIVE_GROUPS, and VOLUME_GROUPS parameters.) You can list as many MSP or volume group names as you have MSP or volume group objects defined. A copy of the file will be migrated to each MSP or volume group listed. The special MSP or volume group name none means that the file will not be migrated. If you define more than one MSP or volume group, separate the names with white space. You can specify either SELECT_MSP or SELECT_VG; the names are equivalent. Volume groups, MSPs, or a mixture of both may be specified by either parameter. If no SELECT_MSP or SELECT_VG parameter applies to a file, it will not be migrated. The parameters are processed in the order they appear in the policy. There is no default. This parameter allows conditional expressions based on the value of a file tag. See “Customizing DMF” in Chapter 1. The root user on the DMF server can override the selection specified in this parameter through the use of the -V option on dmput, or with libdmfusr.so calls. If site-defined policies are in place, they may also override this parameter. |
The file weighting and MSP selection parameters accept an optional when to restrict the set of files to which that parameter applies. It has the following form:
when expression |
expression can include any of the following simple expressions:
| Expression | Description | |
| age | Specifies the number of days since last modification or last access of the file, whichever is more recent. | |
| gid | ||
| sitefn | Invokes a site-defined policy function once for each file being considered, and is replaced by the return code of the function. This is only applicable to the AGE_WEIGHT, SPACE_WEIGHT, SELECT_MSP, and SELECT_VG parameters in a filesystem's policy stanza. For more information, see Appendix C, “Site-Defined Policy Subroutines and the sitelib.so Library”. | |
| sitetag | Specifies a site-determined number associated with a file by the dmtag(1) command, in the range 0 - 4294967295. For example:
| |
| size | ||
| softdeleted | Specifies whether or not the file corresponding to a cached copy has been soft deleted; only applicable to the CACHE_AGE_WEIGHT, CACHE_SPACE_WEIGHT, and SELECT_LOWER_VG parameters in a DCM-mode MSP's policy stanza. Values are false and true. | |
| space | Specifies the number of bytes the file occupies on disk (always a multiple of the blocksize, which may be larger or smaller than the length of the file). For a partial-state (PAR) file, the value used is the space that the file occupies on disk at the time of evaluation. | |
| uid |
Combine expressions by using and, or , and ().
Use the following operators to specify values:
| = |
| != |
| > |
| < |
| >= |
| <= |
| in |
The following are examples of valid expressions:
space < 10m (space used is less than 10 million bytes)
uid <= 123 (file's user ID is less than or equal to 123)
gid = 55 (file's group ID is 55)
age >= 15 (file's age is greater than or equal to 15 days)
space > 1g (space used is greater than 1 billion bytes)
uid in (chris, 10 82-110 200) (file owner's user name is chris or
the file owner's UID is 10, in the range 82-110, or 200)
(gid = 55 or uid <= 123) and age < 5
(file's age is greater than 5 days and its
group ID is 55 or its user ID is higher than 123) |
The AGE_WEIGHT and SPACE_WEIGHT parameters accept an optional ranges clause to restrict the ranges of a file for which a parameter applies. The clause has the following form, where byteranges is one or more byte ranges:
ranges byteranges |
Each byte range consists of a set of numbers that indicate byte positions. (You can also use BOF or bof to indicate the first byte in the file and EOF or eof to indicate the last byte in the file.) Each byte range is separated by a comma and can have one of the following forms:
A specification of two byte positions, where first specifies the first byte in the range and last specifies the last byte in the range:
first:last |
If unsigned, first and last count from the beginning of the file; if preceded by a minus sign (-), they count backwards from the end of the file.
The first byte in the file is byte 0 or BOF and the last byte is -0 or EOF. Therefore, BOF:EOF and 0:-0 both define a range covering the entire file.
For example:
ranges 0:4095 specifies the first 4096 bytes of the file
ranges -4095:EOF specifies the last 4096 bytes of the file
A specification of the size of the range, starting at a given point, where first is a byte position as above and size is the number of bytes in the range, starting at first:
first+size |
For example, the following indicates bytes 20 through 29:
ranges 20+10 |
If size is preceded by a minus sign, it specifies a range of size bytes ending at first. For example, the following indicates bytes 11 through 20:
ranges 20+-10 |
A specification of the size of the range only (without a colon or plus symbol), assumed to start at the end of file (when preceded by a minus sign) or beginning of file:
-size size |
For example, the following specifies the last 20 bytes in the file:
ranges -20 |
The first, last, or size values can be of the following forms:
A hexadecimal number: 0xn
A based number: base# n
A decimal number with an optional trailing scaling character. The decimal number may include a decimal point (.) and exponent. The trailing scaling character may be one of the following (all of which are powers of 1000, not 1024):
| k or K for 1 thousand |
| m or M for 1 million |
| g or G for 1 billion |
| t or T for 1 trillion |
| p or P for 1 quadrillion |
| Note: DMF may round byte ranges and join nearby ranges if necessary. If a range is given a negative weight, rounding may cause additional bytes to be ineligible for automatic space management. |
Do not use a ranges clause when partial-state files are disabled in DMF. Specifying many ranges for a file is discouraged, as it can cause the time and memory used by automatic space management to grow. DMF has an upper limit on the number of regions that can exist within a file; this can sometimes cause a range to be given an effective lower weight than what was specified in the configuration file. This might happen if the file is already partial-state and the range with largest weight cannot be made offline (OFL) because that would create too many regions. If the file has too many regions to make the range offline, but it could be made offline at the same time as a range with lower weight, it will be given the lower weight. If more than one range in the middle of a file is not a candidate for automatic space migration, the limit on the number of regions may make it impossible to automatically free other regions of the file.
The following procedures explain how to create policies for automated space management (including file weighting) and MSP or volume group selection.
Procedure 2-9. Configuring Objects for Automated Space Management
The following steps explain pertinent information for configuring the above policy object:
Ensure that define has a value you set previously in the POLICIES parameter of a filesystem object. There is no default.
Ensure that TYPE is set to policy . There is no default.
Configure automated space management as follows:
Configure MIGRATION_TARGET to an integer percentage of total filesystem space. DMF attempts to maintain this percentage as a reserve of space that is free or occupied by dual-state files that can be deleted if the filesystem free space reaches or falls below FREE_SPACE_MINIMUM. The default is 30.
Configure FREE_SPACE_TARGET to an integer percentage of total filesystem space. DMF will try to achieve this level of free space when free space reaches or falls below FREE_SPACE_MINIMUM. The default is 20.
Configure FREE_SPACE_MINIMUM to an integer percentage of the total filesystem space that DMF must maintain as free. DMF will begin to migrate files when the available free space for the configured filesystem reaches or falls below this percentage value. The default is 10.
Configure FREE_DUALSTATE_FIRST to be on if you want DMF to free the space used by dual-state or partial-state files before it migrates and frees regular files. The default is off.
Configure the age and size weighting factors associated with a file when it is evaluated for migration as follows:
The syntax of the AGE_WEIGHT parameter is a floating-point constant followed by a floating-point multiplier. The age weight is calculated as follows:
constant + (multiplier x age_in_days) |
Add a when clause to select which files should use these values. DMF checks each AGE_WEIGHT parameter in turn, in the order they occur in the configuration file. If the when clause is present and no ranges clause is present, DMF determines whether the file matches the criteria in the clause. If no when clause is present, a match is assumed. If the file matches the criteria, the file weight is calculated from the parameter values. If they do not match, the next instance of that parameter is examined.
An AGE_WEIGHT of 1 1.0 is used if no AGE_WEIGHT applies for a file.
Example 2-1. policy Object for Automated Space Management
define fs_space
TYPE policy
MIGRATION_TARGET 50
FREE_SPACE_TARGET 10
FREE_SPACE_MINIMUM 5
FREE_DUALSTATE_FIRST off
AGE_WEIGHT 0 0.00 when age < 10
AGE_WEIGHT 1 0.01 when age < 30
AGE_WEIGHT 10 0.05 when age < 120
AGE_WEIGHT 50 0.1
SPACE_WEIGHT 0 0
enddef |
In Example 2-1, files that have been accessed or modified within the last 10 days have a weight of 0. File migration likelihood increases with the length of time since last access because the file will have a greater weight. The final line specifies that files which have not been accessed or modified in 120 days or more have a far greater weight than all other files.
The syntax of SPACE_WEIGHT parameters is a floating-point constant followed by a floating-point multiplier. Calculate the space weight as follows:
constant + (multiplier x file_disk_space_in_bytes) |
In Example 2-1, the size of the file does not affect migration because all files have SPACE_WEIGHT of 0.
A SPACE_WEIGHT of 0 0.0 is used if no SPACE_WEIGHT applies for a file.
Configure negative values to ensure that files are never automatically migrated. For example, you might want to set a minimum age for migration. The following parameter specifies that files that have been accessed or modified within 1 day are never automatically migrated:
AGE_WEIGHT -1 0.0 when age <= 1 |
SPACE_WEIGHT -1 0 when space <= 4k |
If partial-state files are enabled on your machine (meaning that you have the PARTIAL_STATE_FILES configuration file parameter set to on and have the appropriate kernel installed, according to the information in the DMF.News file), you can use the ranges clause to select ranges of a file.
DMF checks each AGE_WEIGHT parameter in turn, in the order they occur in the configuration file. As described in step 4a above, DMF checks the when clause, if present, to see if the file matches the criteria. If the file matches and a ranges clause is present, DMF determines if that range has already been weighted. If it has not been weighted, the specified range is given the weight calculated from the parameter values. DMF examines the next instance of the parameter until all ranges in the file have been assigned a weight.
Example 2-2. policy Object for Automated Space Management using Ranges
define fs2_space
TYPE policy
MIGRATION_TARGET 50
FREE_SPACE_TARGET 10
FREE_SPACE_MINIMUM 5
FREE_DUALSTATE_FIRST off
AGE_WEIGHT -1. 0.00 ranges 0:4095 when uid=624
AGE_WEIGHT -1 0 ranges 0:4095,-4095:EOF when uid=321
AGE_WEIGHT 1 0.01 when age < 30
AGE_WEIGHT 10 0.05 when age < 120
AGE_WEIGHT 50 0.1
SPACE_WEIGHT 0 0
enddef |
In Example 2-2, if a file is owned by UID 624 and is 1004096 byes long, the first 4096 bytes are given an AGE_WEIGHT of -1. The remaining 1000000 bytes are given an AGE_WEIGHT based on the age of the file. Therefore, the first 4096 bytes of the file would not be eligible for being put offline by automatic space management. If a file is owned by UID 321, the first and last 4096 bytes of it are not eligible for being put offline by automatic space migration. If a file is owned by UID 956, the policy in Example 2-2 would give the entire file an AGE_WEIGHT based on its age. SPACE_WEIGHT parameters are evaluated similarly.
| Note: DMF calculates the size weight and age weight separately. If either value is less than zero, the file is not automatically migrated and the file or range is not automatically freed. Otherwise, the two values are summed to form the file's or range's weight. |
The following example defines a policy object for MSP or volume group selection:
define fs_msp
TYPE policy
SELECT_MSP none when space < 65536
SELECT_MSP cart1 cart2 when gid = 22
SELECT_MSP cart1 when space >= 50m
SELECT_VG cart2
enddef |
Procedure 2-10. Configuring Objects for MSP or Volume Group Selection
The following steps explain pertinent information for configuring the above policy object:
Ensure that define has a value that you set previously in the POLICIES parameter of the filesystem object. There is no default.
Ensure that TYPE is set to policy . There is no default.
Ensure that the MSP or volume group names you specify as the first value of the SELECT_MSP or SELECT_VG parameter is either the name of an MSP you set previously in the MSP_NAMES or LS_NAMES parameter of the daemon object, or is the name of a volume group that is a component of an LS named in that same parameter. There is no default.
Configure MSP or volume group selection criteria as follows:
If you want to select an MSP or volume group based on file size, use parameters such as the following, which send large files to cart1 and small files to cart2:
SELECT_MSP cart1 when space >= 50m SELECT_MSP cart2 when space >= 65536 |
The order of the SELECT statements is important. The first SELECT statement that applies to the file is honored. For example, if the statements above were reversed, a 50m file would be migrated to cart2, because the check for greater than or equal to (>=) 65536 would be done first, and it would be true.
If you want certain files to be copied to more than one MSP or volume group, use syntax such as the following, which migrates all files that have a group ID of 22 to both of the configured MSPs or volume groups:
SELECT_MSP cart1 cart2 when gid = 22 |
Separate multiple MSP or volume group names with a blank space.
If you want to ensure that some files are never migrated, you can designate the MSP or volume group selection as none. The following line from the sample file ensures that files smaller than 65,536 bytes are not migrated:
SELECT_MSP none when space < 65536 |
Note: The space expression references the number
of bytes the file occupies on disk, which may be larger or smaller than
the length of the file. For example, you might use the following line
in a policy:
Your intent would be to restrict files smaller than 4 Kbytes from migrating. However, this line may actually allow files as small as 1 byte to be migrated, because while the amount of data in the file is 1 byte, it will take 1 block to hold that 1 byte. If your filesystem uses 4-Kbyte blocks, the space used by the file is 4096, and it does not match the policy line. To ensure that files smaller than 4 Kbytes do not migrate, use the following line:
(You could use either SELECT_VG or SELECT_MSP in these examples.) |
A disk cache manager (DCM) is a disk MSP that has been configured to use a dedicated filesystem as a cache to improve the performance of a tape-based volume group. This cache has similar requirements to those of a DMF-managed filesystem:
Automatic space management
File weighting
Selection of one or more volume groups to provide tape-based storage
DCM uses the following configuration parameters, which are similar to standard disk MSP parameters:
| DCM | Standard Disk MSP |
| DUALRESIDENCE_TARGET | MIGRATION_TARGET |
| FREE_DUALRESIDENT_FIRST | FREE_DUALSTATE_FIRST |
| SELECT_LOWER_VG | SELECT_VG |
| CACHE_AGE_WEIGHT | AGE_WEIGHT |
| CACHE_SPACE_WEIGHT | SPACE_WEIGHT |
The DCM parameters have the same format and acceptable values as their disk-MSP-managed filesystem counterparts, with the following differences:
The DCM supports the concept of dual-residence , which means that a cache-resident copy of a migrated file has already been copied to tape, and can therefore be released quickly in order to prevent the cache filling, without any need to first copy it to tape. It is analogous to a dual-state file in the standard disk-MSP-managed filesystem and has equivalent policy parameters to control it.
The age and space weighting parameters refer to the copies in the cache, not the originals in the managed filesystem. (A ranges clause is not valid with the CACHE_AGE_WEIGHT or CACHE_SPACE_WEIGHT parameters.)
SELECT_LOWER_VG defines which volume groups should maintain tape-based copies of files in the cache, and under what conditions that would define dual-residence.
The following disk MSP space management parameters are also applicable to DCM:
FREE_SPACE_MINIMUM FREE_SPACE_TARGET FREE_SPACE_DECREMENT SITE_SCRIPT |
Each object shown in Figure 1-3, must have an object defined in the configuration file. The options shown in the following sections are only the most common. For the complete set, see the dmf.conf(5) man page. For a summary of the parameters and the object to which they apply, see Table 2-5.
The entry for an LS, one for each tape library, has the following options:
| Option | Description | |||
| TYPE | ||||
| CACHE_DIR | Specifies the directory in which the volume group stores chunks while merging them from sparse tapes. If you do not specify this parameter, DMF uses the value of TMP_DIR from the base object. | |||
| CACHE_SPACE | Specifies the amount of disk space (in bytes) that dmatls can use when merging chunks from sparse tapes. During merging, small chunks from sparse tapes are cached on disk before being written to a tape. The default is 0, which causes all files to be merged via sockets. | |||
| COMMAND | Specifies the binary file to execute to initiate the LS. This value must be dmatls. | |||
| DRIVE_GROUPS | Names one or more drive groups containing drives that the LS can use for mounting and unmounting volumes. They are configured as objects of type drivegroup. This parameter must be configured. There is no default. The order of the values specified for this parameter is integral to the determination of the MSP or volume group from which the DMF daemon attempts to recall an offline file. If the offline file has more than one copy, DMF uses a specific order when it attempts to recall the file. It searches for a good copy of the offline file in MSP or LS order, from the dmdaemon object's MSP_NAMES or LS_NAMES parameter. If one of those names refers to an LS, it searches for the copy in drive group order, from the LS object's DRIVE_GROUPS parameter. It then searches for the copy in volume group order from the drive group object's VOLUME_GROUPS parameter.
| |||
| MAX_CACHE_FILE | Specifies the largest chunk (in bytes) that will be merged using the merge disk cache. Larger files are transferred directly via a socket from the read child to the write child. The default is 25% of the CACHE_SPACE value. Valid values are 0 through the value of CACHE_SPACE . | |||
| MESSAGE_LEVEL | Specifies the highest message level number that will be written to the LS log, which includes messages from the LS's components. It must be an integer in the range 0-6; the higher the number, the more messages written to the log file. The default is 2. | |||
| RUN_TASK | ||||
| TASK_GROUPS | Names the task groups that contain tasks the LS should run. They are configured as objects of TYPE taskgroup. There is no default. | |||
| WATCHER | Names the resource watcher that the LS should run. They can be configured as objects of type resourcewatcher, but if the default parameters are acceptable, there is no need to do this. The default is no watcher. |
The entry for a drive group, one for each pool of interchangeable drives in a single library, has the following options:
| Option | Description | |||
| TYPE | ||||
| BLOCK_SIZE | Specifies the block size used when writing tapes from the beginning. The default depends upon the device, with DMF setting defaults as follows:
| |||
| DRIVE_MAXIMUM | Specifies the maximum number of drives within this drive group that the LS is allowed to attempt to use simultaneously. This can be more or less than the number of drives the LS can physically detect. The maximum is 100; the default is 100 for drive groups. If a negative value is specified for DRIVE_MAXIMUM, the drive group uses the sum of the number of available drives and DRIVE_MAXIMUM. | |||
| DRIVE_SCHEDULER | Names the resource scheduler that the drive group should run for the scheduling of tape drives. They are configured as objects of type resourcescheduler . The default is a resource scheduler of default type and parameters. For the defaults, see “Resource Scheduler Objects”. | |||
| DRIVES_TO_DOWN | Specifies an integer value that controls the number of "bad" drives the drive group is allowed to try to configure down. When more than this number are down, whether due to the drive group or to external influences such as the system administrator, the drive group does not attempt to disable any more. The default of 0 prevents the drive group from disabling any. | |||
| LABEL_TYPE | Specifies the label type used when writing tapes from the beginning. Possible values are:
The default is al. | |||
| MAX_MS_RESTARTS | Specifies the maximum number of times DMF can attempt to restart the mounting service (TMF or OpenVault) without requiring administrator intervention. The default and recommended values are 1 for TMF and 0 for OpenVault. | |||
| MOUNT_SERVICE | Specifies the mounting service to use. Possible values are openvault and tmf. The default is openvault. | |||
| MOUNT_SERVICE_GROUP | Specifies the name by which the drive group's devices are known to the mounting service. In the case of TMF, this is the device group name that would be used with the -g option on the tmmnt command. For OpenVault, this is the drive group name that is specified by the ov_drivegroup command. | |||
| MOUNT_TIMEOUT | Specifies the maximum number of minutes to wait for a tape to be mounted. Default is 0, which means forever. If a tape mount request waits for longer than this period of time, the drive group attempts to stop and restart the mount service, in an attempt to force the hanging subsystem to resume normal operation, or to fail solidly. Do not make this value too restrictive, as any non-LS tape activity (including xfsdump) can legitimately delay a volume group's tape mount, which could result in this timeout being exceeded. | |||
| MSG_DELAY | Specifies the number of seconds that all drives in the drive group can be down before an e-mail message is sent to the administrator and an error message is logged. The default is 0, which means that as soon as DMF notices that the mounting service is up and all of the drives are configured down, it will e-mail a message. | |||
| OV_ACCESS_MODES | Specifies a list of access mode names that control how data is written to tape. The default value is readwrite when migrating and readonly when recalling. This parameter is optional. | |||
| OV_INTERCHANGE_MODES (Open Vault MOUNT_SERVICE only) | Specifies a list of names to be provided to OpenVault for the firstmount clause when mounting a tape. Use compression to request compression. By default, this list is empty. | |||
| POSITIONING | Specifies how the tape should be positioned. The values can be:
The default depends on the type of drive, and is either direct or data. If data positioning is specified for a drive whose default is direct, the block ID is calculated by adding an estimate of the number of blocks from the start of the zone to the data being recalled and the block ID of the start of the zone. Not all drives use this format for block ID. | |||
| POSITION_RETRY | Specifies the level of retry in the event of a failure during zone positioning. The values can be:
If the volume group is unable to position to a zone, all recalls for files with data in that zone are aborted by the volume group (though not by DMF if a copy exists in another volume group). The default is lazy, to give the best overall recall time. If you are having trouble getting data from tape, you might want to try aggressive. | |||
| READ_IDLE_DELAY | Specifies the number of seconds an idle tape LS read child (dmatrc) can wait before being told to exit. If other DMF requests are waiting for a tape drive, the read child may be told to exit before READ_IDLE_DELAY seconds have passed. The default is 5 seconds. | |||
| REINSTATE_DRIVE_DELAY | Specifies the number of minutes after which a drive that was configured down by the drive group will be automatically reinstated and made available for use again. A value of 0 means it should be left disabled indefinitely. The default is 1440 (one day). | |||
| REINSTATE_VOLUME_DELAY | Specifies the number of minutes after which a volume that had its HLOCK flag set by DMF will be automatically reinstated and made available for use again. A value of 0 means they should be left disabled indefinitely. The default is 1440 (one day). | |||
| RUN_TASK | ||||
| TASK_GROUPS | Names the task groups that contain tasks the drive group should run. They are configured as objects of TYPE taskgroup. There is no default. | |||
| TMF_TMMNT_OPTIONS (TMF MOUNT_SERVICE only) | Specifies command options that should be added to the tmmnt command when mounting a tape. DMF uses the -Z option to tmmnt to ignore options controlling block size and label parameters. Use the BLOCK_SIZE and LABEL_TYPE drive group parameters instead. There is no need for a -g option here. If it is provided, it must match the value of the MOUNT_SERVICE_GROUP parameter. To request compression, use -i. Options that are ignored are -a, -b, -c, -D, -f, -F, -l, -L, -n, -o, -O, -p, -P, -q, -R, -t, -T, -U, -v, -V, -w, -x , and -X. | |||
| VERIFY_POSITION | Specifies whether the LS write child should (prior to writing) verify that the tape is correctly positioned and that the tape was properly terminated by the last use. The default is to verify. Specifying no or off turns verification off; anything else ensures verification. | |||
| VOLUME_GROUPS | Names the volume groups containing volumes that can be mounted on any of the drives within this drive group. They are configured as objects of type volumegroup. This parameter must be configured. There is no default. The order of the values specified for this parameter is integral to the determination of the MSP or volume group from which the DMF daemon attempts to recall an offline file. If the offline file has more than one copy, DMF uses a specific order when it attempts to recall the file. It searches for a good copy of the offline file in MSP or LS order, from the dmdaemon object's MSP_NAMES or LS_NAMES parameter. If one of those names refers to an LS, it searches for the copy in drive group order, from the LS object's DRIVE_GROUPS parameter. It then searches for the copy in volume group order from the drive group object's VOLUME_GROUPS parameter.
| |||
| WRITE_CHECKSUM | Specifies that tape block should be checksummed before writing. If a tape block has a checksum, it is verified when read. The default is on. |
The entry for a volume group, one for each pool of tape volumes of the same type, usable on the drives of the associated drive group, and which is capable of holding at most one copy of user files, has the following options:
| Option | Description | |
| TYPE | ||
| ALLOCATION_GROUP | Specifies the allocation group that serves as a source of additional volumes if a volume group runs out of media. Normally, one allocation group is configured to serve multiple volume groups. As a volume's hfree flag is cleared (see HFREE_TIME below) in a volume group, it is immediately returned to the allocation group subject to the restrictions imposed by the configuration parameters ALLOCATION_MAXIMUM and ALLOCATION_MINIMUM. The administrator must ensure that volumes in the allocation group are mountable on drives in the same drive group as any volume group that references the allocation group. It is an error to assign an ALLOCATION_GROUP name that is the same as an existing volume group name. The ALLOCATION_GROUP defines a logical pool of volumes rather than an actual operational volume group. As allocation groups have no configurable parameters, they have no configuration stanzas of their own; a reference to them in a volume group's ALLOCATION_GROUP parameter is all that is needed to activate them. A volume group that does not define the ALLOCATION_GROUP option will not use an allocation group. | |
| ALLOCATION_MAXIMUM | Specifies the maximum size in number of volumes to which a volume group can grow by borrowing volumes from its allocation group. The minimum value is 0, the maximum is infinity, and the default is infinity. If the volume group already contains ALLOCATION_MAXIMUM or more volumes, no additional volumes are borrowed from the allocation group. If no allocation group is defined, this parameter is meaningless. | |
| ALLOCATION_MINIMUM | Specifies the minimum size in number of volumes to which a volume group can shrink by returning volumes to its allocation group. The minimum value is 0, which is the default, and the maximum is the current value of ALLOCATION_MAXIMUM. If the volume group already contains ALLOCATION_MINIMUM or fewer volumes, no additional volumes are returned to the allocation group. If no allocation group is defined, this parameter is meaningless. | |
| DRIVE_MAXIMUM | Specifies the maximum number of drives within this drive group that this volume group is allowed to use simultaneously. The value actually used is the least of the drive group's DRIVE_MAXIMUM, this volume group's DRIVE_MAXIMUM and the number of drives the drive group can physically detect. The maximum is 100; the default is the drive group's DRIVE_MAXIMUM. | |
| HFREE_TIME | Specifies the minimum number of seconds that a tape no longer containing valid data must remain unused before the volume group overwrites it. The default value is 172,800 seconds (2 days), and the minimum allowed value is 0. When an LS removes all data from a tape, it sets the hfree (hold free tape) flag bit in the tape's volume (VOL) database entry to prevent that tape from being immediately reused. The next time the LS scans the database for volumes after HFREE_TIME seconds have passed, the LS clears the hfree flag, allowing the tape to be rewritten. If HFREE_TIME is set to 0, the LS will never clear hfree, so an unused tape will not be reused until you clear its hfree flag manually. For a description of how to set and clear the hfree flag manually, see the dmvoladm man page. | |
| MAX_CHUNK_SIZE | Specifies that the volume group should break up large files into chunks no larger than this value (specified in bytes) as it writes data to tape. If a file is larger than this size, it is broken up into pieces of the specified size, and, depending on other activity, more than one write child may be used to write the data to tape. If MAX_CHUNK_SIZE is 0 (the default), the volume group breaks a file into chunks only when an end of volume is reached. | |
| MAX_PUT_CHILDREN | Specifies the maximum number of write child (dmatwc) processes that will be simultaneously scheduled for the volume group. The maximum value is the value of DRIVE_MAXIMUM for the volume group's owning drive group. The minimum value is 1. The default is the same as the value that the volume group uses for DRIVE_MAXIMUM; if the value specified in the configuration file exceeds this default, the default is used. | |
| MERGE_CUTOFF | Specifies a limit at which the volume group will stop scheduling tapes for merging. This number refers to the sum of the active and queued children generated from gets, puts, and merges. The default value for this option is the value used by the volume group for DRIVE_MAXIMUM. This means that if sparse tapes are available, the volume group will create DRIVE_MAXIMUM number of children, thus using tape resources efficiently. However, if any recall requests arrive for that volume group, they will be started before new merges. Setting this number below DRIVE_MAXIMUM, in effect, reserves some tape units for recalls at the expense of merge efficiency. Setting this number above DRIVE_MAXIMUM increases the priority of merges relative to recalls. The minimum value that you can specify is 2. | |
| MIN_VOLUMES | Specifies the minimum number of unused volumes that can exist in the LS's volume database for this volume group without operator notification. If the number of unused volumes falls below MIN_VOLUMES, the operator is asked to add new volumes. The default is 10; the minimum is 0. If a volume group has an allocation group configured, MIN_VOLUMES is applied to the sum of the number of unused volumes in the volume group and in its allocation group subject to any ALLOCATION_MAXIMUM restrictions. | |
| PUTS_TIME | Specifies the minimum number of seconds a volume group waits after it has requested a drive for a write child before it tells a lower priority child to go away. The default is 3600 seconds. | |
| READ_TIME | Specifies the interval, in seconds, after which the volume group will evaluate whether a read child should be asked to go away (even if it is in the middle of recalling a file) so that a higher priority child can be started. If READ_TIME is 0, the volume group will not do this evaluation. The default is 0. | |
| RUN_TASK | ||
| TASK_GROUP | Names the task groups that contain tasks the volume group should run. They are configured as objects of TYPE taskgroup. There is no default. | |
| TIMEOUT_FLUSH | Specifies the number of minutes after which the volume group will flush files to tape. The default is 120 minutes. | |
| ZONE_SIZE | Specifies approximately how much data the write child should put in a zone. The write child adds files and chunks to a zone until the data written equals or exceeds this value, at which time it writes a tape mark and updates the database. Smaller values allow faster recalls and better recoverability but poorer write performance. The volume group also uses zone size to determine when to start write children. The default is 50 MB. |
The entry for a resource scheduler, one for each drive group in a single library, has the following options:
| Option | Description | |||
| TYPE | ||||
| ALGORITHM | Specifies the resource scheduling algorithm to be used. Two are currently supplied: a simple one called fifo, and a more flexible one called weighted_roundrobin (default).
| |||
| MODULE_PATH | Specifies the pathname of a Dynamic Shared Object (library of runtime-loadable routines) that contains an RSA whose name was specified by the ALGORITHM parameter. The default is to use the built-in RSAs. |
Other parameters are specific to a particular RSA. There are no parameters for fifo. For weighted_roundrobin , the following apply:
| Option | Description | ||
| PENALTY | Reduces the priority of requests from a volume group that is not the next one preferred by the round-robin algorithm. It is a multiplier in the range 0.0-1.0. Low values result in the urgency assigned by the volume group being totally or partially ignored, and high values mean that the urgency is more important than selecting one whose turn ought to be next. The default is 0.7. | ||
| WEIGHT | Assigns a weighting to one or more volume groups. The ratio of these weightings to each other (within the one drive group) determines the number of opportunities the volume group has to obtain drives when they are needed. The weightings are integers in the range 1-99, and need not be unique. For efficiency reasons, small numbers are preferred, especially if large numbers of volume groups are defined. Usually, there are multiple WEIGHT lines in the configuration, and a given volume group might appear on more than one of them. In such cases, the sum of the weights is used as the effective weight for that volume group. Any volume groups that do not appear on a WEIGHT line are assigned the default of 5. If there are no WEIGHT lines, all volume groups will use this default, resulting in a strict round-robin behavior. WEIGHT has the following format:
|
The entry for a resource watcher is needed only if you wish to change its default parameters; a reference to an resource watcher by the LS is sufficient to activate it. The resource watcher has the following options:
The following code example does not use all of the possible options for configuring an LS. It defines an LS containing a default resource watcher and one drive group, which in turn contains two volume groups sharing an allocation group, and a resource scheduler to give one volume group twice the priority than the other when competing for drives.
The volume group objects are slightly different, reflecting that the first one handles all of the recalls in normal circumstances as well as migrations, but the second is usually write-only.
define ls1
TYPE libraryserver
COMMAND dmatls
DRIVE_GROUPS dg1
CACHE_SPACE 500m
TASK_GROUPS ls_tasks
WATCHER rw
enddef
define dg1
TYPE drivegroup
VOLUME_GROUPS vg_prim vg_sec
MOUNT_SERVICE openvault
MOUNT_SERVICE_GROUP drives
OV_INTERCHANGE_MODES compression
DRIVE_SCHEDULER rs
DRIVES_TO_DOWN 2
REINSTATE_DRIVE_DELAY 60
enddef
define rs
TYPE resourcescheduler
WEIGHT 10 vg_prim
WEIGHT 5 vg_sec
enddef
define vg_prim
TYPE volumegroup
ALLOCATION_GROUP ag
enddef
define vg_sec
TYPE volumegroup
ALLOCATION_GROUP ag
DRIVE_MAXIMUM 2
enddef |
The steps in Procedure 2-11 explain pertinent information for configuring each of the LS objects in the previous example.
Procedure 2-11. Configuring an LS and Its Components
Ensure that define has a value that you set previously in the LS_NAMES or MSP_NAMES parameter of the daemon object. There is no default.
Ensure that TYPE is set to libraryserver . There is no default.
Ensure that COMMAND is set to dmatls. There is no default.
Specify a DRIVE_GROUPS parameter that names a collection of interchangeable tape drives. The assumption in this example is that there is only one such group. There is no default.
To tell the LS how much disk space it can use, set the CACHE_SPACE parameter. The LS can merge tapes more efficiently if it can stage most of the files to disk. Configure the CACHE_SPACE parameter to be at least twice the configured tape zone size. The default for CACHE_SPACE is 0, which causes all data to be transferred by sockets. For more information on tape zone sizes, see “Media Concepts” in Chapter 6.
Configure the TASK_GROUPS parameter to the names of the objects used to define how periodic maintenance tasks are completed. There is no default. For more information, see “Configuring Maintenance Tasks for the LS”.
To observe LS operation through a web browser, define a resource watcher. You need only a reference. Define an resource watcher object only if you want to change its default parameters.
Assuming that SPOOL_DIR was set in the base object to be /dmf/spool, the URL to use in this example is file://dmf/spool/ls/_rw/ls.html. Text files are generated in the same directory as the HTML files.
Define the drive group referenced in step 4. There is no COMMAND line; a drive group is not an independent program, but a component of an LS.
Define the volume groups using the drives managed by this drive group with the VOLUME_GROUPS parameter.
Specify the use of OpenVault. Because Open Vault is the default mounting service, this line can be omitted.
Specify the name that the mounting service uses to refer to this group of drives. When using OpenVault, the MOUNT_SERVICE_GROUP line specifies the OpenVault drive group to be used.
| Note: OpenVault uses the same term as does DMF to describe a group of interchangeable tape devices, but the two uses are separate. Their names need not match, though it may be less confusing if they do. |
If using TMF, the MOUNT_SERVICE_GROUP line names the TMF device group name.
Use the OV_INTERCHANGE_MODES and TMF_TMMNT_OPTIONS lines to specify that the drives (OpenVault and TMF, respectively) should be used in compression mode.
Override the default resource scheduler behavior by referring to an object called rs, to be defined later.
Allow the drive group to configure at most two drives down temporarily for 60 minutes for recovery from I/O errors if the drives are faulty and if doing so will result in a more reliable operation. When this happens, the administrator is e-mailed so that maintenance can be performed.
In the rs object, specify that when there are more requests for tape drives than there are drives in the drive group, volume group vg_prim is to be given access twice as often as vg_sec. The ratio of the numbers is important, but the exact values are not.
Define the volume groups. The VOLUME_GROUPS parameter of the drive group object and the SELECT_LS or SELECT_MSP lines in the filesystem objects refer to them.
Define a common allocation group called ag. allocation groups have no configurable parameters, so they have no defining object; just a reference is sufficient. Use of an allocation group is optional.
Include any other volume group parameters that you require. For example, one of the previous steps specified that the secondary volume group vg_sec can use, at most, two tape drives, so that other drives in this drive group are immediately available for use by vg_prim when it needs them.
This section describes the steps you must take to configure OpenVault for a drive group. You must execute OpenVault commands, create security key files, and edit the DMF configuration file.
Procedure 2-12. Configuring DMF to Use OpenVault
The following procedure describes how to make OpenVault and DMF work together. When using OpenVault 1.5 and later versions, you can use the ov_admin script to enable the DMF application. When using earlier versions of OpenVault, you can use the setup script. See the OpenVault Operator's and Administrator's Guide for a description of this script.
| Note: The procedure that follows assumes that before you complete the steps described, the OpenVault server is configured and all drives and libraries are configured and OpenVault is running. |
On the OpenVault server, add DMF as both a privileged and unprivileged OpenVault application for this host.
When using versions of OpenVault prior to 1.5, use the setup script, menu item 1, submenu 5.
When using OpenVault 1.5 or later versions, use the ov_admin script, and select the menu option that allows you to manage applications. Create the DMF application then activate both a privileged and an unprivileged instance of it.
The application name should be dmf (in lowercase). The instance name should be dmf@hostname where dmf is in lowercase, and hostname is the output of the command hostname -s. For example:
% hostname -s system1 |
In this case, dmf@system1 would be the instance name.
Add the DMF application as a valid user to appropriate OpenVault drive groups. The OpenVault drive groups that DMF uses must contain only fungible drives. That is, the drives in the OpenVault drive group must have identical characteristics and accessibility, so that any volume that can be mounted and written on one of the drives can also be mounted and read on any of the other drives within the group. Failure to provide identical mounting and accessibility characteristics to all drives in an OpenVault drive group used by an LS might result in tape mount failures.
When using OpenVault 1.4.x or earlier releases, it is preferable that you use the OpenVault setup script, menu item 2, submenu 7. When using OpenVault 1.5 or later, choose the appropriate item from the ov_admin menu. If for some reason you cannot use the setup or ov_admin script, you can enter the command manually, as follows:
ov_drivegroup -a drive_group -A dmf |
Add DMF as a valid application to appropriate cartridge groups.
For OpenVault versions prior to 1.5, it is preferable that you use the OpenVault setup script, menu item 2, submenu 8.
For OpenVault 1.5 and later, the ov_admin script allows you to specify the cartridge groups when the DMF application is created or, after creation of the DMF application, you can choose the menu option that allows you to manage cartridge groups.
If for some reason you cannot use the setup or the ov_admin script, you can enter the command manually, as follows:
ov_cartgroup -a tape_group -A dmf |
Configure the base object for use with OpenVault:
define base
TYPE base
HOME_DIR /dmf/home
.
.
.
OV_KEY_FILE /dmf/home/ovkeys
OV_SERVER hostname
enddef |
Configure the OV_KEY_FILE parameter name of the key file that holds security information for OpenVault. It is usually located in HOME_DIR and called ovkeys.
Configure the OV_SERVER parameter to the value returned by the hostname(1) command on the machine on which the OpenVault server is running. This parameter only applies when OpenVault is used as the mounting service. The default value is the host name of the machine on which you are running.
Use the dmov_keyfile(8) command to create the file defined by the OV_KEY_FILE parameter. This command will prompt you for the privileged and unprivileged keys that you defined in step 1.
Configure the LS's drive group object for use with OpenVault. In the drive group object, use the following steps:
Configure the MOUNT_SERVICE parameter to be openvault.
Configure the MOUNT_SERVICE_GROUP parameter to be the name of the OpenVault drive group, as seen in the output from the ov_stat -d command.
Configure the OV_ACCESS_MODES parameter to be a list of access mode names that control how the tape is used. The parameter is optional. The default value is readwrite when migrating and readonly when recalling. Use this parameter to force readwrite.
The other possible values that OpenVault can use are not configurable in DMF: for rewind/norewind, DMF uses rewind; for variable/ fixed, DMF uses variable.
Configure the OV_INTERCHANGE_MODES parameter to be a list of interchange mode names that control how data is written to tape. This can be used to control whether the device compresses data as it is written. This parameter is optional.
To specify that you want data compressed, use:
OV_INTERCHANGE_MODES compression |
To force all tapes to be written as DLT4000, use:
OV_INTERCHANGE_MODES DLT4000 |
This parameter is applied when a tape is first used or rewritten.
Make the appropriate cartridges accessible to the allocation groups, volume groups, or filesystem backup scripts by assigning the cartridges to the DMF application in OpenVault. To do this, you must know the following:
Cartridge type name. To determine the cartridge types allowed by a given drive, enter the following:
ov_stat -c -D drive | grep base |
The fourth column shown in the output is the cartridge type.
Cartridge group. To determine the possible cartridge groups, enter the following:
ov_cartgroup -s -A dmf |
If you already have tapes defined in your LS database, tell OpenVault about these tapes by entering one of the following:
dmov_makecarts -g cartgroup -t carttype lsname dmov_makecarts -g cartgroup -t carttype -v vg1, vg2 lsname dmov_makecarts -g cartgroup -t carttype taskgroupname |
You can replace any of the references to a volume group previously mentioned with an allocation group. If the -v parameter is omitted, all volume groups and allocation groups in the specified LS will be processed. Tapes will be added to the file controlling the run_full_dump.sh and run_partial_dump.sh scripts by specifying the name of the task group that refers to them.
If there are unmanaged cartridges in an OpenVault managed library, you can import the unmanaged cartridges, assign them to DMF, and add them to a database by entering one of the following:
dmov_loadtapes -l library -g cartgroup -t carttype vgname dmov_loadtapes -l library -g cartgroup -t carttype agname dmov_loadtapes -l library -g cartgroup -t carttype taskgroupname |
This command will invoke a vi(1) session. In the vi(1) session, delete any cartridges that you do not want added to the database. Tapes will be added to the file controlling the run_full_dump.sh and run_partial_dump.sh scripts by specifying the name of the task group which refers to them.
If neither of the above cases are appropriate, you can manually configure the cartridges. The following commands can be useful in this effort:
To list cartridges in a library, enter the following:
ov_stat -s -L library |
To list information on cartridges known to OpenVault, enter the following:
ov_lscarts -f '.*' |
To import cartridges into OpenVault and optionally assign them to DMF use the ov_import command.
To assign a cartridge known to OpenVault to an application, use the ov_vol command with the -n option.
Use one of the following dmvoladm(8) commands to add tapes to the LS databases:
dmvoladm -l lsname -c 'create vsn001-vsn010 vg vgname' dmvoladm -l lsname -c 'create vsn001-vsn010 vg agname' |
An allocation group is specified by the vg option, just like a volume group.
There is no special procedure to inform TMF of the tapes' existence. TMF assumes that every tape it deals with is in the library or can be provided by an operator, as needed.
You can configure parameters for how the LS daemon performs the following maintenance tasks:
For each of these tasks, you can configure when the task is run. For merging sparse tapes, you must provide more information such as what determines that a tape is sparse and how many tapes can be merged at one time.
| Note: The run_remove_journals.sh
and run_remove_logs.sh tasks are configured as part
of the daemon_tasks object, but these tasks also clear
the MSP/LS logs and journals. These tasks are described in “Configuring Daemon Maintenance Tasks”.
Table 2-1, provides a summary of automated maintenance tasks. |
The following example explains how to define the msp_tasks object. You can change the object name itself ( msp_tasks) to be any name you like. This example assumes the LS using this task has only one volume group. For information about tape merging when an LS has multiple volume groups, see Step 3.
Do not change the pathnames or task names.
You may comment out the RUN_TASK parameters for any tasks you do not want to run.
define msp_tasks
TYPE taskgroup
RUN_TASK $ADMINDIR/run_tape_report.sh at 00:10
#
RUN_TASK $ADMINDIR/run_tape_merge.sh on \
monday wednesday friday at 2:00
THRESHOLD 50
#VOLUME_LIMIT 20
#DATA_LIMIT 5g
#
RUN_TASK $ADMINDIR/run_merge_stop.sh at 5:00 |
Procedure 2-13. Configuring the msp_tasks Object
Define the object to have the same name that you provided for the TASK_GROUPS parameter of the LS object. In the example it is msp_tasks.
Ensure that TYPE is set to taskgroup . There is no default.
Configure the RUN_TASK parameters. DMF substitutes $ADMINDIR in the path with the /usr/lib/dmf directory. When the task is run, it is given the name of the object that requested the task as the first parameter and the name of the task group (in this case msp_tasks) as the second parameter. The task itself may use the dmconfig(8) command to obtain further parameters from either of these objects.
The RUN_TASK parameters require that you provide a time_expression.
The time_expression defines when a task should be done. It is a schedule expression that has the following form:
[every n period] [at hh:mm[:ss] ...] [on day ...] |
period is one of minute[s], hour[s], day[s], week[s], or month[s].
n is an integer.
day is a day of the month (1 through 31) or day of the week (sunday through saturday ).
The following are examples of valid time expressions:
at 2:00 every 5 minutes at 1:00 on tuesday |
The following steps specify the information you must provide for the tasks to run correctly:
The run_tape_report.sh and run_compact_tape_report.sh tasks generate a report on the tapes in the LS tape pool and on volume group activity. They are now superseded by the daemon task run_daily_report.sh .
The run_tape_merge.sh task merges sparse tapes. Specify the criteria that DMF uses to determine that a tape is sparse, as follows:
Use the THRESHOLD parameter to set an integer percentage of active data on a tape. DMF will consider a tape to be sparse when it has less than this percentage of data that is still active.
Use the VOLUME_LIMIT parameter to set the maximum number of tape volumes that can be selected for merging at one time.
Use the DATA_LIMIT parameter to set the maximum amount of data (in bytes) that should be selected for merging at one time.
For LSs, you can configure tape merging as part of the LS object's TASK_GROUPS parameter or as part of a RUN_TASK parameter in the volume group object. If it is configured as part of the LS's TASK_GROUPS parameter, volumes from any of the volume groups in that LS may be marked as sparse. This can lead to drive scheduling and cache usage conflicts. To avoid this problem, configure tape merging as part of the volume group object and ensure there is no overlap in the times that the various merge tasks run.
As this might become cumbersome when there are large numbers of volume groups configured, an alternative has been provided to run_tape_merge.sh, called run_merge_mgr.sh. This script establishes the needs of the volume groups for more tapes, using their MIN_VOLUMES parameters as a guide to expected requirements. The script processes the most urgent requests first, minimizing interference with the production workload. To use this script, perform the following steps:
Define a task group, which is referred to by the drive group object (not the volume group or LS object).
Specify a RUN_TASK parameter for run_merge_mgr.sh in the task group and (optionally) another for run_merge_stop.sh . You can also specify MESSAGE_LEVEL, THRESHOLD, VOLUME_LIMIT , and DATA_LIMIT parameters.
Ensure that the LS object that refers to this drive group has a resource watcher defined via the WATCHER parameter.
For each volume group, confirm that the value of its MIN_VOLUMES parameter is realistic.
Use the run_merge_stop.sh task to shut down volume merging (tape merging) at a time you specify by using a time_expression. This task is an alternative to using the VOLUME_LIMIT and DATA_LIMIT parameters to stop merging at specified points. In the example, the limit parameters are commented out because run_merge_stop.sh is used to control volume merging.
After you have added the LS information to the configuration file, use the dmvoladm(8) command with the -m option to create any missing directories with the proper labels and to create the volume (VOL) and catalog (CAT) records in the LS database.
You can follow the steps in Procedure 2-14, for all of the LSs you have defined.
| Caution: Each LS must have a unique set of volume serial numbers. |
Procedure 2-14. Creating LS Database Records
The following procedure is shown as an example that assumes you have an LS called ls1. This LS contains a volume group named vg_pri.
Enter the following command and it will respond as shown:
% dmvoladm -m ls1 dmvoladm: at rdm_open - created database libsrv_db adm: 1> |
The response is an informational message indicating that dmvoladm could not open an existing LS database, so it is creating a new and empty one. You should get this message the first time you use dmvoladm for an LS, but never again. The next line is the prompt for dmvoladm directives.
Assume that you will use 200 tapes with standard labels VA0001 through VA0200.
After the prompt, enter the following directive:
adm:1> create VA0001-VA0200 vg vg_pri |
| Note: You are specifying the volume group vg_pri for the tapes being added. It is also valid to specify an allocation group name instead of a volume group name. |
After entering this directive, you will receive 200 messages, one for each entry created, beginning with the following:
VSN VA0001 created. VSN VA0002 created. |
Use the following dmvoladm directive to list all of the tape VSNs in the newly created library:
adm:2> list all |
Issue the dmvoladm quit directive to complete setting up the LS.
adm:3> quit |
To enable a file transfer protocol (FTP) MSP, include a name for it on the MSP_NAMES or LS_NAMES parameter in the daemon object and define an msp object for it in the DMF configuration file.
DMF has the capability to use an FTP MSP to convert a non-DMF fileserver to DMF with a minimal amount of down time for the switch over, and at site-determined pace. Contact your customer service representative for information about technical assistance with fileserver conversion.
An FTP MSP object has the following options (defaults are provided here or in Procedure 2-16):
| Parameter | Description | |
| TYPE | ||
| CHILD_MAXIMUM | Specifies the maximum number of child processes the MSP is allowed to fork. The default is 4; the maximum is 100. | |
| COMMAND | Specifies the binary file to execute in order to initiate this MSP. For the FTP MSP, this value must be dmftpmsp. | |
| FTP_ACCOUNT | Specifies the account ID to use when migrating files to the remote system. | |
| FTP_COMMAND | Specifies additional commands to send to the remote system. There may be more than one instance of this parameter. | |
| FTP_DIRECTORY | ||
| FTP_HOST | Specifies the Internet host name of the remote machine on which files are to be stored. | |
| FTP_PASSWORD | Specifies the file containing the password to use when migrating files to the remote system. This file must be owned by root and be only accessible by root. | |
| FTP_PORT | Specifies the port number of the FTP server on the remote system. The default value is the value configured for ftp in the services file. | |
| FTP_USER | Specifies the user name to use when migrating files to the remote system. | |
| GUARANTEED_DELETES | Specifies the number of child processes that are guaranteed to be available for processing delete requests. If CHILD_MAXIMUM is nonzero, its value must be greater than the sum of GUARANTEED_DELETES and GUARANTEED_GETS. The default is 1. | |
| GUARANTEED_GETS | Specifies the number of child processes that are guaranteed to be available for processing dmget(1) requests. If CHILD_MAXIMUM is nonzero, its value must be greater than the sum of GUARANTEED_DELETES and GUARANTEED_GETS . The default is 1. | |
| IMPORT_DELETE | Specifies if the MSP should honor hard-delete requests from the DMF daemon. Legal values are:
This parameter applies only if IMPORT_ONLY is set to on. Set IMPORT_DELETE to on if you wish files to be deleted on the destination system when hard deletes are processed. | |
| IMPORT_ONLY | Specifies that the MSP is used for importing only. Set this parameter ON when the data is stored as a bit-for-bit copy of the file and needs to be available to DMF as part of a conversion. The MSP will not accept dmput(1) requests when this parameter is enabled. The MSP will, by default, ignore hard-delete requests when this parameter is enabled. When the DMF daemon recalls a file from an IMPORT_ONLY MSP, it makes the file a regular file rather than a dual-state file, and it soft-deletes the MSP's copy of the file. | |
| MESSAGE_LEVEL | Specifies the highest message level number that will be written to the MSP log. It must be an integer in the range 0-6; the higher the number, the more messages written to the log file. The default is 2. For more information on message levels, see “General Message Log File Format”. | |
| MVS_UNIT | Defines the storage device type on an MVS system. This must be specified when the destination is an MVS system. Valid values are 3330, 3350, 3380, and 3390. | |
| NAME_FORMAT | Specifies the strings that form a template to creates names for files stored on remote machines in the STORE_DIRECTORY. For a list of possible strings, see Table 2-3. The default is %u/%b (username/bfid ). This default works well if the remote machine runs an operating system based on UNIX. The default may not work at all if the remote machine runs an operating system that is not based on UNIX or if a given user has a large number of files. The date- and time-related strings allow sites with very large numbers of files to spread them over a large number of directories, to minimize subsequent access times. Using the %b specification will guarantee a unique filename. The NAME_FORMAT must include %b or %2, %3, %4 in some combination. The default size allotted to the NAME_FORMAT value in the daemon database base record is 34 bytes. This is large enough to accommodate the default for NAME_FORMAT if the user name is 8 or fewer characters (the %b value is always 24 characters). If you choose a set of strings that will evaluate to a field that is larger than 34 bytes, you may want to consider increasing the size of this record; see “Configuring Daemon Database Record Length”. | |
| TASK_GROUPS | Names the task groups that contain tasks the MSP should run. They are configured as objects of TYPE taskgroup. There is no default. | |
| WRITE_CHECKSUM | Specifies that the DMF MSP's copy of the file should be checksummed before writing. If the file has been checksummed, it is verified when read. The default is on. |
The MSP checks the DMF configuration file just before it starts child processes. If the DMF configuration file changed, it is reread.
If CHILD_MAXIMUM is nonzero, its value must be greater than the sum of GUARANTEED_DELETES and GUARANTEED_GETS.
The parameters COMMAND, FTP_HOST, FTP_USER, FTP_PASSWORD, and FTP_DIRECTORY must be present.
The MVS_UNIT parameter affects only IBM machines; they are further described in the dmf.conf(5) man page.
| Note: The MSP will not operate if the FTP_PASSWORD file is readable by anyone other than root. |
Table 2-3. NAME_FORMAT Strings
String | Evaluates To |
|---|---|
%1 | First 32 bits of the bit file identifier (BFID) in lowercase hexadecimal. This is always 8 pad characters ( 00000000). |
%2 | Second 32 bits of the BFID in lowercase hexadecimal. |
%3 | Third 32 bits of the BFID in lowercase hexadecimal. |
%4 | Fourth 32 bits of the BFID in lowercase hexadecimal. |
%b | BFID in hexadecimal (least significant 24 characters). This does not contain the 8 pad characters found in the 8 most significant characters of the full BFID. |
%u | User name of the file owner. |
%U | User ID of the file owner. |
%g | Group name of the file. |
%G | Group ID of the file. |
%% | Literal % character. |
%d | Current day of month (two characters). |
%H | Current hour (two characters). |
%m | Current month (two digits). |
%M | Current minute (two digits). |
%S | Current second (two digits). |
%y | Last two digits of the current year (such as 03 for 2003). |
|
|
The following example defines an FTP MSP:
define ftp
TYPE msp
COMMAND dmftpmsp
FTP_HOST fileserver
FTP_USER dmf
FTP_ACCOUNT dmf.disk
FTP_PASSWORD /dmf/ftp/password
FTP_DIRECTORY ftpmsp
FTP_COMMAND umask 022
enddef |
Procedure 2-15. Configuring the ftp Object
The following steps explain pertinent information for configuring an ftp object that uses a NAME_FORMAT of %u/%b:
Ensure that define has a value that you set previously in the MSP_NAMES or LS_NAMES parameter of the daemon object. There is no default.
Ensure that TYPE is set to msp . There is no default.
Ensure that COMMAND is set to dmftpmsp. There is no default.
Set the FTP_USER parameter to the user name to use on the remote FTP server during session initialization. There is no default.
Set the FTP_ACCOUNT parameter (if necessary) to the account to use on the remote FTP server during session initialization. Most FTP servers do not need account information. When account information is required, its nature and format will be dictated by the remote machine and will vary from operating system to operating system. There is no default.
Set the FTP_PASSWORD parameter to the name of the file containing the password to be used on the remote FTP server during session initialization. This file must be owned by root and only be accessible by root. In the example, the password for the user dmf on fileserver is stored in the file /dmf/ftp/password. There is no default.
Set the FTP_DIRECTORY parameter to the directory into which files will be placed on the remote FTP server. There is no default.
If necessary, specify commands to the remote machine's FTP daemon. In the example, the umask for files created is set to 022 (removes write permission for group and other). There is no default.
To enable a disk MSP, include a name for it on the MSP_NAMES or LS_NAMES parameter in the daemon object and define an msp object for it in the DMF configuration file.
As with the FTP MSP, you can use a disk MSP to convert a non-DMF fileserver to DMF with a minimal amount of down time for the switch over, and at a site-determined pace. Contact your customer service representative for information about technical assistance with fileserver conversion.
A disk MSP object has the following options:
| Parameter | Description | |
| TYPE | msp (required name for this type of object) | |
| CHILD_MAXIMUM | Specifies the maximum number of child processes the MSP is allowed to fork. The default is 4; the maximum is 100. | |
| COMMAND | Specifies the binary file to execute in order to initiate this MSP. For the disk MSP, this value must be dmdskmsp. | |
| DSK_BUFSIZE | Specifies the transfer size in bytes used when reading from and writing to files within the disk MSP's STORE_DIRECTORY. The value must be in the range 4096 through 16 million. The default is 131072 when writing, and 1000000 when reading.
| |
| GUARANTEED_DELETES | Specifies the number of child processes that are guaranteed to be available for processing delete requests. The default is 1. | |
| GUARANTEED_GETS | Specifies the number of child processes that are guaranteed to be available for processing dmget(1) requests. The default is 1. | |
| IMPORT_DELETE | Applies only if IMPORT_ONLY is set to on. Set IMPORT_DELETE to on if you wish files to be deleted in STORE_DIRECTORY when hard deletes are processed. Does not apply to DCM-mode. | |
| IMPORT_ONLY | Specifies the MSP is used for importing only. Set this parameter on when the data is stored as a bit-for-bit copy of the file and needs to be available to DMF as part of a conversion. The MSP will not accept dmput(1) requests when this parameter is enabled. By default, the MSP will ignore hard delete requests when this parameter is enabled. Does not apply to DCM-mode. | |
| MESSAGE_LEVEL | Specifies the highest message level number that will be written to the MSP log. It must be an integer in the range 0- 6; the higher the number, the more messages written to the log file. The default is 2. For more information on message levels, see “General Message Log File Format”. | |
| MIGRATION_LEVEL | Specifies the level of migration service for the DCM, as in filesystem objects. Valid values are none (no flushing to a lower volume group), user (only requests from dmmigrate(8) or a manually invoked dmdskfree (1) ), or auto (automated space management). The default is auto. (Applicable only to a DCM-mode MSP.) | |
| NAME_FORMAT | Specifies the strings that form a template to creates names for files stored on remote machines in the STORE_DIRECTORY. For a list of possible strings, see Table 2-3. The default is %u/%b (username/bfid ). This default works well if the remote machine runs an operating system based on UNIX. The default may not work at all if the remote machine runs an operating system that is not based on UNIX or if a given user has a large number of files. The date- and time-related strings allow sites with very large numbers of files to spread them over a large number of directories, to minimize subsequent access times. Using the %b specification will guarantee a unique filename. The NAME_FORMAT must include %b or %2, %3, %4 in some combination. The default size allotted to the NAME_FORMAT value in the daemon database base record is 34 bytes. This is large enough to accommodate the default for NAME_FORMAT if the user name is 8 or fewer characters (the %b value is always 24 characters). If you choose a set of strings that will evaluate to a field that is larger than 34 bytes, you may want to consider increasing the size of this record; see “Configuring Daemon Database Record Length”. | |
| POLICIES | For DCM disk MSP use only. See “Setting Up a Disk MSP in DCM Mode”. | |
| PRIORITY_PERIOD | Specifies the number of minutes after which a migrating file gets special treatment. Normally, if there is insufficient room in the STORE_DIRECTORY for a file, the DCM MSP will attempt to make room, while continuing to store files that will fit. If a file has not been stored into the STORE_DIRECTORY within PRIORITY_PERIOD, however, the DCM MSP will stop trying to store other files until either sufficient room has been made or it has determined that room cannot be made. This behavior may change in the future. The default value is 2 hours; the minimum is 1 minute, and the maximum value is 2000000. (Applicable only to DCM-mode disk MSPs.) | |
| STORE_DIRECTORY | ||
| TASK_GROUPS | Names the task groups that contain tasks the MSP should run. They are configured as objects of TYPE taskgroup. There is no default. | |
| WRITE_CHECKSUM | Specifies that the DMF MSP's copy of the file should be checksummed before writing. If the file has been checksummed, it is verified when read. The default is on. |
The following example describes setting up a disk MSP:
define dsk
TYPE msp
COMMAND dmdskmsp
CHILD_MAXIMUM 8
GUARANTEED_DELETES 3
GUARANTEED_GETS 3
STORE_DIRECTORY /remote/dir
enddef |
Procedure 2-16. Configuring the dsk Object
The following steps explain pertinent information for configuring the dsk object:
Ensure that define has a value that you set previously in the MSP_NAMES or LS_NAMES parameter of the daemon object. There is no default.
Ensure that TYPE is set to msp . There is no default.
Ensure that COMMAND is set to dmdskmsp. There is no default.
Set the CHILD_MAXIMUM parameter to the maximum number of child processes you want this MSP to be able to fork. The default is 4. The example allows 8.
Set the GUARANTEED_DELETES parameter to the number of child processes that are guaranteed to be available for processing delete requests. The default is 1. The example allows 3.
Set the GUARANTEED_GETS parameter to the number of child processes that are guaranteed to be available for processing dmget requests. The default is 1. The example allows 3.
Set the STORE_DIRECTORY to the directory where files will be stored. This parameter is required; there is no default. (In DCM-mode, the directory specified must be a dedicated XFS or CXFS filesystem; see “Setting Up a Disk MSP in DCM Mode”.)
To work with the DCM, the disk MSP requires the following:
The STORE_DIRECTORY field of the configuration stanza for the MSP must be the mount point of a dedicated XFS or CXFS filesystem mounted with DMAPI enabled. See “Filesystem Mount Options” for instructions.
The configuration stanza must contain at least one POLICIES parameter and the configuration stanza for that parameter must contain a SELECT_LOWER_VG parameter.
There must also be a task group that runs the run_dcm_admin script during off-peak hours to perform routine maintenance for the MSP.
In DCM mode, the BUFFERED_IO_SIZE, DIRECT_IO_SIZE, and MIN_DIRECT_SIZE have the following definitions:
| BUFFERED_IO_SIZE | Specifies the size of I/O requests for buffered I/O when migrating files downward in the hierarchy from the STORE_DIRECTORY of this disk MSP running in DCM mode. The legal range of values is 4096 through 16777216. The default is 262144. | |||
| DIRECT_IO_SIZE | Specifies the size of I/O requests for direct I/O when migrating files downward in the hierarchy from the STORE_DIRECTORY of this disk MSP running in DCM mode (see O_DIRECT in the open(2) man page for a description of direct I/O). The legal range of values is 65536 through 18446744073709551615. The default depends on the filesystem, but will not exceed the value of DIRECT_IO_MAXIMUM_SIZE defined in the base object. | |||
| MIN_DIRECT_SIZE | Determines whether direct or buffered I/O is used when migrating files downward in the hierarchy from the STORE_DIRECTORY of this disk MSP running in DCM mode (see O_DIRECT in the open(2) man page for a description of direct I/O). If the number of bytes to be read is smaller than the value specified, buffered I/O is used, otherwise direct I/O is used. The legal range of values is 0 (direct I/O is always used) through 18446744073709551615 (direct I/O is never used). The default is 0.
|
The default size allotted to the NAME_FORMAT value in the daemon database base record is 34 bytes. This is large enough to accommodate the default for NAME_FORMAT if the user name is 8 or fewer characters (the %b value is always 24 characters). If you choose a set of strings that will evaluate to a field that is larger than 34 bytes, you may want to consider increasing the size of this record; see “Configuring Daemon Database Record Length”.
When using DCM mode, dmdskmsp will no longer fail if the STORE_DIRECTORY is full. Instead, it will queue the requests and wait to fulfill them until after dmdskfree has freed the required space.
Following is a sample of the configuration stanzas with some explanatory notes below. Many of these parameters have defaults and can be omitted if they are appropriate.
define daemon
TYPE dmdaemon
LS_NAMES dcm_msp ls # [See note 1]
... # [See note 2]
enddef
define msp_policy
TYPE policy
SELECT_MSP dcm_msp copy2 when space > 4096 # [See note 3]
... # [See note 2]
enddef
define dcm_msp
TYPE msp
COMMAND dmdskmsp
STORE_DIRECTORY /dcm_cache # [See note 4]
CHILD_MAXIMUM 10 # [See note 5]
POLICIES dcm_policy
TASK_GROUPS dcm_tasks
enddef
define dcm_policy
TYPE policy # [See note 6]
FREE_SPACE_MINIMUM 10
FREE_SPACE_TARGET 70
DUALRESIDENCE_TARGET 90
FREE_SPACE_DECREMENT 1
FREE_DUALRESIDENT_FIRST on
CACHE_AGE_WEIGHT 1 .1
CACHE_SPACE_WEIGHT 1 .1
SELECT_LOWER_VG none when uid = 0
SELECT_LOWER_VG vg1 when space > 1G
SELECT_LOWER_VG vg2
enddef
define dcm_tasks
TYPE taskgroup
RUN_TASK $ADMINDIR/run_dcm_admin.sh at 22:00:10
enddef |
Notes:
The DCM must be specified before the LSs that contain its lower volume groups. (Otherwise, all recalls will attempt to come directly from tape.)
Other parameters essential to the use of this stanza but not relevant to DCM have been omitted.
The DCM and its lower volume groups should be considered to act as a single high-speed volume group logically maintaining only one copy of a migrated file. You should always have a second copy of all migrated files, which is the purpose of copy2 in this example. It would probably be a tape volume group, but could be any type of MSP other than a disk MSP in DCM mode.
The copy that resides in the DCM STORE_DIRECTORY is not to be considered a permanent copy of the file in terms of the safety of the file's data. It can be deleted at any time, though never before a copy of it exists in one of the SELECT_LOWER_VG volume groups.
A dedicated DMAPI-mounted filesystem
Any other parameters applicable to a disk MSP may also be used, with the exception of IMPORT_ONLY and IMPORT_DELETE.
Several parameters in DCM policies have functions that are analogous to those in standard disk MSP policies; see “DCM Policies”.
To verify the DMF configuration, run the dmcheck(8) script. This command checks the configuration file object and parameters, and reports on inconsistencies.
The DMF daemon database is created in HOME_DIR/daemon as dbrec.dat, dbrec.keys, pathseg.dat, and pathseg.keys. The database definition file (in the same directory) that describes these files and their record structure is named dmd_db.dbd. The database journal file is named dmd_db. yyyymmdd.[hhmmss]. It is created in the directory JOURNAL_DIR/daemon (JOURNAL_DIR is specified by the JOURNAL_DIR configuration parameter).
The inst(8) utility on IRIX systems and the rpm(8) utility on Linux systems set up system startup and shutdown scripts to start and stop DMF. You can start and stop the DMF daemon manually by executing the following:
/etc/init.d/dmf start /etc/init.d/dmf stop |
You could also use the the dmfdaemon(8) and dmdstop(8) commands, but this is not the recommended method.
The dmfdaemon, dmlockmgr, dmfsmon, MSP, and LS processes all create message files that are used to track various DMF events. These DMF message log files use the same general naming convention and message format. The message log file names are created using the extension . yyyymmdd, which represents the year, month, and day of log file creation.
Each line in a message log file begins with the time the message was issued, an optional message level, the process ID number, and the name of the program that issued the message.
The optional message level is described below. The remainder of the line contains informative or diagnostic information. The following sections provide details about each of these log files:
“Automated Space Management Log File” in Chapter 3 for information about dmfsmon and autolog.yyyymmdd
“Daemon Logs and Journals” in Chapter 4 for information about dmfdaemon and dmdlog.yyyymmdd
“dmlockmgr Communication and Log Files” in Chapter 5 for information about dmlockmgr and dmlocklog.yyyymmdd
“LS Logs” in Chapter 6 and “FTP MSP Activity Log” in Chapter 6 for information about dmatls, dmdskmsp, dmftpmsp, and msplog.yyyymmdd
Chapter 7, “DMF Maintenance and Recovery”, for information about log file maintenance
Messages in the dmdlog, dmlocklog , and msplog files contain a 2-character field immediately following the time field in each message that is issued. This feature helps to categorize the messages and can be used to extract error messages automatically from these logs. Because the only indication of DMF operational failure may be messages written to the DMF logs, recurring problems can go undetected if you do not check the logs daily.
Possible message types for autolog, dmdlog, msplog, and dmlocklog are defined in Table 2-4. The table also lists the corresponding message levels in the configuration file.
Table 2-4. DMF Log File Message Types
Field | Message type | Message level |
|---|---|---|
-E | Error | 0 |
-O | Ordinary | 0 |
-I | Informative | 1 |
-V | Verbose | 2 |
-1 | Debug level 1 | 3 |
-2 | Debug level 2 | 4 |
-3 | Debug level 3 | 5 |
-4 | Debug level 4 | 6 |
Table 2-5, lists the parameters that can be specified in the /etc/dmf/dmf.conf file and the objects to which they apply.
| Note: the most up-to-date list of parameters is in the dmf.conf(5) man page. |
Legend:
| BS: Base |
| DM: Daemon |
| DV: Device |
| DG: Device group |
| DP: Non-DCM Disk MSP |
| DC: DCM Disk MSP |
| FS: Filesystem |
| FP: FTP MSP |
| LS: Library server |
| PO: Policy |
| RS: Resource scheduler |
| RW: Resource watcher |
| TG: Task group |
| VG: Volume group |
Table 2-5. Parameters for the DMF Configuration File
Parameter | BS | DM | DV | DG | DP | DC | FS | FP | LS | PO | RS | RW | TG | VG | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ADMIN_EMAIL | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
AGE_WEIGHT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
ALGORITHM |
|
|
|
|
|
|
|
|
|
| X |
|
|
| |
ALLOCATION_GROUP |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
ALLOCATION_MAXIMUM |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
ALLOCATION_MINIMUM |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
BLOCK_SIZE |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
BUFFERED_IO_SIZE |
|
|
|
|
| X | X |
|
|
|
|
|
|
| |
CACHE_AGE_WEIGHT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
CACHE_DIR |
|
|
|
|
|
|
|
| X |
|
|
|
|
| |
CACHE_SPACE |
|
|
|
|
|
|
|
| X |
|
|
|
|
| |
CACHE_SPACE_WEIGHT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
CHILD_MAXIMUM |
|
|
|
| X | X |
| X |
|
|
|
|
|
| |
COMMAND |
|
|
|
| X | X |
| X | X |
|
|
|
|
| |
DATABASE_COPIES |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DATA_LIMIT |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DIRECT_IO_MAXIMUM_SIZE | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
DIRECT_IO_SIZE |
|
|
|
|
| X | X |
|
|
|
|
|
|
| |
DRIVES_TO_DOWN |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
DRIVE_GROUPS |
|
|
|
|
|
|
|
| X |
|
|
|
|
| |
DRIVE_MAXIMUM |
|
|
| X |
|
|
|
|
|
|
|
|
| X | |
DRIVE_SCHEDULER |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
DUALRESIDENCE_TARGET |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
DUMP_DATABASE_COPY |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_DEVICE |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_FILE_SYSTEMS |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_FLUSH_DCM_FIRST |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_INVENTORY_COPY |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_MAX_FILESPACE |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_MIGRATE_FIRST |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_RETENTION |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_TAPES |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_VSNS_USED |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
DUMP_XFSDUMP_PARAMS |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
ENABLE_KRC |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
EXPORT_QUEUE |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
FREE_DUALSTATE_FIRST |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
FREE_SPACE_DECREMENT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
FREE_SPACE_MINIMUM |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
FREE_SPACE_TARGET |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
FTP_ACCOUNT |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_COMMAND |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_DIRECTORY |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_HOST |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_PASSWORD |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_PORT |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
FTP_USER |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
GUARANTEED_DELETES |
|
|
|
| X | X |
| X |
|
|
|
|
|
| |
GUARANTEED_GETS |
|
|
|
| X | X |
| X |
|
|
|
|
|
| |
HFREE_TIME |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
HOME_DIR | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
HTML_REFRESH |
|
|
|
|
|
|
|
|
|
|
| X |
|
| |
IMPORT_DELETE |
|
|
|
| X |
|
| X |
|
|
|
|
|
| |
IMPORT_ONLY |
|
|
|
| X |
|
| X |
|
|
|
|
|
| |
JOURNAL_DIR | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
JOURNAL_RETENTION |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
JOURNAL_SIZE | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LABEL_TYPE |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
LICENSE_FILE | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LOG_RETENTION |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
LS_NAMES |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
MAX_CACHE_FILE |
|
|
|
|
|
|
|
| X |
|
|
|
|
| |
MAX_CHUNK_SIZE |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
MAX_MS_RESTARTS |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
MAX_PUT_CHILDREN |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
MAX_VIRTUAL_MEMORY |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
MERGE_CUTOFF |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
MESSAGE_LEVEL |
| X |
|
| X | X | X | X | X |
|
|
|
|
| |
MIGRATION_LEVEL |
| X |
|
|
| X | X |
|
|
|
|
|
|
| |
MIGRATION_TARGET |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
MIN_DIRECT_SIZE |
|
|
|
|
| X | X |
|
|
|
|
|
|
| |
MIN_VOLUMES |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
MODULE_PATH |
|
|
|
|
|
|
|
|
|
| X |
|
|
| |
MOUNT_SERVICE |
|
| X | X |
|
|
|
|
|
|
|
|
|
| |
MOUNT_SERVICE_GROUP |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
MOUNT_TIMEOUT |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
MOVE_FS |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
MSG_DELAY |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
MSP_NAMES |
| X |
|
|
|
|
|
|
|
|
|
|
|
| |
MVS_UNIT |
|
|
|
|
|
|
| X |
|
|
|
|
|
| |
NAME_FORMAT |
|
|
|
| X | X |
| X |
|
|
|
|
|
| |
OV_ACCESS_MODES |
|
| X | X |
|
|
|
|
|
|
|
|
|
| |
OV_INTERCHANGE_MODES |
|
| X | X |
|
|
|
|
|
|
|
|
|
| |
OV_KEY_FILE | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
OV_SERVER | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
PENALTY |
|
|
|
|
|
|
|
|
|
| X |
|
|
| |
POLICIES |
|
|
|
|
| X | X |
|
|
|
|
|
|
| |
POSITIONING |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
POSITION_RETRY |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
PUTS_TIME |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
READ_IDLE_DELAY |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
READ_TIME |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
REINSTATE_DRIVE_DELAY |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
REINSTATE_VOLUME_DELAY |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
RUN_TASK |
|
|
|
|
|
|
|
|
|
|
|
| X | * | |
SELECT_LOWER_VG |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
SELECT_MSP |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
SELECT_VG |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
SITE_SCRIPT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
SPACE_WEIGHT |
|
|
|
|
|
|
|
|
| X |
|
|
|
| |
SPOOL_DIR | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
STORE_DIRECTORY |
|
|
|
| X | X |
|
|
|
|
|
|
|
| |
TAPE_TYPE |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TASK_GROUPS |
| X |
| X | X | X | X | X | X |
|
|
|
| X | |
THRESHOLD |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
TIMEOUT_FLUSH |
|
|
|
|
|
|
|
|
|
|
|
|
| X | |
TMF_TMMNT_OPTIONS |
|
| X | X |
|
|
|
|
|
|
|
|
|
| |
TMP_DIR | X |
|
|
|
|
|
|
|
|
|
|
|
|
| |
VERIFY_POSITION |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
VOLUME_GROUPS |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
VOLUME_LIMIT |
|
|
|
|
|
|
|
|
|
|
|
| X |
| |
WATCHER |
|
|
|
|
|
|
|
| X |
|
|
|
|
| |
WEIGHT |
|
|
|
|
|
|
|
|
|
| X |
|
|
| |
WRITE_CHECKSUM |
|
|
| X |
|
|
|
|
|
|
|
|
|
| |
ZONE_SIZE |
|
|
|
|
|
|
|
|
|
|
|
|
| X |
* The run_tape_merge.sh and run_merge_stop.sh tasks and their associated parameters can be specified in the volume group object.