A managed filesystem is an XFS or CXFS filesystem mounted with the Data Management Application Programming Interface (DMAPI) enabled and for which DMF software can migrate and/or recall migrated data. DMF software continuously monitors managed filesystems on high-performance disk so that it can maintain a certain amount of free space in those filesystems. This free space permits the creation of new files and the recall of previously migrated files. Figure 1-1 describes the concept of the DMF migration cycle between the managed filesystem and the secondary storage.

DMF software automatically detects a drop below the free-space threshold. DMF software then transparently moves file data from the managed filesystem to the secondary storage by freeing the data blocks of files that have already been migrated. File migration occurs in two stages:

For example, Figure 1-2 shows a configuration where DMF software will free the data blocks of less-recently accessed files (such as represented by the letter “A”) to empty the managed filesystem well below the threshold as new files are added or as previously migrated files (such as represented by the letters “B” and “E”) are recalled. Despite the movement of data, all content is accessible all of the time.

In general, only the most timely data resides on the higher-performance disk; DMF software automatically migrates less timely data to secondary storage. However, all of the data always appears to be online to users and applications using normal access methods, regardless of the data's actual location.

Although DMF software moves file data, it leaves file metadata in place so that users can access files without knowing the actual location of the data. Metadata consists of items such as index nodes (inodes) and directory structure. Migrated files appear as normal files to users and are always easily accessible via high-performance network connections.

Because migrated files remain cataloged in their original directories, users and applications never need to know where the data actually resides; they can access any migrated file using normal processes. In fact, when drilling into directories or listing their contents using standard POSIX-compliant commands, a user cannot determine the location of file data within the storage tier; determining the data's actual residence requires special commands or command options.

A file whose data blocks have been freed is considered from the DMF software perspective to be offline and its data blocks are therefore available for new active data, either new files or recalled files. However, from the user perspective , the file always appears to be online because the inodes and directories remain in the managed filesystem, allowing users to access the file by normal means.

The only difference users might notice when accessing a file whose data blocks have been freed is a delay in response time, because the data must be retrieved from secondary storage. From the user's perspective, all data always appears to be available online, regardless of its actual location.

Managed files can have multiple distinct file regions with different residency states. A region is a contiguous range of bytes that have the same residency state. A file that has more than one region is called a partial-state file. A file that is in a static state (that is, not currently being migrated or unmigrated) can have one region that is online in the managed filesystem for immediate access and another region that is offline and must be recalled in order to be accessed.

Partial-state files provide the following capabilities:

For additional details, see:

DMF software transports large volumes of data on behalf of many users and has evolved to satisfy customer requirements for scalability and the safety of data:

As a DMF administrator, you determine how disk space capacity is handled by doing the following:

DMF software selects files for migration and frees data blocks of already migrated files based on site-defined criteria that are specified in a migration policy. For example, a migration policy does the following:

DMF software can migrate data to the following media:

You can also use disk or COPAN RAID sets as a cache in conjunction with another migration target to provide multiple levels of migration; see “Multiple Storage Tiers”.

DMF software supports a range of storage-management applications. In some environments, DMF software is used strictly to manage highly stressed online disk resources. In other environments, it is also used as an organizational tool for safely managing large amounts of data. In all environments, DMF software scales to the storage application and to the characteristics of the available storage devices.

DMF software interoperates with the following:

By combining these services with DMF software, you can configure an SGI system as a high-performance fileserver.

DMF software provides a set of graphical and command-line tools to help you configure, monitor, and manage the DMF system. DMF Manager is a web-based tool you can use to do the following:

For details, see:

Also see:

DMF Manager is useful for all DMF customers from enterprise to high-performance computing and is available via the Firefox® and Internet Explorer® web browsers.

At a glance, you can see if the DMF environment is operating properly. An icon in the upper-right corner indicates if the DMF environment is up (green) or down (upside down and red). If something requires, DMF Manager makes actions available to identify and resolve problems. The tool volunteers information and provides context-sensitive online help. DMF Manager also displays performance statistics, allowing you to monitor DMF activity, filesystems, and hardware.

Figure 1-3 is an example of the Overview panel. It shows status of the DMF environment, including the following:

This section discusses the following:

You can run DMF software in a high-availability (HA) cluster.

DMF software provides access to a subset of the DMF client functions via the DMF Simple Object Access Protocol (SOAP) web service. For more information, see Chapter 16, “DMF SOAP Server”.

