Status of the SRM 2.2 WLCG usage agreement and its addendum

Addendum requirements

Feature BeStMan Gateway CASTOR dCache DPM StoRM GFAL/lcg-util Priority
Protection of spaces from (mis-)usage by generic users via space ACLs No Yes, but not by DN/FQAN Yes, but only Stage-to-Space Yes, but only Write-To-Space Yes N/A 2 1: to protect spaces dedicated to special activities (e.g. T1D0 at T1) 1: needed for better data protection
Full VOMS-awareness Yes No Yes Yes Yes Yes 1.5 1: easier mgmt of access privileges 1: needed for better data protection
Selecting spaces for read operations No Yes No Yes No, but no tape backend Yes 1 1: all T1s could use space tokens 1: needed to understand data movement and used disk space
Correct implementation of srmGetSpaceMetadata Yes Yes Yes Yes Yes Yes      
Providing information to efficiently store data to tapes N/A No No N/A N/A No 0 0 0
srmLs returns all space tokens with a copy of the file No Yes No, but files can be in one space only Yes No, but files can be in one space only Yes 0.5 1: to understand where a file is 0.5
Release files without request token Yes Yes Yes Yes Yes Yes     2
N/A = Not applicable

Items in red changed recently.


  • 0 = useless
  • 1 = if available, it could allow for more functionality in data management, or better performance, or easier operations, but it is not critical
  • 2 = critical: it should be implemented as soon as possible and its lack causes a significant degradation of functionality / performance / operations.

Other requirements

Feature BestMAN CASTOR dCache DPM StoRM GFAL/lcg-util Priority
File pinning N/A No Yes Yes Yes Yes 2: "soft" pinning is acceptable 2 2


The two main issues at tier2 sites are the "scalability and stability" at the requested scale needed to fulfill experiments requirements. I.e. it is required that the SRM front-end should guarantee that the activity of a single user could not disrupt the service

Implementation details

Space protection

According to the Addendum, a space allocation can have an Access Control List (ACL) defining who can do what. The possible operations which are mandatory for WLCG are Read-from-Space, Write-to-space, Stage-to-Space, Replicate-from-Space and Purge-from-Space. The optional operations are Release-Space, Update-Space, Modify-Space-ACL and Query-Space. A user should be identified by his DN and/or VOMS primary FQAN. The Addendum proposes to follow the syntax used by NFSv4. Given that Modify-Space-ACL is optional, it is acceptable that only the administrator can modify the ACLs.

BeStMan Gateway

As BeStMan is deployed on top of other file systems, none of SRM space features are supported, nor really required, from the experience of the T2 sites using BeStMan. Usually, the management features (such as spaces in XrootD or quotas in HDFS, GPFS, and Lustre) are provided by the underlying file system.

Being fully VOMS-aware has been a crucial feature for management; this has been delivered for about a year or so, and is well-tested.


CASTOR allows to grant or deny certain privileges to users or groups via a native interface consisting of the commands stager_addprivilege, stager_removeprivilege and stager_listprivileges. There are several possible operations, among which Get, Put, PrepareToGet, PrepareToPut, PutDone, Rm, DiskCopyReplica, ChangePrivilege and ListPrivileges. The operations in the Addendum are covered, but the ACLs identify users via username and groupname rather than DN or VOMS FQAN.


Starting from release 1.9.4, dCache provides support for Tape Protection, that is, restriction of who may read from tape (Tape Read Access). This mechanism can be activated only by the administrator, who has to decide which users can trigger file staging. Users are identified by the DN of their certificate and optionally a VOMS FQAN. Wildcards are allowed. The only operation supported is Stage-to-Space.


For DPM the most important requirement for space protection (to forbid file staging by generic users) does not apply by definition. The only form of space protection is the possibility to restrict writing to a space to a list of VOMS FQANs. In general, a space belongs to a group and only members of the group can write to the space.

Full VOMS awareness


CASTOR has a very crude form of VOMS awareness: authorisation via SRM works using the grid-mapfile mechanism, which is built using a tool equivalent to edg-mkgridmap. Its configuration file maps VOMS FQANs to local accounts (possibly pool accounts) and the DNs having a certain FQAN are retrieved from the VOMS server. Therefore, the VOMS extensions of the user proxy are totally irrelevant. For the moment there are no definite plans to implement real VOMS support.

Selecting spaces for read operations

If space selection for read operations is supported, srmChangeSpaceForFiles does not need to be supported, as the same functionality can be obtained invoking srmBringOnline or srmPrepareToGet followed by a srmPurgeFromSpace.


It is not possible to select on which space token a file should be staged, because in dCache all files have a single "SRM copy" (which does not prevent from having other copies on pools which cannot contain space tokens). At the dCache level it is possible to select the pool where to stage a file according to rules which look at the client IP or the protocol, but this cannot be controlled via SRM.


