| Subsection |
Question |
Response |
| Protocol support |
Are there any unsupported or partially supported operations (e.g. pinning) ? |
All features that dCache and xrootd support natively should work for GridKa, too. |
| Prioritisation |
Can you handle priority requests? |
No. |
| Operations and metrics |
Can you provide space occupied on tapes by VO (includes deleted data, but not yet reclaimed space) to 100TB accuracy? |
Yes |
| Operations and metrics |
Can you provide total sum of data stored by VO in the archive to 100TB accuracy? |
Yes |
| Timeouts |
Do you have hardcoded or default timeouts? |
Yes, we have default timeouts with dCache for flushing and staging of at least 24 hours (may be larger on request). No timeouts are enforced with xrootd. |
| Operations and metrics |
How do you allocate free tape space to VOs? |
We do not allocate space on tape for any VO. |
| Site and Endpoints |
How is tape storage selected for a write (choice of endpoint, specification of a spacetoken, namespace prefix). |
dCache and xrootd both archive into the same tape storage backend. |
| Queuing |
Is it advantageous to group requests by a particular criterion (e.g. tape family, date)? |
In theory, yes, that would be advantageous. But we cannot guarantee that it will stay in that order or grouping. There is only a loose chronological order. |
| Recommendations for clients |
|
|
| Queuing |
→ For which operations? |
srm-bring-online / open |
| Prioritisation |
→ How is this requested? |
|
| Queuing |
→ How is this signalled to client? |
srm-bring-online and accessing a file will fail. |
| Queuing |
→ Max number of outstanding requests |
|
| Queuing |
→ Min/Max bulk request size? |
|
| Queuing |
→ Min/Max requests submitted at one time |
dCache assignes flush and stage tasks to pools, which all have an upper limit for concurrent active tasks, usually 2k. Requests beyond that are queued. For xrootd the limit is a total of 3200 concurrent flushing and staging tasks. |
| Queuing |
→ What criterion? |
Timestamps would be most useful, since tape families don't necessarily match what the VOs use as classification. |
| Queuing |
Should clients back off under certain circumstances? |
SRM feature with dCache: A limit can be set for every request type, including srm-bring-online (10k by default). Once more requests are accumulated, SRM will block and return "overloaded" error. For xrootd, there is no such feature that would reckognise an overload situation. If a file cannot be staged from tape, xrootd will fail on each subsequent request immediately. |
| Operations and metrics |
What is the frequency with which you run repack operations to reclaim space on tapes after data deletion? |
We have defined a threshold for "tape occupancy", which will trigger reclamation per tape. |
| Site and Endpoints |
What is the site name? |
FZK_LCG2 |
| Queuing |
What limits should clients respect? |
|
| Timeouts |
What timeouts do you recommend? |
|
| Site and Endpoints |
Which endpoint URLs do your archival systems expose? |
srm:{atlassrm-fzk,cmssrm-kit,lhcbsrm-kit}.gridka.de |
HEPTape Web
Create New Topic
Index
Search
Changes
Notifications
Statistics
Preferences
Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.