release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg

SRM Space Manager configuration

[return to top]

SRM Space Manager and LinkGroups

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.

[return to top]

Definition of the LinkGroups in the PoolManager.conf

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.

[return to top]

Activating SRM Space Manager

In order to enable the new space reservation: add (uncomment) the following definition in dCacheSetup


[return to top]

SRM Space Manager Parameters in dCacheSetup

[return to top]


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:


[return to top]


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:


[return to top]


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:


[return to top]


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:


[return to top]

Implicit Space Reservations

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)()"

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)"