You can use the direct archiving feature to manually copy file data between a POSIX filesystem (such as a Lustre™ filesystem) directly to DMF secondary storage by configuring the POSIX filesystem for archive use in the DMF configuration file and using the dmarchive(1) command. The POSIX filesystem cannot be DMAPI-enabled (that is, it cannot be mounted with the dmi mount option) and is known as an archive filesystem. When using this feature, DMF software copies the file data to DMF secondary storage while placing the metadata in a filesystem that is managed by DMF. See “Use dmarchive to Copy Archive File Data to Secondary Storage” in Chapter 3.

When you purchase DMF software, you also receive the following mounting services:

When OpenVault is the mounting service, DMF software will try to retrieve data from an in-library volume before requesting that an out-of-library tape be imported. See “Using Out-of-Library Tapes” in Chapter 5.

DMF software uses the following terminology with regard to the state of a file in a managed filesystem:

When a file is first migrated, DMF software copies the data to secondary storage but may not immediately free the data in the managed filesystem on the high-performance disk. During this period, the file is considered to be dual-state because it resides in both locations. Like a regular file, a migrated file has an inode. An offline file or a partial-state file requires the intervention of the DMF daemon to access its offline data; a dual-state file is accessed directly from the original that still exists in the managed filesystem.

The operating system informs the DMF daemon when a migrated file is modified. If anything is written to a migrated file, the offline copy is no longer valid, and the file becomes a regular file until it is migrated again.

If you are using DMF direct archiving to copy files from a filesystem that is not managed, archiving files are files where the original resides on an archive filesystem (one not managed by DMF software, such as Lustre) and whose offline copies are in progress. When the process completes, the files are offline files.

The migration process is managed by a daemon-like component called a library server (LS) or media-specific process (MSP):

A site can use any combination of DMF methods.

Figure 1-4 and Figure 1-5 summarize these concepts and “Multiple Storage Tiers” provides more details and illustrations.

The various DMF methods provide multiple storage tiers:

The figures in the following subsections show the use of multiple tiers and the concepts of DMF data migration (in which file data is copied from the managed filesystem to the secondary storage, but the inode remains in place in the managed filesystem) and data recall.

You choose both the percentage of the filesystem to migrate and the amount of free space. You as the administrator can manually trigger file migration or file owners can issue manual migration requests.

A file is migrated when the automated space-management controller dmfsfree(8) selects the file or when an owner requests that the file be migrated by using the dmput(1) command.

When the daemon receives a request to migrate a file, it does the following:

When the MSPs/VGs have completed the offline copies, the daemon marks the file as migrated in its database and changes the file to dual-state. If the user specifies the dmput -r option, or if dmfsfree requests that the file's space be released, the daemon releases the data blocks and changes the file state to offline. For more information, see the dmput(1) man page.

This section discusses the following:

This section discusses the following:

The DMF server always provides the following services:

The individual processes that migrate and recall data are known as data-mover processes. Nodes that run data-mover processes are data movers; this may include the DMF server node if it is configured to use the integrated data-mover functionality and, if you have purchased the Parallel Data-Mover Option, the parallel data-mover nodes. The DMF server and the parallel data-mover nodes can each run multiple data-mover processes.

As shown in Figure 1-13, the basic DMF product (that is, without the Parallel Data-Mover Option) runs data-mover processes on the DMF server. This allows the DMF control system to reside on a single server and minimizes the cost of a DMF implementation. Additional nodes can be installed with DMF client software (see “DMF Control from Client Platforms”).

Figure 1-14 shows the DMF product in a CXFS clustered filesystem environment.

For users with higher throughput requirements, Parallel DMF allows additional data movers to operate in parallel with the integrated data-mover functionality on the DMF server, increasing data throughput and enhancing resiliency.

The parallel data-mover node's dedicated function is to move data from the managed filesystem to volume-based media (COPAN MAID, COPAN VTL, JBFS configurations, or tape) back into the managed filesystem, using an LS. Offloading the majority of I/O from the integrated data-mover functionality on the DMF server improves I/O throughput performance.

Because multiple parallel data-mover nodes can be used to move data, DMF software can scale its I/O throughput capabilities. When one parallel data-mover node hits its peak throughput capabilities, you can add more parallel data-mover nodes to the configuration as needed to improve I/O performance. Each parallel data-mover node can improve overall DMF performance by up to its maximum performance. For example, if you have parallel data-mover nodes that each provide up to a 2-GB/s increase, then having a configuration with three of these parallel data-mover nodes would provide a net increase of up to 6 GB/s. Additional drives and filesystem bandwidth may be required to realize the benefit from additional parallel data-mover nodes.

