Database Reference
In-Depth Information
This is a lot of work for each user to manage. One can imagine writing
specialized scripts to manage this task. SRMs are designed to provide this
functionality through appropriate interfaces. Furthermore, SRMs are designed
to provide this functionality on shared storage resources, such as a shared disk
cache by a community of users, by allocation of space quotas to users, and to
ensure fairness of space allocation and scheduling. In addition, SRMs provide
uniform access to all storage systems including MSSs. The concepts involved
in fulfilling this scenario by SRMs are explained next.
1. Logical file name for files at a site.
As mentioned above, an SRM
may front multiple storage systems at a site. A file may reside on any
one or more of these systems. Furthermore, it may be advantageous for
the SRM at that site to copy a file temporarily to a disk system that has
better transfer access for the user. For this reason it is useful to have a
single logical file name (LFN) associated with that site. For access by
SRMs, the LFN is complemented with machine name and port at the
site to produce a site URL (SURL). An example of such an SURL is,
srm://sleepy.lbl.gov:4000/tmp/foo-123. Note that the protocol is “srm”;
the machine name is “sleepy.lbl.gov” at port 4000; the directory name
is “tmp”; and the file name is “foo-123.” In general, using SURLs by
SRMs is a way for a site to move files to any storage system they support
while still having the same SURL visible externally through catalogs or
other means.
2. Transfer URL for accessing files.
Once the SRM is given the SURL
through the function call to get a file, it decides which copy to provide
the client. The file can be on a different machine and port than the
SRM, and a protocol supported on that machine has to be provided for
the client to use to transfer the file. Thus, the SRM returns a transfer
URL (TURL). An example of a TURL for the SURL above might be
gridftp://dm.lbl.gov:4010/home/level1/foo-123. Note that the transfer
protocol provided is “gridftp”; the machine name and port are different,
as well as the directory path. Usually, file names stay the same in the
TURL, but returning a different file name is possible.
3. Transfer protocol negotiation.
The protocol provided to the client
must match the protocols the client has. For this reason, a request to
get files has a parameter, where a client can specify an ordered list of
preferred protocols. The SRM returns the highest possible protocol it
supports. For example, the client can provide a protocols list: bbftp,
gridftp, and ftp; and the SRM returns gridftp, since it does not have a
server that supports bbftp.
4. Putting files into SRMs.
In order to put files into SRMs, such as
output files of a job, the SRM has to allocate space. The function call
requesting to put a file specifies the SRUL of the file that will be put into
the SRM, along with the file size. If the file size is unknown, the SRM
