**Copy Operation and Request State Transitions of**

**Common Storage Resource Manager Operations**

Timur Perelmutov

*timur@fnal.gov*

Fermi National Accelerator Lab

May 24, 2004

Version 1.0

***Introduction***

This document\'s goal is to amend the "Common Storage Resource Manager
Operations version 1.0" \[1\] with the specification of the "copy"
operation, only briefly mentioned in \[1\]. Also it provides a more
precise description of the possible states of the SRM Requests, and
events that can lead to the changes of these states. The combination of
this document and Common Storage Resource Manager Operations version 1.0
is called Storage Resource Manager specification version 1.1.

Notation and Terminology is exactly the same as in \[1\] and is not
defined here.

***Copy operation***

Name: copy

Arguments:

SURL\[\] sourceSURLs;

SURL\[\] destinationSURLs;

Returns:

RequestStatus

Description: The copy operation takes an array of source SURLs and an
array of destination SURLs. The number of elements in these arrays MUST
be equal. Either source SURLs or destination SURLs, or both MUST be
local SRM urls. The nonlocal (remote) SURLs can be either SRM urls of
some remote SRM server, compliant to \[1\], or urls in one of the
transfer protocol, known to this SRM. SRM attempts to perform the
copying of the source SURLs into the destination SURLs, first element of
source SURLs array into first element of the destination SURLs array,
etc. There are three possible combination of locality of each source
SURL /destination SURL pair.

1.  If the both source and destination SURLs are local, then SRM can
    perform internal copy .

2.  if one of the SURLs is non-local, and is in one of the transfer
    protocols supported by SRM, SRM performs copying.

3.  If one of the SURLs is non-local SRM url, SRM performs either SRM
    get for source SURL, or SRM put for destination SURL, supplying the
    list of SRM supported transfer protocols, as one of the arguments to
    discover the transfer URL. Once the TURL is known, SRM can perform
    transfer of data from/to remote TURL. It is responsibility of SRM to
    notify the remote SRM server of the completion of transfer (in case
    of success or failure) by setting each RequestFileStatus to "Done"
    state.

Uniformity of SURLs: If one source(destination) SURL is local SURL, then
all of the source (destination) SURLs are local. If one of the
source(destination) SURL is remote then all of the SURLs are remote and
have the same protocol, host and port parts.

Once the copy function is issued, the copy request is assigned a new
unique requestId, which is returned in the RequestStatus. The state of
the copy request execution can be monitored by using getRequestStatus
operation. For each pair of the sourceSURL/destinationSURL a unique
(within this request) request file id is assigned and one
RequestFileStatus structure is created in each RequestStatus returned by
copy or getRequestStatus for this request.

**Copy RequestFileStatus state transitions**

Initially the request file status state is "Pending". Once the
processing of the copy request for this SURLs pair begins, the state
becomes "Running". Once the the copying is complete the state becomes
"Ready". The state changes to "Done", (once and if) the user issued the
setFileStatus(requestId,fileId,"Done") command to cancel the request or
to indicate that it has received the notification of the completion of
the copying and the request can be disposed of by SRM. At any time,
while the copying has not completed, the state of the request can become
"Failed".

**Copy RequestStatus state transitions**

Initially RequestStatus state is "Pending". If at least one
RequestFileStatus is in "Failed" state or if there is an error,
preventing SRM from execution of the request,the RequestStatus state is
"Failed". If none of the RequestFileStatus is in "Failed" state and
there is at least one is "Running", or "Ready" the RequestStatus is
"Active". If all of the RequestFileStatuses are "Done", the
RequestStatus state is "Done" too.

**References**

\[1\] Common Storage Resource Manager Operations, Ian Bird, Bryan Hess,
Andy Kowalski , Don Petravick, Rich Wellner ,Alex Sim, Arie Shoshani,
October 22, 2001, Version 1.0,
http://sdm.lbl.gov/srm-wg/doc/srm.v1.0.pdf