The basic DMF product can run in an environment with or without CXFS. If DMF software is managing a CXFS filesystem, DMF software will ensure that the filesystem's CXFS metadata server is on the same machine as the DMF server and will use metadata server relocation if necessary to achieve that configuration (see “Configure DMF Appropriately with CXFS™” in Chapter 3). Parallel DMF must always run in a CXFS environment. The parallel data-mover nodes are SGI x86_64 machines that are installed with the SGI DMF Parallel Data Mover software package, which includes the required underlying CXFS software.

The parallel data-mover node has specific hardware requirements and must access volume-based media on a port that is not used by CXFS. See “SAN Switch Zoning or Separate SAN Fabric Requirement”.

If you choose the Parallel DMF, you must use OpenVault for those drive groups (DGs) that contain drives on parallel data-mover nodes.

Figure 1-15 shows the concept of the DMF product using parallel data-mover nodes in a CXFS cluster with only one server-capable administration node. The parallel data-mover nodes only write data to secondary storage on volume-based media in an LS.

In a configuration with Parallel DMF, the DMF server still provides the services listed in “DMF Server Functions”.

For more information, see Chapter 8, “Parallel DMF Configuration”.

The DMF daemon keeps track of migrated files in the daemon database. The key to each file is its bit-file identifier (BFID). For each migrated file, the daemon assigns a BFID that is stored in the file's inode. There is a daemon database record for each copy of a migrated file.

The daemon database also contains information such as the following:

When you use an MSP, the daemon database contains all of the information required to track a migrated file.

If you use an LS, there is also the LS database, which contains two tables of records:

Detailed information about the daemon and LS databases and their associated utilities is provided in “CAT Records” in Chapter 14 and “VOL Records” in Chapter 14.

There are also databases for DMF Manager performance records and alerts.

For information about the OpenVault database, see OpenVault Administrator Guide for SGI InfiniteStorage.

DMF software provides capabilities to ensure the integrity of offline data. For example, you can have multiple MSPs/VGs with each managing its own pool of volumes. Therefore, you can configure the DMF environment to copy filesystem data to multiple offline locations.

DMF software stores data that originates in a CXFS or XFS filesystem. Each object stored corresponds to a file in the native filesystem. When a user deletes a file, the inode for that file is removed from the filesystem. Deleting a file that has been migrated begins the process of invalidating the offline image of that file. In the LS, this eventually creates a gap in the volume. To ensure effective use of media, the LS provides a mechanism for reclaiming space lost to invalid data. This process is called volume merging.

Much of the work done by DMF software involves transaction processing that is recorded in databases. The DMF databases provide for full transaction journaling and employ two-phase commit technology. The combination of these two features ensures that DMF software applies only whole transactions to its databases. Additionally, in the event of an unscheduled system interrupt, it is always possible to replay the database journals in order to restore consistency between the DMF databases and the filesystem. DMF utilities also allow you to verify the general integrity of the DMF databases themselves. See “Administration Tasks” for more information.

DMF software consists of the DMF daemon and one or more MSPs or LSs. The DMF daemon accepts requests to migrate filesystem data from the DMF administrator or from users. It also communicates with the operating system kernel to maintain a file's migration state in that file's inode.

The DMF daemon is responsible for dispensing a unique bit-file identifier (BFID) for each file that is migrated. The daemon also determines the destination of migration data and forms requests to the appropriate MSP/LS to make offline copies.

The MSP/LS accepts requests from the DMF daemon. For outbound data, the LS accrues requests until the amount of data justifies a volume mount. Requests for data retrieval are satisfied as they arrive. When multiple retrieval requests involve the same volume, all file data is retrieved in a single pass across the volume.

DMF software uses the DMAPI kernel interface defined by the Data Management Interface Group (DMIG). DMAPI is also supported by X/Open, where it is known as the XDSM standard.

Figure 1-16 illustrates the basic DMF architecture. Figure 1-17 shows the architecture of the LS.

There is one LS process (dmatls) per library, which maintains a database that all of its components share. The entities in the shaded boxes in Figure 1-17 are internal components of the dmatls process. Their functions are as follows:

The dmatrc and dmatwc processes are called the read children and write children. They are created by VGs to perform the actual reading and writing of volumes. Unlike most of the other DMF processes that run indefinitely, these processes are created as needed, and are terminated when their specific work has been completed.