DPM allows to specify a target space token for srmBringOnline requests, but this is irrelevant in the WLCG context, as DPM is not currently used with a tape backend.


In StoRM, a file can exist on only one space, hence space selection for read operations does not make sense. Moreover, currently StoRM is not used with a tape backend. Anyway, also when StoRM will support T1D0 (using GPFS-TSM), it will not be possible to specify a target space and the file will always be staged to the same disk cache.

Currently StoRM at CNAF implements T1D1, but using the tape backend (GPFS-TSM) as a backup system; if a file disappears from disk, it will be automatically staged back from tape.

Correct implementation of srmGetSpaceMetadata

srmGetSpaceMetadata should return information about the space used and available for a given space token.

Providing information to efficiently store data to tapes

This request is now unanimously considered irrelevant.

File Pinning


Ideally file pinning should be "hard" everywhere. However, "soft" pinning is acceptable, but only because a dedicated prestaging service is being developed for ATLAS to handle the space management.


File pinning is extremely important to make data reprocessing manageable, given that the disk cache is limited. A "soft" pinning can be acceptable, but it should have a real effect on the order in which files are garbage collected, which is not the case today.

WLCG SRM Usage agreement summary

In this section all requirements expressed in the WLCG SRM usage agreement are listed "as they are", just for convenience. To critically review them is for the time being outside of the scope of this document.
  • Storage classes. Only T1D0, T1D1 and T0D1 are used.
  • File lifetime. All files are permanent and can be completely removed only using srmRm.
  • Protocol negotiation. Protocols are specified in order of preference in Get, Put and BringOnline requests.
  • Space size. It only refers to the disk space, while tape space is considered infinite.
  • Space reservation. Only static space reservations are mandatory.
  • Space reservation. The input parameter sizeOfTotalSpaceDesired shall be ignored.
  • Space reservation. It can be restricted to certain DNs or VOMS roles. If not allowed, the server returns SRM_AUTHORIZATION_FAILURE.
  • Space reservation. The input parameter expectedFileSize shall be ignored.
  • Space reservation. The input parameter preferredRetentionPolicyInfo should be renamed retentionPolicyInfo and the corresponding output parameter removed.
  • Space reservation. The input parameter storageSystemInfo shall be not be specified by the client and shall be ignored by the server.
  • Space reservation. The lifetime of the reserved space may be infinite, the client must take care of removing the space.
  • Space reservation. The input parameter transferParameter is optional.
  • Space reservation. The method srmChangeSpaceForFiles does not need to be supported.
  • Ls. The file locality and the space token returned by srmLs do not have to be returned for directory listings.
  • Ls. The file locality must be LOST for permanent hardware failures, UNAVAILABLE for temporary hardware failures.
  • Ls. For directory listings the number of entries returned can be limited.
  • Ls. If the file does not exist, SRM_INVALID_PATH is returned.
  • Ls. If numberOfLevels is zero, the returned information refers to the directory itself.
  • Get/BringOnline. The target space token can be specified.
  • Get/Put. The transfer protocol is mandatory.
  • Get/Put/BringOnline. The method is asynchronous.
  • Get. If the connection type is not provided, the server can choose it.
  • Get/Put/BringOnline. The output estimated times cannot be relied upon.
  • Get/BringOnline. If a file is temporarily unavailable, SRM_FILE_UNAVAILABLE is returned.
  • Get/BringOnline. If a file is permanently lost, SRM_FILE_LOST is returned.
  • Get/Put/Copy/BringOnline. If a file has still an open Put (= no srmPutDone issued), SRM_FILE_BUSY is returned.
  • Get/Put/Copy/BringOnline. If the request does not complete within the totalRequestTime (negotiated with the server), it times out and returns SRM_TIMEDOUT. Not required for the start of data taking.
  • Put. The client must provide SURLs and the implementation does not have to generate names.
  • Put/BringOnline. The server shall allow the request to continue provided that at least one file is successful or in progress.
  • Get/Put. If both target space token and RetentionPolicyInfo are specified, they must match, otherwise SRM_INVALID_REQUEST is returned.
  • Get/Put/Copy. The WLCG clients will specify the target space token and not the RetentionPolicyInfo. A default space token will be chosen by the server if not specified.
  • Put/Copy. WLCG shall not use any SURL lifetime.
  • Put. The TURL lifetime is the time available to write the file, after which the TURL may become invalid.
  • Put. A TURL returned by a srmPrepareToPut cannot be used for read access.
  • Copy. Files are immutable and therefore WLCG clients shall not specify overwriteOption.

-- AndreaSciaba - 2009-08-28

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r17 - 2010-05-07 - AndreaSciaba
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback