Space Manager is making reservations agains space in
LinkGroups, LinkGroup is an object created by the
PoolManager, that consists of several Links. The total
space available in the given LinkGroup is a sum of available
spaces in all links. The available space in each link is a sum
of the available spaces in all pools assinged to a given
link. Therefore for the space reservation to work correctly it
is essential that each pool belongs to one and only one link,
and each link belongs to only one LinkGroup. LinkGroups are
assigned several parameters that determine what kind of space
the LinkGroup correspond to and who can make reservation
against this space.
To configure PoolManager to create the new LinkGroup (a new
reservable entity in dCache), please use following example
(given in the PoolManager). Here we assume that write-link
link already exists:
(PoolManager) admin >psu create linkGroup write-link-group(PoolManager) admin >psu addto linkGroup write-link-group write-link
To tell Space Manager if the LinkGroup will be able to store files with given AccessLatency and RetentionPolicy, LinkGroups have 5 attributes: custodialAllowed, outputAllowed, replicaAllowed, onlineAllowed and nearlineAllowed. These attributes can be specified with the following commands:
(PoolManager) admin >psu set linkGroup custodialAllowed <group name> <true|false>(PoolManager) admin >psu set linkGroup outputAllowed <group name> <true|false>(PoolManager) admin >psu set linkGroup replicaAllowed <group name> <true|false>(PoolManager) admin >psu set linkGroup onlineAllowed <group name> <true|false>(PoolManager) admin >psu set linkGroup nearlineAllowed <group name> <true|false>
Please note that that it is up to administrators that the link groups attributes are specified correctly. For example dcache will not complain if the linkGroup that does not support tape backend will be declared as one that supports custodial.
In order to enable the new space reservation: add (uncomment)
the following definition in dCacheSetup
srmSpaceManagerEnabled=yes
If space reservation request does not specify retention
policy we will assign
SpaceManagerDefaultRetentionPolicy
retention policy by default.
Possible values are REPLICA,
OUTPUT and CUSTODIAL.
Usage example:
SpaceManagerDefaultRetentionPolicy=CUSTODIAL
If space reservation request does not specify access latency
we will assign
SpaceManagerDefaultAccessLatency this
access latency by default.
Possible values are ONLINE and
NEARLINE.
Usage example:
SpaceManagerDefaultAccessLatency=NEARLINE
If
SpaceManagerReserveSpaceForNonSRMTransfers
is set to true, and if the transfer
request come from the door, and there was not prior space
reservation made for this file, Space Manager will try to
reserve space before satisfying the request.
Possible values are true and
false.
Usage example:
SpaceManagerReserveSpaceForNonSRMTransfers=false
SpaceManagerLinkGroupAuthorizationFileName
specifies a file that contains the list of FQANs that are
allowed to make space reservations in a given link
group. The file syntax is described in the next section.
This parameter is not set by default.
Usage example:
SpaceManagerLinkGroupAuthorizationFileName=/opt/d-cache/etc/LinkGroupAuthorization.conf
As it was described in the section called “Introduction”,
dCache can perform implicit space reservations for SRM
Version 1 data transfers and for SRM Version 2.2 data
transfers that are not given the space token explicitly. The
parameter that enables this behavior is
srmImplicitSpaceManagerEnabled, which is
described in the section called “SRM configuration for experts”. In case
of SRM version 1.1 data transfers, when the Access Latency
and Retention Policy cannot be specified, and in case of SRM
V2.2 clients, when Access Latency and Retention Policy are not
specified, the default values will be used. First SRM will
attempt to use the values of AccessLatency
and RetentionPolicy tags from the directory
to which a file is being written. If the tags are present,
then the Access Latency and Retention Policy will be set on
basis of the system wide defaults, which are controlled by
SpaceManagerDefaultRetentionPolicy and
SpaceManagerDefaultAccessLatency variables
in dCacheSetup; these variable are described in details in the
previous section "SRM Space Manager Parameters in
dCacheSetup".
If you have a direct access to the namespace, you can check if the AccessLatency and RetentionPolicy tags are present by using the following commands:
[root] #cd <pnfsDir>[root] #cat ".(tags)()".(tag)(OSMTemplate) .(tag)(file_family) .(tag)(storage_group) .(tag)(AccessLatency) .(tag)(RetentionPolicy)
If the output contains the lines saying
(tag)(AccessLatency) and
.(tag)(RetentionPolicy) than the tags are
already present and you can get the actual values of these
tags by executing the following commands, which are shown
together with example outputs:
[root] #cat ".(tag)(AccessLatency)" ONLINE[root] #cat ".(tag)(RetentionPolicy)" CUSTODIAL
To create/change the values of the tags, please execute :
[root] #echo <"New Access Latency"> > ".(tag)(AccessLatency)"[root] #echo <"New Retention Policy"> > ".(tag)(RetentionPolicy)"
The valid AccessLatency values are
ONLINE and NEARLINE,
valid RetentionLatency values are
REPLICA, OUTPUT and
CUSTODIAL.
Below are the reals examples of these commands:
[root] #echo "ONLINE" > ".(tag)(AccessLatency)"[root] #echo "REPLICA" > ".(tag)(RetentionPolicy)"