Database Reference
In-Depth Information
and managing user quotas internally. However, the experience with SRM v1.1
revealed functionality that was missing: in particular, the need to explicitly
reserve space through the interface and manage its lifetime, explicitly creating
and managing directories through the interface and providing access control.
This led to SRM v2.2, which was stabilized to a great degree based on practical
requirements from the Large Hadron Collider (LHC) SRM development team
(see Section 3.4). By now several more implementations resulted, including
an SRM for a disk pool at CERN, called DPM; an SRM for the parallel
file system GPFS in Italy, called StoRM; and an SRM that can be deployed
to disk systems or various MSS system at LBNL, called BeStMan. A brief
description of each of these implementations is provided in Reference 10 as
well as large-scale daily testing of their interoperation. The interoperation of
SRM implementations that adhere to SRM v2.2 specification and locations of
their use is illustrated in Figure 3.4.
The historical discussion above was intended to show that the SRM spec-
ification was developed over time by a large number of international collab-
orators. SRM v2.2 was submitted and approved as a standard by the Open
Grid Forum (OGF).
3
The practical requirements of the SRM usage for the
LHC are discussed in some detail in Section 3.4 as an example of a suc-
cessful deployment of SRM technology in a large international project. The
change from SRM v1.1 to SRM v2.2 illustrates the diculties of evolving stan-
dards. The SRM deployment in the Earth Systems Grid (ESG) is discussed in
Section 3.6.
We discuss next the main concepts that emerged over time for SRM regard-
less of their versions. We focus only on the latest version.
3.3.2 SRM Concepts
To illustrate the functionality of SRMs, we start with a simple example of
having to run a job on a local machine; the files that are needed for the job
are at remote locations including remote MSSs. Assume that the job requires
a large number of files (100-1000). A user will have to perform the following
actions:
allocate space
bring in all input files or some fraction of the files if they do not fit in
the space
ensure correctness of files transferred
monitor and recover from errors
if files don't fit space, remove files to make space for more files
save output files, possibly moving them to archival storage
if files come from different storage systems (including MSSs), different
protocols may need to be used
