Administration Guide › SFS Overview › CA VM:Director Configuration for SFS User Administration › Resynchronizing the CA VM:Director Configuration of SFS

Resynchronizing the CA VM:Director Configuration of SFS

SFS allocations that anyone makes outside CA VM:Director are unknown to CA VM:Director, making its SFS administration information unreliable. Therefore, you must verify that no allocations are made outside CA VM:Director or resynchronize the CA VM:Director configuration of each SFS file pool so that it reflects the actual current state of that file pool. To prevent outside allocations, make CA VM:Director the only SFS administrator defined for each file pool.

Resynchronizing the CA VM:Director configuration of SFS works much like the automatic configuration of CA VM:Director for SFS, with the following differences:

SFS manager authority

If an SFS manager no longer has any space allocated in the specified file pool or in a particular user storage group in the specified file pool, CA VM:Director does not remove that manager’s authority to that file pool or that user storage group.

For example, SFS manager DSTREET is authorized to allocate space from user storage group 2 of file pool VMPROD. The only user ID she manages that used this user storage group is MARYR, who owned 330 blocks of file space in this user storage group. However, MARYR no longer owns space in this storage group, but is instead using 250 blocks of file space in user storage group 4:

You resynchronize the CA VM:Director configuration for file pool VMPROD, and DSTREET comes out of the resynchronization with allocation authority for both user storage group 2 and user storage group 4, even though none of the user IDs she manages now uses space in user storage group 2. She can allocate no space from user storage group 4, which the resynchronization added to her list of user storage groups, because her allocation limit in this newly added user storage group is 0 (this is always the case for user storage groups added to an SFS manager during resynchronization):

Overallocation of space in user storage groups

If user IDs using the file pool have more space allocated to them in a given user storage group than their SFS managers are allowed to allocate through CA VM:Director, their allocations are summed and listed in their managers’ current allocations, but their managers’ allocation limits are not raised.

These managers cannot allocate more space in these overallocated file pools. They must ask their SFS administrators to raise their allocation limits beyond their current actual allocations if they need to allocate more space.

For example, manager DSTREET is authorized to allocate 500 blocks of space in user storage group 5 of file pool VMPROD:

Resynchronization of this file pool reveals that half a dozen of DSTREET’s user IDs were allocated 800 blocks of space in this user storage group. Her new information in CA VM:Director is as follows:

She is no longer able to allocate space in this user storage group unless the SFS administrator expands her authority.

User ID directory entries

The directory entries of user IDs that are enrolled in SFS and that are managed in SFS through CA VM:Director include *FP= special comments. One *FP= comment lists several file pools, depending on the length of the file pool names. (There is no correspondence between the number of *FP= comments in a directory entry and the number of file pools a user ID is authorized to use.) All user IDs’ directory entries are updated so that they have the correct *FP= special comments; file pools in which a user ID was enrolled outside CA VM:Director are added to that user ID’s *FP= special comment, and file pools in which a user ID no longer owns space are removed.

Important! Do not change these *FP= comments or remove them from directory entries. Doing so invalidates the information CA VM:Director has about SFS and so makes SFS administration through CA VM:Director incomplete. For more information about this special comment, see *FP= (File Pool) in Special Comment Reference.