Chapter 2 HPSS Planning
114 September 2002 HPSS Installation Guide
Release 4.5, Revision 2
map records is the total number of disk storage segments divided by 2. Another way to put an
upper bound on the number of disk map records is as follows:
• For each disk storage class defined, determine the total amount of disk space in bytes
available in the storage class.
• Divide this by the storage segment size for the storage class. This will give the maximum
number of storage segments that could be created for this storage class.
• Sumthe number of storage segments needed over all the storage classes. This will give you
anupper bound on the number of storage segments. This value is also an upper bound on
the number of disk maps, making the worst case assumption that each file uses only one
storagesegment. If you assume two segments per file, divide the total number of segments
by 2.
Bitfile Tape Segments. For a bitfile that is a stored on tape, one or more records will be created in
the bitfile tape segment file. Under normal conditions, you would expect one bitfile tape segment
recordfor each tape on which the file is stored. A safe assumption is that for each bitfile stored on
tape, you need two bitfile tape segment records.
BFS Storage Segment Checkpoint. The BFS storage segment checkpoint file is used to maintain
consistency of allocated storage segments. Basically, this consistency is needed because it is
necessary to allocate space in a separate Encina transaction to allow maximal storage access
concurrence. This file should normally be large enough to store a few hundred records.
BFSStorage Segment Unlinks. The BFS storage segment unlink file is used to keep track of Storage
Server storage segments that need to be deleted. Deletion of storage segments is done in a Bitfile
Serverbackground thread for enhanced performance. This file normally should be large enough to
store a few thousand records.
BitfileCOS Changes. The COS change file keeps track of bitfiles that have a pending COS change.
When the COS of a bitfile is changed, a record is created in this file. It is deleted by a background
threadin the BFS when the COS change has been successfully accomplished. This usually involves
copyingthe file data to new media. Under normal operations, this file would be large enough for a
fewhundred records. However, if a utility is used to change the COS on a large set of files, this file
mayneed to be enlarged; otherwise, the utility will have to do its work in a piece-meal fashion over
some period of time.
Bitfile Migration Records. The Bitfile Server creates a migration record for a file that needs to be
migratedand deletes this record when the migration is completed. In the worst case scenario, this
file would contain a record for every bitfile that is stored on disk. If a site is able to estimate how
many files are in an active and unmigrated state, then this file can be limited to this number.
Bitfile Purge Records. The Bitfile Server creates a purge record for each file that has data in a
purgeablestate. This includes files that have been migrated and files that have been staged but not
overwritten. In the worst case scenario, this file would contain a record for every bitfile that is
storedon disk. If a site is able to estimate how may files would be in a purgeable state, then this file
can be limited to that number. Generally, a file will not have both a migration record and a purge
record.Based on this, the number of records in the migration file plus the number of records in the
purge file would be equal to the number of files stored on disk.
Accounting Summary Records. This file contains accounting information for an account index,
COSid and storage classes combinations. There are essentially two kinds of records: 1) if the
storage class is 0, then the record is a storage summary record and contains the total number of