have a significant impact. Turning the flag on constrains files that are alread y larger than the Maximum
File Size to their current size. Existing smaller files will be constrained to the Maximum File Size.
Changing Minimum File Size can have an impact on COS selection. Currently, the PFTP and FTP
interfaces use the Minimum File Size to select an appropriate COS based on file s ize.
Changing the Stage Code should be done with care:
•The On Open option stages files to the top of the hierarchy when the file is opened, and is
synchronous. The open operation returns when the stage operation completes.
•The No Stage option can have a significant impact on system performance. Repeated reads of
files that have been migrated will generally be satisfied from lower levels in the hierarch y where
files are likely to be on tape. If users are writing only parts of a file at a time with s ignificant
delays between the writes, migration may result in the file being stored in a more fragmented
manner on tape.
•The On Open Async option causes stage operations to be started when files are opened, but open
operations do not wait for stages to complete; they return to their callers immediately. If a caller
then reads one of these files, the read operation will block until the stage is complete.
•The On Open Background option causes an open operation to complete immediately, returning a
special error code that indicates that the stage is not complete. The caller can then poll HPSS for
completion of the stage operation before reading the file. Normally this polling is done
automatically by the client API, but client API polling can be turned off which will allow the
client to do the polling.
Changing the Auto Stage Retry flag has no adverse side effects. It is recommended that this flag be
enabled for all COS's using multiple copies.
The hierarchy associated with a COS cannot be changed without deleting all files in this COS or moving
them to another COS. Failure to observe this condition will likely result in lost and corrupted files. Any
changes to an existing COS other than changing the hierarchy ID can be put into effect by re-initializing
core servers that use the COS. If a COS is deleted or added, the core servers must be recycled to
recognize this.
6.3.4. Deleting a Class o f Service Definition
To delete a COS, you must ensure that all files in the COS have been either deleted or moved to another
COS and that all configuration references to the COS have been removed. These configurations include
the Global Configuration's Default Class of Service, Storage Subsystem's Default COS Override, Log
Daemon's Archive Class of Service, and every fileset's associated Class of Service.
Deleting a Class of Service is an unusual administrative action and HPSS does not provide uti lity
programs to delete all the files in a given COS or move all files in a given COS to another COS. A
certain amount of site specific ad hoc planning and usage of available tools will be necessary to identify,
remove or move all files from a Class of Service. The dump_acct_sum utility program provides a count
of the number of files in all Classes of Service based on the accounting metadata and was developed
primarily so there would be a reasonable way to know if a Class of Service was empty.
To delete the COS definition, use the Delete button on the appropriate Class of Service Configuration
window.
HPSS Management Guide November 2009
Release 7.3 (Revision 1.0) 179