The DMF daemon, dmfdaemon(8), is the core component of DMF. The daemon exchanges messages between itself and commands, the MSPs and LSs, and the kernel. It also assigns bit-file identifiers (BFIDs) to migrated files and maintains the DMF database entries for offline copies.
When DMF is started, the daemon database is automatically initialized. To start the daemon manually, use the DMF startup script, as follows:
/etc/init.d/dmf start |
Typically, DMF should be initialized as part of the normal system startup procedure by using a direct call in a system startup script in the /etc/rc2.d directory.
The following sections provide additional information about the daemon database and daemon processing:
After initialization, dmfdaemon performs the following steps:
Isolates itself as a daemon process.
Checks for the existence of other dmfdaemon processes. If another dmfdaemon exists, the newer one terminates immediately.
Initializes the daemon log.
Opens the daemon database.
Initializes the daemon request socket.
Initiates the MSPs and LSs.
Enters its main request processing.
The daemon uses log files and journal files as described in “Daemon Logs and Journals”.
The main request processing section of the DMF daemon consists of the following sequence:
The select(2) system call, which is used to wait for requests or for a default time-out interval
A request dispatch switch to read and process requests detected by the select call
A time processor, which checks activities (such as displaying statistics and running the administrator tasks) done on a time-interval basis
This processing sequence is repeated until a stop request is received from the dmdstop(8) command. When a normal termination is received, the MSPs and LSs are terminated, the database is closed, and the logs are completed.
A typical request to the daemon starts with communication from the requester. The requester is either the kernel (over the DMF device interface) or a user-level request (from the command pipe). A user-level command can originate from the automated space-management commands or from an individual user.
After receipt, the command is dispatched to the appropriate command processor within the daemon. Usually, this processor must communicate with an MSP or LS before completing the specified request. The commands are queued within the daemon and are also queued to a specific group of database entries. All entries referring to the same file share the same BFID. The command is dormant until the reply from the MSP/LS is received or the MSP/LS terminates. When command processing is completed, a final reply is sent to the issuing process, if it still exists.
A final reply usually indicates that the command has completed or an error has occurred. Often, error responses require that you analyze the daemon log to obtain a full explanation of the error. An error response issued immediately usually results from an invalid or incorrect request (for example, a request to migrate a file that has no data blocks). A delayed error response usually indicates a database, daemon, MSP, or LS problem.
The DMF daemon maintains a database that resides in the directory HOME_DIR /daemon_name ( HOME_DIR is specified by the HOME_DIR configuration parameter). This database contains information about the offline copies of a given file, as well as some information about the original file. The database also contains the bit-file identifier (BFID), which is assigned when the file is first migrated.
Other information maintained on a per-entry basis includes the following:
File size (in bytes)
MSP or volume group name and recall path
Date and time information, including the following:
Time at which the database record was created
Time at which the database record was last updated
A check time for use by the administrator
A soft-delete time, indicating when the entry was soft-deleted
Original device and inode number
Base portion of the original file name, if known
The dmdadm(8) command provides maintenance services for the daemon database.
dmdadm executes directives from stdin or from the command line when you use the -c option. All directives start with a directive name followed by one or more parameters. Parameters may be positional or keyword-value pairs, depending on the command. White space separates the directive name, keywords, and values.
When you are inside the dmdadm interface (that is, when you see the adm command_number > prompt), the command has a 30-minute timeout associated with it. If you do not enter a response within 30 minutes of the prompt having been displayed, the dmdadm session terminates with a descriptive message. This behavior on all the database administrative commands limits the amount of time that an administrator can lock the daemon and MSP/LS databases from updates.
The dmdadm directives are as follows:
The syntax for the dmdadm directives is summarized as follows:
count selection [limit] create bfid settings delete selection [limit] dump selection [limit] help list selection [limit] [format] load filename quit (or q or exit) set format update selection [limit] to settings... |
The parameters have the following meanings:
The selection parameter specifies the records to be acted upon.
The limit parameter restricts the records acted upon.
The bfid parameter for the create directive specifies the bit-file-identifier (BFID) for the record being created.
The settings parameter for the create and update directives specifies one or more fields and their values.
The format parameter selects the way in which output is displayed. Any program or script that parses the output from this command should explicitly specify a format; otherwise the default is used, which may change from release to release.
The value for selection can be one of the following:
A BFID or range of BFIDs
The keyword all
A period (.), which recalls the previous selection
An expression involving any of the above, field value comparisons, and, or, or parentheses.
A field value comparison may use the following to compare a field keyword to an appropriate value:
| < (less than) |
| > (greater than) |
| = (equal to) |
| != (not equal to) |
| <= (less than or equal to) |
| >= (greater than or equal to) |
The syntax for selection is as follows:
selection ::= or-expr or-expr ::= and-expr [ or or-expr ] and-expr ::= nested-expr [ and or-expr ] nested-expr ::= comparison | ( or-expr ) comparison ::= bfid-range | field-keyword op field-value op ::= < | > | = | != | >= | <= bfid-range ::= bfid [ - bfid] | [bfid - [bfid]] | key-macro key-macro ::= all field-keyword ::= name or abbreviation of the record field field-value ::= appropriate value for the field bfid ::= character representation of the bfid |
Thus valid values for selection could be any of the following:
305c74b200000010-305c74b200000029 7fffffff000f4411- -305c74b2000004c8 all origsize>1m . and origage<7d |
The field parameter keywords listed below can be used as part of a selection parameter to select records. They can also be used in a settings parameter, as part of a keyword-value pair, to specify new values for a field, or in a format parameter. When specifying new values for fields, some of the field keywords are valid only if you also specify the -u (unsafe) option.
The time field keywords (checktime, deletetime, origtime, and updatetime ) have a value of either now or UNIX or Linux raw time (seconds since January 1, 1970). These keywords display their value as raw time. The value comparison > used with the date keywords means newer than the value given. For example, >36000 is newer than 10AM on January 1, 1970, and >852081200 is newer than 10AM on January 1, 1997.
The age field keywords (checkage, deleteage , origage, and updateage) let you express time as a string. They display their value as an integer followed by the following:
| w (weeks) |
| d (days) |
| h (hours) |
| m (minutes) |
| s (seconds) |
For example, 8w12d7h16m20s means 8 weeks, 12 days, 7 hours, 16 minutes, and 20 seconds old.
The comparison > used with the age keywords means older than the value given (that is, >5d is older than 5 days).
A limit parameter in a directive restricts the records acted upon. It consists of one of the following keywords followed by white space and then a value:
The format parameter selects a format to use for the display. If, for example, you want to display fields in a different order than the default or want to include fields that are not included in the default display, you specify them with the format parameter. The format parameter in a directive consists of one of the following:
format default
format keyword
format field-keywords
The format keyword form is intended for parsing by a program or script and therefore suppresses the headings.
The field-keywords may be delimited by colons or white space; white space requires the use of quotation marks.
 | Note: BFID is always included as the first field and need not be specified. |
