Chapter 1 HPSS Basics
30 September 2002 HPSS Installation Guide
Release 4.5, Revision 2
purge, and storage servers must now exist within a storage subsystem. Each storage subsystem
maycontain zero or one gatekeepers to perform site specific user level scheduling of HPSS storage
requests or account validation. Multiple storage subsystems may share a gatekeeper. All other
serverscontinue to exist outside of storage subsystems. Sites which do not need multiple name and
bitfile servers are served by running an HPSS with a single storage subsystem.
Storagesubsystems are assigned integer ids starting with one. Zero is not a valid storage subsystem
idas servers which are independent of storage subsystems are assigned to storage subsystem zero.
Storage subsystem ids must be unique. They do not need to be sequential and need not start with
one,but they do so by default unless the administrator specifies otherwise. Each storage subsystem
has a user-configurable name as well as a unique id. The name and id may be modified by the
administratorat the time the subsystem is configured but may not be changed afterward. In most
cases,the storage subsystem is referred to by its name, but in at least one case (suffixes on metadata
filenames) the storage subsystem is identified by its id. Storage subsystem names must be unique.
Thereare two types of configuration metadata used to support storage subsystems: a single global
configurationrecord, and one storage subsystem configuration record per storage subsystem. The
global configuration record contains a collection of those configuration metadata fields which are
usedby multiple servers and that are commonly modified. The storage subsystem records contain
configuration metadata which is commonly used within a storage subsystem.
Itis possible to use multiple SFS servers within a single HPSS system. Multiple storage subsystems
areable to run from a single SFS server or using one SFS server per storage subsystem. In practice,
differentmetadata files may be located on different SFS servers on a per file basis depending on the
SFS path given for each file. For configuration and recovery purposes, however, it is desirable for
allof the metadata files for a single subsystem to reside on a single SFS server. This single SFS server
mayeither be a single server which supports the entire HPSS system, or it may support one or more
subsystems. Those metadata files which belong to the servers which reside within storage
subsystems are considered to belong to the storage subsystem as well. In an HPSS system with
multiplestorage subsystems, there are multiple copies of these files, and the name of each copy is
suffixed with the integer id of the subsystem so that it may be uniquely identified (for example
bfmigrrec.1,bfmigrrec.2, etc.).
Metadata files that belong to a subsystem (i.e. files with numeric suffix) should never be shared
between servers. For example, the Bitfile Server in Subsystem #1 has a metadata file called
bfmigrrec.1.This file should only be used by the BFS in Subsystem #1, never by any other server.
The definitions of classes of service, hierarchies, and storage classes apply to the entire HPSS
systemand are independent of storage subsystems. All classes of service, hierarchies, and storage
classesare known to all storage subsystems within HPSS. The level of resources dedicated to these
entities by each storage subsystem may differ. It is possible to disable selected classes of service
within given storage subsystems. Although the class of service definitions are global, if a class of
service is disabled within a storage subsystem then the bitfile server in that storage subsystem
neverselects that class of service. If a class of service is enabled for a storage subsystem, then there
mustbe a non-zero level of storage resources supporting that class of service assigned to the storage
servers in that subsystem.
Data stored within HPSS is assigned to different Storage Subsystems based on pathname
resolution.A pathname consisting of “/” resolves to the root Name Server. The root Name Server is
the Name Server specified in the Global Configuration file. However, if the pathname contains
junction components, it may resolve to a Name Server in a different Storage Subsystem. For
example,the pathname “/JunctionToSubsys2” could lead to the root fileset managed by the Name
Serverin Storage Subsystem 2. Sites which do not wish to partition their HPSS through the use of