DOWN or when the user application is aborted.
NOTES:
1.All open requests to the Core Server will call the Gatekeeping Service open API (gk_Open). This includes opens that end up invoking a stage.
2.Any stage call that is invoked on behalf of open will NOT call the Gatekeeping Service stage API (gk_Stage). (e.g. The ftp site stage <filename> command will use the Gatekeeping Service open API, gk_Open, rather than the Gatekeeping Service stage API, gk_Stage.)
3.Direct calls to stage (hpss_Stage, hpss_StageCallBack) will call the Gatekeeping Service stage API (gk_Stage).
4.If the site is monitoring Authorized Caller requests then the site policy interface won't be allowed to deny or delay these requests, however it will still be allowed to monitor these requests. For example, if a site is monitoring Authorized Caller and Open requests, then the site gk_site_Open interface will be called for open requests from users and the gk_site_OpenStats interface will be called for open requests due an authorized caller request (e.g. migration by the MPS). The site policy can NOT return an error for the open due to migration, however it can keep track of the count of opens by authorized callers to possibly be used in determining policy for open requests by regular users. Authorized Caller requests are determined by the Core Server and are requests for special services for MPS and XFS. These services rely on timely responses, thus gatekeeping is not allowed to deny or delay these special types of requests.
5.The Client API uses the environment variable HPSS_GKTOTAL_DELAY to place a maximum limit on the number of seconds a call will delay because of HPSS_ERETRY status codes returned from the Gatekeeper. See Section 13.1: Client API Configuration of the HPSS Management Guide for more information.
Refer to HPSS Programmer's Reference, Volume 1 for further specifications and guidelines on implementing the Site Interfaces.
3.10. Storage Characteristics Considerations
This section defines key concepts of HPSS storage and the impact the concepts have on HPSS configuration and operation. These concepts, in addition to the policies described above, have a significant impact on the usability of HPSS.
Before an HPSS system can be used, the administrator must create a description of how the system is to be viewed by the HPSS software. This process consists of learning as much about the intended and desired usage of the system as possible from the HPSS users and then using this information to determine HPSS hardware requirements and the configuration of the hardware to provide the desired performance. The process of organizing the available hardware into a desired configuration results in the creation of a number of HPSS metadata objects. The primary objects created are classes of service, storage hierarchies, and storage classes.
A Storage Class is used by HPSS to define the basic characteristics of storage media. These characteristics include the media type (the make and model), the media block size (the length of each basic block of data on the media), the transfer rate, and the size of media volumes. These are the physical characteristics of the media. Individual media volumes described in a Storage Class are called Physical Volumes (PVs) in HPSS.
Storage Classes also define the way in which Physical Volumes are grouped to form Virtual Volumes
HPSS Installation Guide | July 2008 |
Release 6.2 (Revision 2.0) | 101 |
