A mass storage system which stores data and is connected to the dCache system. Each dCache pool will write files to it as soon as they have been completely written to the pool (if the pool is not configured as a LFS). The tertiary storage system is not part of dCache. However, it is possible to connect any mass storage system as tertiary storage system to dCache via a simple interface.

A tertiary storage system which stores data on magnetic tapes.

See tertiary storage system.

The type of HSM which is connected to dCache as a tertiary storage system. The choice of the HSM type influences the communication between dCache and the HSM. Currently there are osm and enstore. osm is used for most HSMs (TSM, HPSS, ...).

If a dCache instance does not have a tetiary storage system, it is not a cache but a large file store. There are two lfs modes: precious and transient mode.

Copying a file from a dCache pool to the tertiary storage system.

Copying a file from the tertiary strorage system to one of the dCache pools.

See to restore.

Any kind of transfer performed by a dCache pool. There are store, restore, pool to pool (client and server), read, and write transfers. The latter two are client transfers.

See Also mover.

The process/thread within a pool which performs a transfer.

See Also transfer.

The primary configuration file of a dCache hostis config/dCacheSetup. Each domain uses the file config/<domainName>Setup which is in fact a link to config/dCacheSetup. The config/dCacheSetup file might even be the same across the hosts of a dCache instance.

<PoolDomainName>.poollist File

(PP or P2P)

<DomainName>.batch File

One and the same file may be found on several pools of a dCache instance. While “file” usually denotes the abstract concept representing the data which makes up the file, we use the term “replica” to denote one specific copy on a dCache pool. Within one dCache instance a file is uniquely described by the pnfs ID. In contrast, a replica is uniquely specified by the pnfs ID and the pool name it is stored on.

The replica manager keeps track of the number of replicas of each file within a certain subset of pools and makes sure this number is always within a specified range. This way, the system makes sure that enough versions of each file are present and accessible at all times. This is especially useful to ensure resilience of the dCache system, even if the hardware is not reliable. The replica manager cannot be used when the system is connected to a tertiary storage system. The activation and configuration of the replica manager is described in Chapter 6, Resilience with the Replica Manager.

An SRM provides a standard webservice interface for managing a storage resouce (e.g. a dCache instance). It is possible to reserve space, retrieve or store files, and replicate files to another SRM. The actual transfer of data is not done via the SRM itself but via any protocol supported by both parties of the transfer. Authentication and authorisation is done with the grid security infrastructure. dCache comes with an implementation of an SRM which can turn any dCache instance into a grid storage element.

The pnfs companion is a database which stores the dCache specific information (cache info) which is normally stored within the pnfs namespace. Because this information is accessed very often by the pool manager, using the companion greatly improves the performance of the pool manager and the pnfs server.

Accounting information is either stored in a text file or in a PostgreSQL database by the billing cell usually started in the httpDomain domain. This is described in Chapter 23, Accounting.

The pool manager is the central component of a dCache system. It decides which pool is used for any kind of request...

Responsible for determining the cost for copying a file to a pool. The pool manager will choose the pool with the least cost.

Responsible for determining all pools allowable for a specific transaction. A detailed account of its configuration and behaviour is given in the section called “The Pool Selection Mechanism”.

A central service which can “pin” files to a pool for a certain time. It is used by the SRM to satisfy prestage requests.

A central service which can reserve space on pools for a certain time. It is used by the SRM to satisfy space reservation requests.

A pool in a dCache instance is responsible for storing data on disk. It is a cell which manages the space available in a subdirectory (specified in the poollist File) which is localizes on the host on which the pool cell is running.

The pool manager determines the pool used for storing a file by calculating a cost value for each available pool. The pool with the lowest cost is used. The costs are calculated by the cost module as described in . The total cost is a linear combination of the I.e.,

where ccf and scf are configurable with the command set pool decision.

See Also gl-cost.

See Also gl-cost.