1. Status of the SRM 2.2 MoU extension
Flavia Donno
Andrea Sciabà
Grid Deployment Board
April 8, 2009

2. Summary of items Protect spaces from generic users
Restrict space release, staging, pool-to-pool copy
VOMS awareness of SRM server
The primary FQAN in proxy should determine authorization
Space selection for read operations
More control on pool usage
Release files without knowing the ID of the request that staged them in
srmLs should say in which spaces a file exists
srmGetSpaceMetaData should return information about the used and available space in an SRM space
Pass information to the SRM server to optimize tape usage
Essential to have a high efficiency in staging

3. Space protection CASTOR Available, based on UID and GID dCache
Protection against prestaging requests available by STEP09
DPM
Spaces can be write protected. Multiple FQANs can be authorized to write (from 1.7.0).
Prestaging: not applicable.
StoRM
Space ACLs as defined in MoU (v.1.4-RCx, x4).
FQAN pattern matching supported as recommended by EGEE (EGEE-III-JRA1_FQAN_wildcard_v1.0.doc)

4. VOMS awareness CASTOR Not available. Timescale not yet defined dCache
Available. ACLs for file system operations available before STEP09
DPM
Available
StoRM

5. Space selection for read operations
CASTOR
Available
dCache
Not available. Could implement pool selection using the TExtraInfo input parameter
DPM
Not applicable
StoRM
Not applicable (files have a unique copy). Will be available with tape integration

6. Release files without request ID
CASTOR
Supported, but srmReleaseFiles buggy (files still reported as pinned after), fixed in SRM 2.8
dCache
Supported from (in preparation)
DPM
Supported from 1.7.0
StoRM
Supported

7. srmLs returns spaces CASTOR Not available dCache
Not available (files can be in only one space token)
DPM
Available with 1.7.0
StoRM

8. srmGetSpaceMetadata CASTOR
Available. It does not currently account for disk servers not in production. It will with CASTOR 2.1.8
dCache
Available
DPM
StoRM

9. Client-driven tape optimization
CASTOR
Not client-driven. Can map namespace regions or disk pools to tape pools
dCache
Not client-driven. Can pass space token to HSM interconnect scripts, and can map namespace regions to tape families
DPM
Not applicable
StoRM
Not applicable now. For integration with tape backend, foreseen to have automatic optimization

10. Other news CASTOR dCache DPM StoRM All servers
Ls will return checksum from SRM 2.8 with CASTOR 2.1.8
Initially it will not work with files created via GridFTP in “internal” mode (CERN); if created via RFIO or via GridFTP in “external” mode (Tier-1’s) it will work
dCache
Most effort on stability (asynchronous srmLs from 1.9.3)
effort to support xrootd: to be evaluated
Also working on NFS 4.1 and http support
DPM
srmCopy supported from 1.7.0
1.7.1 (to be certified) stores file checksum
(http support already available)
StoRM
Ls returns Adler32 checksum (v.1.4)
All servers
Proper usage of SRM_INTERNAL_ERROR when server or backend is busy

11. Other news (II) Clients (GFAL/lcg-util, FTS) lcg-util FTS SRM workshop
Will implement support for proper retry after an SRM_INTERNAL_ERROR by autumn
Support for asynchronous srmLs in CVS for GFAL, will come with the first patch for FTS 2.2
lcg-util
Correctly manages the case when multiple space tokens match a space description
FTS
Allows to specify space tokens, pin lifetime, file storage type and transfer parameters (to be certified)
SRM workshop
To be held on May at DESY

12. Conclusions Not available for 2009/2010 data taking
Client-driven tape optimization
VOMS support in CASTOR
Space selection in read operations in dCache
Available for STEP09?
File checksum in srmLs in CASTOR: yes, at CERN, with limitations. Yes, at Tier-1 sites, if they upgrade
Prestaging and p2p copy protection in dCache: foreseen
Release files without request ID in dCache: foreseen
File ACLs in dCache: foreseen
Space ACLs in StoRM: foreseen
Question: what is still really needed?
Are there new requirements for SRM?