Database Reference
In-Depth Information
SRM Interface
SRM Interface
Storage
Resource
Manager
SRM Disk
Cache
Storage
Resource
Manager
MSS Interface
Tape Robot
Tape Robot
MSS Disk
Cache
MSS Disk
Cache
MSS
MSS
Figure 3.2
SRM interface to a mass storage system. On the left the SRM
is embedded in the MSS; on the right it is external to the MSS, managing its
own disk cache.
can choose to take the first approach of extending the MSS to support the
SRM functionality. This is the case with several systems as described in the
next section (JASMine, dCache, and Castor). On the other hand, the MSS
system can be treated as a “black box,” and a front-end SRM accesses that
system through its API. This was the case with HPSS as well as with a legacy
MSS system in the National Center for Atmospheric Research (NCAR) as
described in Section 3.5.2.
The difference between these two approaches is illustrated in Figure 3.2. On
the left the SRM software is embedded in the MSS, thus exposing the SRM
interface (in addition to the previously supported interfaces). On the right
the SRM software is external to the MSS and communicates with the MSS
through its interface. In the case of HPSS the interface is either PFTP (parallel
FTP) or HSI (hierarchical storage interface). As can be seen in the case of
an external SRM, the SRM manages its own disk cache and files that go into
and out of the MSS get copied to the SRM cache. This extra “hop” can add
to access latency when getting a file from the MSS. However, if the file is
on tape, the time to transfer it from one disk to another is a small fraction of
the total latency. On the other hand, having the SRM cache can help, since
frequently accessed files by the SRM clients are kept in its cache. This can
lead to better access rates, as clients do not have to compete with other MSS
clients. A similar advantage can be achieved while putting files into the MSS
since the files can be written quickly into the SRM disk cache and then moved
lazily by the SRM to the MSS.
