Database Reference
In-Depth Information
still allowing the SRM to garbage-collect the space at the end of that pe-
riod in case the administrator neglects to do so. This is a very important
capability to ensure that unnecessary files do not clog large shared disks.
When putting files into the SRM, it is often needed to ensure they are
not lost, especially when it is the original copy of a file. For this reason,
SRMs support a file type referred to as
permanent
, referring to files that
can only be removed explicitly by the owner or by users given permis-
sion by the owner. While this is an obvious requirement, an SRM needs
to ensure that such files are protected. For example, the file may reside
in a storage space that is released by its owner (see space reservation,
below). If such a space contains a permanent file, the SRM needs to take
action such as archiving the file and/or notifying the owner before that
space can be released.
Another interesting case is when files are “dumped” temporarily into
a disk cache because of high transfer-rate requirements, with the inten-
tion of archiving them later and releasing them once archived. In such
a case, files are given a lifetime long enough until the archiving com-
pletes. Normally, the files will be released after they are archived by the
program responsible to archive them. However, in case of a mishap, it
is necessary to protect these files as if they were permanent. We refer to
such a file type as
durable
in the sense that a warning is issued by the
SRM if their lifetime expires rather than removing the files. Concurrent
with the warning, an SRM may take a default action, such as archiving
these files so that the disk space can be released for other usage.
The three types of files, volatile, durable, and permanent, were found
to be sucient for all use cases encountered so far. In practice, some
projects choose to have all files permanent in order to have full control
of what is kept in the storage systems, and others always use volatile file
types when data is replicated. So far, durable file types have not been
used in practice.
10. Asynchronous support of requests.
Multifile requests to get files from
an SRM or to put files into an SRM are an important feature that al-
lows clients to express a large request at once either by listing the set of
files or by providing a directory name that contains all the files. Since
such requests can take a long time to complete, it is not practical for
them to be synchronous, that is, forcing the client to wait for their com-
pletion. Thus, all such requests need to be supported asynchronously.
This means that some kind of a request token has to be returned when
a request is made, and the client can at any time later use the request
token to find out the status of the request.
Request tokens can be either supplied by the client or provided by the
SRM. However, relying on client assignment of token names can cause
errors, and therefore in the SRM specification it was decided that the
SRM generates a request token that is guaranteed to be unique (usually