For any field that takes a byte count, you may append the letter k, m, or g (in either uppercase or lowercase) to the integer to indicate that the value is to be multiplied by one thousand, one million, or one billion, respectively.
The following is sample output from the dmdadm list directive; recordlimit 20 specifies that you want to see only the first 20 records.
adm 3>list all recordlimit 20
BFID ORIG ORIG ORIG MSP MSP
UID SIZE AGE NAME KEY
------------------------------------------------------------------------
305c74b200000010 20934 69140480 537d silo1 88b49f
305c74b200000013 26444 279290 537d silo1 88b4a2
305c74b200000014 10634 67000 537d silo1 88b4a3
305c74b200000016 10634 284356608 537d silo1 88b4a5
305c74b200000018 10634 1986560 537d silo1 88b4a7
305c74b20000001b 26444 232681 537d silo1 88b4aa
305c74b20000001c 10015 7533688 537d silo1 88b4ab
305c74b200000022 8964 23194990 537d silo1 88b4b1
305c74b200000023 1294 133562368 537d silo1 88b4b2
305c74b200000024 10634 67000 537d silo1 88b4b3
305c74b200000025 10634 284356608 537d silo1 88b4b4
305c74b200000026 10634 1986560 537d silo1 88b4b5
305c74b200000027 1294 1114112 537d silo1 88b4b6
305c74b200000028 10634 25270 537d silo1 88b4b7
305c74b200000029 1294 65077248 537d silo1 88b4b8
305c74b20000002b 9244 2740120 537d silo1 88b4ba
305c74b200000064 9335 9272 537d silo1 88b4f3
305c74b200000065 9335 10154 537d silo1 88b4f4
305c74b200000066 9335 4624 537d silo1 88b4f5
305c74b200000067 9335 10155 537d silo1 88b4f6
adm 4> |
The following example displays the number of records in the database that are associated with user ID 11789 and that were updated during the last five days:
adm 3>count origuid=11789 and updateage<5d 72 records found. |
The text field order for daemon records generated by the dmdump(8), dmdumpj(8), and the dump directive in dmdadm is listed below. This is the format expected by the load directives in dmdadm:
To isolate the mspname and mspkey from the daemon records soft-deleted fewer than three days ago, use the following command:
dmdadm -c "dump deleteage<3d and deletetime>0" | awk "-F|" '(print $11,$12}' |
The DMF daemon uses log files to track various types of activity. Journal files are used to track DMF database transactions.
The ASCII log of daemon actions has the following format ( SPOOL_DIR refers to the directory specified by the SPOOL_DIR configuration parameter):
SPOOL_DIR/daemon_name/dmdlog.yyyymmdd |
The file naming convention is that yyyy, mm, and dd correspond to the date on which the log was created (representing year, month, and day, respectively). Logs are created automatically by the DMF daemon.
| Note: Because the DMF daemon will continue to create log files and journal files without limit, you must remove obsolete files periodically by configuring the run_remove_logs and run_remove_journals tasks in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2. |
The DMF daemon automatically creates journal files that track database transactions. They have the following pathname format (JOURNAL_DIR refers to the directory defined by the JOURNAL_DIR configuration parameter):
JOURNAL_DIR/daemon_name/dmd_db.yyyymmdd[.hhmmss] |
Existing journal files are closed and new ones created in two circumstances:
When the first transaction after midnight occurs
When the journal file reaches size defined by the JOURNAL_SIZE configuration parameter
When the first transaction after midnight occurs, the existing open journal file is closed, and the suffix .235959 is appended to the current file name no matter what the time (or date) of closing. The closed file represents the last (or only) transaction log of the date yyyymmdd. A new journal file with the current date is then created.
When the journal file reaches JOURNAL_SIZE, the file is closed and the suffix .hhmmss is added to the name; hh, mm, and ss represent the hour, minute, and second of file closing. A new journal file with the same date but no time is then created.
For example, the following shows the contents of a JOURNAL_DIR/daemon_name directory on 15 June 1998:
dmd_db.19980604.235959 dmd_db.19980612.235959 dmd_db.19980605.235959 dmd_db.19980613.145514 dmd_db.19980608.235959 dmd_db.19980613.214233 dmd_db.19980609.235959 dmd_db.19980613.235959 dmd_db.19980610.235959 dmd_db.19980614.235959 dmd_db.19980611.094745 dmd_db.19980615 dmd_db.19980611.101937 dmd_db.19980611.110429 dmd_db.19980611.235959 |
For every date on which database transactions occurred, there will exist a file with that date and the suffix .235959, with the exception of an existing open journal file. Some dates have additional files because the transaction log reached JOURNAL_SIZE at a specified time and the file was closed.
You can configure daemon_tasks parameters to remove old journal files (using the run_remove_journals.sh task and the JOURNAL_RETENTION parameter. For more information, see “Configuring Daemon Maintenance Tasks” in Chapter 2.
 | Warning: If a daemon database becomes corrupt, recovery consists of applying journals to a backup copy of the database. Database recovery procedures are described in “Database Recovery” in Chapter 7. |