How FTS handles space tokens
The user can specify either the source or the destination token for a job:
glite-transfer-submit -t dest_token -S source_token ...
This page explains how FTS treats these token strings.
FTS 2.2
Source token
- Assume that token_string is a token description and issue an srmGetSpaceTokens request to the SRM
- If the request fails, fail the transfer (scope = source, phase = preparation, category = ERROR_USER)
- If the request succeeds, one or more tokens are returned with the arrayOfSpaceTokens parameter. Choose the first one. No further check is made on the source token(assume that the tokens returned by srmGetSpaceTokens are valid).
Destination token
- Assume that token_string is a token description and issue an srmGetSpaceTokens request to the SRM
- If the request fails, fail the transfer (scope = destination, phase = preparation, category = ERROR_USER)
- If the request succeeds, one or more tokens are returned with the arrayOfSpaceTokens parameter
- If there is only one token, issue an srmGetSpaceMetaData request for the token and check that the unusedSize parameter is at least equal to the file size plus a margin (see below).
- If the space satisfies the requirements, continue the transfer
- If the space does not satisfy the requirements, fail the transfer (scope = destination, phase = preparation, category = ERROR_NO_SPACE_LEFT)
- If there is more than one token, issue an srmGetSpaceMetaData request for each token
- Select the space with the lowest unusedSize among those that have an unusedSize equal at least to the file size plus a margin
- If none of the spaces specifies the above requirement, fail the transfer (scope = destination, phase = preparation, category = ERROR_NO_SPACE_LEFT)
Note: the file size margin is arbitrarily chosen to be 1MB.
FTS 2.1 and previous versions
- The case of multiple space tokens corresponding to the same description was not foreseen. In case more than one space token was returned, the first one was selected.
- If the srmGetSpaceTokens request failed, the token string was assumed to be the token itself. This behavior has been removed in following versions.
Last edit:
PaoloTedesco on 2009-01-22 - 13:32
Number of topics: 1
Maintainer:
PaoloTedesco