IBM Hub/Switch 2.12 HPSS Metadata Backup Considerations

Chapter 2 HPSS Planning

142 September 2002 HPSS Installation Guide

Release 4.5, Revision 2

oftime. This makes a ‘migrate early, migrate often’ strategy a feasible way to keep XFS disks clear

of inactive data.

The only inherent size limitation for XFS is a 2 TB maximum ﬁlesystem size, which is a limitation

of the Linux kernel. The ﬁle size limit is 16-64TB (depending on page size) which is limited in

practice by the maximum ﬁlesystem size.

Sitesmay choose to implement site policy in the Gatekeeper Server for load balancing create, open,

and/orstage requests. The site policy could limit the maximum number of non-AuthorizedCaller

requests allowed at once by either delaying or denying particular requests. To delay the request,

thesite policy may return a special retry status along with the number of seconds to wait before the

Client API retries the request. Delaying requests should limit the number of create, open, and/or

stage requests performed at a particular point in time, thus decreasing the load on the system.

However,care must be taken to ﬁgure out the best retry wait scheme to meet the requirements for

eachsite and to conﬁgure the correct number of Gatekeeper Servers if the load on one Gatekeeper

Serveris heavy. (Note: The maximum number of Gatekeeper Servers per storage subsystem is one.)

Also, sites need to write their Site Interfaces optimally to return in a timely manner.

Twospecial error status codes (HPSS_ETHRESHOLD_DENY and HPSS_EUSER_DENY) may be

used to reﬁne how a site may deny a create, open, or stage requests. If the BFS receives either of

these errors, then it will return this error directly to the Client API rather than performing a retry.

Errorsother than these two or the special HPSS_ERETRY status will be retried several times by the

BFS. See either volume of theHPSS Programmer's Reference for more information.

Create,open, and stage requests from Authorized Callers (DMG, MPS, NFS) can NOT be delayed

or denied due to timing sensitivity of the special requests these servers make to the BFS. For

example, migration of a ﬁle by MPS is an Authorized Caller Open request. The site policy could

keep track of Authorized Caller requests to further limit non-AuthorizedCaller requests.

If a Gatekeeper Server is being used for Gatekeeping Services, then the BFS for each storage

subsystemconﬁgured to use a particular Gatekeeper Server will return errors for the create, open,

and/orstage requests being monitored by that Gatekeeper Server when that Gatekeeper Server is

down. For example, if storage subsystem #2 is conﬁgured to use Gatekeeper Server #2, and

Gatekeeper Server #2 is monitoring open requests and is DOWN, then each open by the BFS in

storage subsystem #2 will eventually fail after retrying several times.

2.12 HPSS Metadata Backup Considerations

This Section contains guidelines for proper maintenance of the SFS metadata. The policies

describedshould be fully understood and implemented to protect the HPSS metadata. Failure to

follow these policies can lead to unrecoverable data loss.

Also, if running a Highly Available HPSS, make sure to review Section G.7: Metadata Backup

Considerations on page 569 as it covers issues related to reliable metadata backup in an HA environment.

Theremainder of this section is a set of “rules” associated with backing up HPSS metadata. Though

toolslike sfsbackup as well as site speciﬁc generated scripts and procedures can be used to backup