Media transports and robotic automounters are also key components of all DMF installations. Generally, DMF software can be used with any transport and automounter that is supported by either OpenVault or TMF. Additionally, DMF software supports absolute block positioning , a media transport capability that allows rapid positioning to an absolute block address on the volume. When this capability is provided by the transport, positioning speed is often three times faster than that obtained when reading the volume to the specified position.

A migrate group (MG) is a logical collection of MSPs and VGs that you combine into a set in order to have a single destination for a migrate request. A migration request to the MG will result in the copying of the file to exactly one MSP/VG that is a member of the MG.

You define an MG by adding the migrategroup object to the DMF configuration file. You can use the defined name of the MG in DMF policies and commands, similar to the way in which you use the names of VGs/MSPs. See:

The capacity of the DMF environment is measured in several ways, as follows:

DMF software has evolved in production-oriented, customer environments. It is designed to make full use of parallel and asynchronous operations, and to consume minimal system overhead while it executes, even in busy environments in which files are constantly moving online or offline. Exceptions to this rule will occasionally occur during infrequent maintenance operations when a full scan of filesystems or databases is performed.

For information about the DMF capacity license, see Chapter 2, “DMF Licensing”.

The DMF server uses the DMF administrative and store directories to store its databases, log files, journal files, and temporary files. Table 1-1 summaries the configuration parameters used to define these directories, the variable that represents the value of the parameter in this guide, and the purpose of the directories. For configuration details, see Chapter 7, “DMF Configuration File”.

For more information about DMF administrative directories, see “DMF Administrative and Store Directories”.

The PostgreSQL database is required by DMF for various purposes, including the queue-viewing tools:

For configuration parameters specific to Postgres, see “base Object Parameters” in Chapter 7.

For more information about DMF administrative directories, see “DMF Administrative and Store Directories”.

A DMF server node requires the following:

DMF parallel data-mover nodes require the following:

If you use Parallel DMF, you must use OpenVault for those DGs that contain drives on parallel data-mover nodes. See “Parallel DMF Overview”.

OpenVault requires ksh, not pdksh.

TMF has no requirements specific to DMF software.

DMF software is licensed. See Chapter 2, “DMF Licensing”.

For filesystems to be managed by DMF software, they must be mounted with the DMAPI interface enabled. See “Install DMAPI” in Chapter 3.

Drives must be visible only from the active DMF server, the passive DMF server (if applicable), and the parallel data-mover nodes. The drives must not be visible to any other nodes. You must use one of the following:

DMF software requires independent paths to drives so that they are not fenced by CXFS. The ports for the drive paths on the switch must be masked from fencing in a CXFS configuration.

XVM must not fail over CXFS filesystem I/O to the paths visible through the tape/disk HBA ports when Fibre Channel port fencing occurs.

DMF Manager has the following requirements:

To use the DMF SOAP service capability, the software must be installed on the DMF server node.

DMF direct archiving has the following requirements:

If a filesystem does not meet these requirements, do not add it to the DMF configuration file as an archive filesystem.

The fast-mount cache feature requires the following at a minimum:

However, SGI always recommends that you migrate at least two copies to secondary-storage targets in order to prevent file data loss in the event that a migrated copy is damaged. When using a fast-mount cache, SGI therefore recommends that you migrate at least three copies (one to the cache and two to secondary-storage targets).

See “Use Fast-Mount Cache Appropriately” in Chapter 3.

DMF software supports the following cloud systems as secondary storage:

SGI strongly recommends that you migrate at least two copies to secondary-storage targets in order to prevent file data loss in the event that a migrated copy is damaged. A given cloud can be a single point of failure, therefore redundant copies within one cloud do not sufficiently protect against data loss. SGI therefore highly recommends that you migrate data to a second location (to another cloud instance, tape, or disk).

See Arcitecta's Mediaflux documentation for information about using DMF in a Mediaflux environment. In particular, there are certain requirements for configuring DMF and for using dmaudit(8) when restoring files in a managed filesystem.

DMF software manages two primary resources:

You can configure those resources in a variety of environments, including the following:

You must do the following:

You will install the DMF server software (which includes the software for TMF and OpenVault) from the ISSP media.

To configure the DMF environment, you must define a set of parameters in the DMF configuration file, typically by using a sample file as a starting point. See:

To make site-specific modifications, see “Customizing DMF” in Chapter 5.

For a detailed example of configuring using COPAN cabinets, see:

DMF software requires that you perform recurring administrative duties in the following areas:

The DMF administrator has access to a wide variety of commands for controlling the DMF environment. This section discusses the following:

The FTP MSP uses no special commands, utilities, or databases.