r2 - 30 Apr 2008 - 08:28:49 - ShawnMckeeYou are here: TWiki >  Admins Web > SpaceTokens


Questions from Shawn

Hi Everyone,

At AGLT2 we have setup SRM V2.2 compliant spaces ATLASMCDISK,
warning Apparently the name of the GROUP area is now ATLASGRPDISK -- Shawn

We are still using AGLT2_SRM (SRM V2.2 without space tokens) for all
production because of possible issues with various parts of the
production system supporting space tokens.  

Here is my understanding of things along with some questions.  Please
correct my mis-impressions.

A "space token" is a 6 digit number representing a storage
"contract"(size, lifetime, VO/role privilege).   Within ATLAS we have
"names" representing types of storage (as above).   The space token
should be created by the site's storage administrator.  For example, in
dCache this means that the space token for ATLASMCDISK will be
associated with the corresponding pools and directory setup for this
storage.   Also for dCache there is a way to "alias" the name for the
actual space token.  So an admin can configure a space token (605133)
and set ATLASMCDISK as a name for this (like DNS for a network

For site's using  space tokens the ToA entry should explicitly call out
the "name" attached to the space token (e.g., ATLASMCDISK). 

Site's apparently need to publish (via GIP?) their storage and space
token info because some clients query this.

OK...now for my main questions:

1) For the space tokens Tier-2's are supposed to provide (see list at
	a) ATLAS should be the only supported VO? 
	b) Should the "size" associated with each space-token be the
total size of the storage area setup for this purpose? (or should we
limit it to something less?)
	c) What is the "lifetime" we should use for the 4 tokens
(infinite) ?
	d) For the 4 tokens which "VOMS" roles should have which
privileges (read, write, delete)?

2) How should we configure dCache to "alias" the space token name? (An
example would be nice)
3) Can the various client tools directly utilize the "name" (as opposed
to the space token number)?
4) Can someone provide details of configuring GIP to publish the storage

5) What is the status of PANDAMOVER, Pilots and (in general) the
production system regarding supporting space-token storage? (We really
want to transfer our production to our new storage locations because
AGLT2_SRM utilizes worker nodes for its pools and they don't serve files
well when running jobs).

6) Are there any tools within ATLAS which support implementing storage
"policies"?  Any recommended policies?

Thanks for any clarifications or examples.   It would be really useful
to have a web page that Tier-2's can go to for this storage migration to
space-tokens that would summarize all the steps and choices.


Here is a US ATLAS Tier-2 table for SRM V2.2 compliant areas we must support

Space Token Description Example dCache Path ToA Naming Convention Minimum Size (TB)
ATLASMCDISK /pnfs/<site_domain>/atlasmcdisk <site>_MCDISK 10
ATLASDATADISK /pnfs/<site_domain>/atlasdatadisk <site>_DATADISK 10 (Depends upon subscriptions/cpus at site)
ATLASGRPDISK /pnfs/<site_domain>/atlasgrpdisk <site>_GRPDISK 2
ATLASENDUSERDISK /pnfs/<site_domain>/atlasenduserdisk <site>_ENDUSERDISK 2 (Depends upon user count? 1 TB/user?)

An example <site_domain> is aglt2.org and and example <site> is AGLT2.


-- RobertGardner - 29 Apr 2008

About This Site

Please note that this site is a content mirror of the BNL US ATLAS TWiki. To edit the content of this page, click the Edit this page button at the top of the page and log in with your US ATLAS computing account name and password.


Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback