Database Reference
In-Depth Information
assumes a maximum default size. The SRM allocates space, given that
the quota available to the user has enough space to hold this extra file
and return a TURL the client can then put the file using the TURL
transfer protocol into the allocated space. We note that an SRM may
limit the number of TURLs it returns to the client because of space
limitations or prevent the client from transferring too many files con-
currently, thus overwhelming the storage system.
5. Getting files from remote sites.
Since SURLs are used to identify
precisely the SRM site that stores a particular file, it is possible in prin-
ciple to request a file to be brought into a local SRM from a remote site,
by simply providing it with the remote SURL. This requires that SRMs
communicate with each other in a peer-to-peer fashion. A special copy
function is provided that permits getting files from a source SRM to a
target SRM in either
pull
or
push
mode.
Not all SRM implementations support the copy function if the SRM
is intended for use as a local SRM. In this case, the SRM only supports
requests to get files from or to put files into the SRM. In dealing with
such local SRMs, it is still possible to transfer files between sites. For
example, the file transfer service (FTS)
37
developed at CERN for the
LHC projects and described in Section 3.4 requests to get a file from the
source SRM, gets back a source TURL, then requests to put a file from
the target SRM, which allocates the space for it, and returns a target
TURL. FTS then uses the two TURLs to perform a third-party transfer
between the source and target disk caches. This mode of operation also
gives FTS full control of the number of transfers requested, as well as
monitoring their performance.
6. Pinning files and releasing files.
When a file is requested from an
SRM, there needs to be some guarantee that the file will stay in place
until it is used. On the other hand, an SRM cannot afford to keep the
file indefinitely or rely on the client to delete it when done. For example,
a client can crash and never delete the requested file. For this reason
SRM supports the concept of
pinning
a file for a specified lifetime. The
length of the lifetime is negotiable, where it can be specified in a request,
and the SRM can choose to return a shorter lifetime based on its local
policies. The clock on the lifetime for a file starts at the time that the
file is made available to the client. Thus, when requesting multiple files
to be staged from an MSS, for example, each file may have a different
start time on its lifetime.
It is useful for the SRM to know when the client is finished accessing
a file. In that case it can reuse the space by deleting the file if necessary.
The function to let the SRM know that the client no longer needs the
file is referred to as
releasing
the pin on the file. The reason for having
a release concept rather than delete is that the SRM can in this case
have the choice whether to keep the file longer (e.g., for another client)
