SFS Overview

Contents
vmx32besp
Contents
 
 
3
 
 
You can have 
VM:Secure
 manage the enrollment of users and allocation of space in SFS by implementing the various SFS configuration and management functions in 
VM:Secure
. These functions enable you to describe your SFS configuration to 
VM:Secure
, including which file pools and storage groups you want to manage through 
VM:Secure
 and how much space can be allocated in each storage group. They further let you specify who can enroll users under 
VM:Secure
 management, in which file pools they can enroll users, and how much space they can allocate to users in each storage group.
The user IDs that describe your SFS configuration to 
VM:Secure
 are SFS administrators. The user IDs that perform user administration tasks in SFS through 
VM:Secure
 management are SFS managers.
All but one of the configuration functions for 
VM:Secure
 SFS are performed by SFS administrators. The only function that must be performed by the 
VM:Secure
 system administrator rather than the SFS administrator is identifying the SFS administrators to 
VM:Secure
. Most of the daily management functions for SFS using 
VM:Secure
 are performed by SFS managers.
SFS Administrators
SFS administrators in 
VM:Secure
 perform three primary functions:
  • Identify to 
    VM:Secure
     the SFS file pools and user storage groups on your system that it will manage
  • Designate existing directory managers as SFS managers, and specify which file pools, storage groups, and default allocations those managers can use when they allocate SFS space under 
    VM:Secure
     
  • Enroll any user ID in any SFS file pools under 
    VM:Secure
     control, giving that user ID any amount of file space in any storage group
 SFS Administrator tasks 
Administrators can also remove SFS manager authority from user IDs and change or remove the file space allocated to individual user IDs.
SFS Managers
SFS managers in 
VM:Secure
 are any directory managers that an SFS administrator designates to be SFS managers. Managers can add, enroll, or delete any user ID that they can manage in SFS.
The file pools, user storage groups, file space size, and maximum file space size that an SFS manager can assign to its subordinate user IDs are determined by an SFS administrator.
SFS managers can do the following:
  • Enroll in SFS the user IDs they manage as directory managers
  • Change SFS allocations for the user IDs they manage by giving those user IDs space in additional file pools or in file pools those user IDs already use
  • Remove user IDs’ allocations in individual file pools or remove those user IDs from SFS entirely
If the SFS administrator wants other people to oversee the daily administration of user IDs and SFS space, the administrator must specify SFS managers to perform this user administration.
 
Enrollment Limits
 
An SFS administrator sets up an SFS manager with limits. These limits include the following:
  • From which file pools this manager is authorized to allocate space
  • From which user storage groups in these file pools this manager is authorized to allocate space
  • How much space this manager is authorized to allocate from each user storage group to all managed user IDs.
 
Example:
 
The SFS administrator authorized SFS manager BGEDDES to allocate space in the following file pools. The amount of space BGEDDES is authorized to allocate for each user storage group in each of these file pools appears in parentheses following the file pools:
 
SFS Manager:
 
 
BGEDDES
 
File pools:
VMXA
VMXB
VMXC
VMXD
User storage groups (number of blocks):
4 (5,000)
2 (10,000)
2 (8,000)
3 (5,000)
 
5 (10,000)
3 (9,000)
4 (15,000)
4 (10,000)
 
7 (50,000)
4 (1,000)
5 (15,000)
5 (1,500)
These file pools, the user storage groups, and the maximum allocable space BGEDDES has in each user storage group are his enrollment limits.
Summed Enrollment Limits for All SFS Managers
The space that an SFS administrator authorizes each SFS manager to allocate in a user storage group is literally that amount of space in the user storage group, up to his limit, and not a percentage of the total space available in the user storage group. (There is another factor determining how much space SFS managers can allocate, but more on this later.)
For example, the SFS administrator can specify that each of three managers can allocate 1,000 blocks of space in User Storage Group 3, which has 1,000 blocks of space:
 Allocation of 4K physical blocks 
Notice that the three managers are allowed to allocate a total of 3,000 blocks (their allocable space is 1,000 blocks + 1,000 blocks + 1,000 blocks) even though the available space is 1,000. This is because the managers’ allocable space is not cumulative.
What their limits on allocation really mean is:
  • Manager A is allowed to allocate up to 1,000 blocks of space in User Storage Group 3, for use by Manager A’s user IDs only if the space is available when they want it
  • Manager B is allowed to allocate up to 1,000 blocks of space in User Storage Group 3, for use by Manager B’s user IDs only if the space is available when they want it
  • Manager C is allowed to allocate up to 1,000 blocks of space in User Storage Group 3, for use by Manager C’s user IDs only if the space is available when they want it.
 
Default Enrollment Values
 
An SFS administrator can make an SFS manager’s enrollment functions easier by setting up enrollment defaults for that manager. Several defaults are available for an SFS administrator to define for an SFS manager, such as a default enrollment file pool, a default user storage group in each file pool, and a default allocation size in each user storage group.
The administrator sets up enrollment defaults when defining SFS managers, and can change the defaults at any time. The managers must have allocation authority to the file pool assigned to them as the default file pools, and to each user storage group defined as their default user storage group for each file pool. Additionally, they must be able to allocate at least as much space in each user storage group as the default amount of space set up in their defaults.
If an SFS manager accepts the enrollment defaults as the enrollment values for a user ID, they are actually passed on to SFS.
For example, these are the default enrollment values for SFS manager BGEDDES:
SFS manager:
 
BGEDDES
 
Default file pool:
VMXA
Default user storage group:
4
Default allocation size:
100 blocks
Her authority includes allocable space of 5,000 blocks in user storage group 4 in file pool VMXA, so these default enrollment values will help her enroll several user IDs in SFS easily.
When BGEDDES enrolls a user ID in SFS, these enrollment defaults are the ones that 
VM:Secure
 displays for that user ID. She can change these default values for this user ID at the time she enrolls this user ID simply by typing over the default values she wants to change. For example:
 
SFS manager:
 
 
BGEDDES
 
Enroll user ID:
SREED
Initial enrollment values for user ID SREED (BGEDDES’s default enrollment values):
Initial enrollment values for user ID SREED (BGEDDES’s default enrollment values):
Final enrollment values for user ID SREED (BGEDDES’s changes at enrollment time):
Final enrollment values for user ID SREED (BGEDDES’s changes at enrollment time):
File pool:
VMXA
File pool:
VMXB
User storage group:
4
User storage group:
2
Allocation size:
100 blocks
Allocation size:
500 blocks
SFS itself now indicates that user ID SREED has 500 blocks of space in user storage group 2 of file pool VMXB.
Any subsequent changes an SFS administrator makes to BGEDDES’s default enrollment values do not affect any user IDs that BGEDDES already enrolled in SFS with her previous default enrollment values.
If an administrator sets up a manager’s enrollment defaults and then removes the default file pool from that manager’s authority, the administrator will erase that manager’s enrollment defaults. This does not affect any user IDs BGEDDES already enrolled in SFS with her previous default enrollment values, but does prevent her from enrolling user IDs in SFS. The SFS administrator must assign new enrollment defaults to this manager before she can enroll user IDs again.
Product Configuration for SFS User Administration
The 
VM:Secure
 configuration for SFS consists of two parts:
  • Description of the SFS file pools and the user storage groups in those file pools
  • Definition of the VM user IDs that will be SFS administrators and SFS managers, and the scopes of the managers’ authorities
The description of a file pool is simply the file pool’s name. The description of a user storage group is the user storage group’s number under its file pool and its allocation limit.
The description of SFS to 
VM:Secure
 includes only the file pools you defined for SFS that you want 
VM:Secure
 to manage. For each file pool described, 
VM:Secure
 needs only the user storage groups you want it to manage.
The definition of SFS administrators and SFS managers in 
VM:Secure
 identifies which user IDs can change the 
VM:Secure
 configuration for SFS and which user IDs can manage user IDs under SFS. SFS administrators’ requirements and responsibilities are explained in the section, SFS Administrators, earlier in this section; SFS managers’ requirements and responsibilities are explained in the SFS Managers section.
 
Automatic Configuration
 
If SFS is already in use at your site when you install 
VM:Secure
, you can identify each file pool that you want 
VM:Secure
 to manage, then have 
VM:Secure
 determine the configuration of this file pool and the user IDs who use and manage it.
This function is available on the same screen at which you identify file pools to 
VM:Secure
, through the PF2(Auto - Config) key.
 For more information about the actual procedure, see Adding a File Pool and User Storage Groups to the Product Configuration.
As part of this determination of the SFS configuration for each specified file pool, 
VM:Secure
 checks the following:
  •  
    All user storage groups
    All user storage groups that 
    VM:Secure
     finds in the specified file pool that are in use by valid user IDs are identified to 
    VM:Secure
     so that user IDs can be assigned space in them through 
    VM:Secure
    . If there are user storage groups that you do not want managed through 
    VM:Secure
    , you can remove them from the 
    VM:Secure
     information after it completes its automatic configuration.
    The allocation limit 
    VM:Secure
     sets for each user storage group identified to 
    VM:Secure
     is 300 percent. This means that each user storage group under the control of 
    VM:Secure
    , can be allocated to 300 percent of its physical space. (The section, Allocation of Space in User Storage Groups, explains how user storage groups can be allocated beyond their physical sizes.)
  •  
    User IDs currently enrolled in SFS
    The names of all user IDs currently using that file pool are added to the 
    VM:Secure
     list of enrolled user IDs. The user storage groups in which these user IDs are currently using space are listed in 
    VM:Secure
     as the ones they are authorized to use, and the amount of space they are currently using is their limit.
    For instance, if user ID FSTONE is using 15 K blocks of space in user storage group 3 in file pool VMX004, FSTONE’s enrollment information in 
    VM:Secure
     is for file pool VMX004, user storage group 3, with a space limit of 15 K blocks.
  •  
    Directory managers for those user IDs
    For each file space that is owned by a VM user ID, 
    VM:Secure
     finds the name of that user ID’s directory manager and adds that directory manager to 
    VM:Secure
     as an SFS manager. Further, those VM user IDs are assigned their directory managers as their SFS managers.
Authority of SFS Managers Defined Through Automatic Configuration
The authority an SFS manager has, as defined through the 
VM:Secure
 automatic configuration, is restricted to the file space used by the user IDs that SFS manager manages.
The first user ID identified as being managed by a particular directory manager causes that directory manager to also be made an SFS manager. The limits of that SFS manager’s authority are the file pool and the user storage group in which that user ID’s file space is located.
 
Example:
 
The automatic configuration of the file pool VMLGL finds the following for user ID PMASON, who is managed by DSTREET:
 
User ID:
 
 
PMASON
 
Directory manager:
DSTREET
File pool:
VMLGL
User storage group:
4
Space allocated:
80 blocks
Therefore, automatic configuration makes DSTREET an SFS manager, and authorizes DSTREET to enroll user IDs in user storage group 4 of file pool VMLGL:
 
User ID:
 
 
PMASON
 
Directory manager:
DSTREET
SFS manager:
DSTREET
File pool:
VMLGL
File pool:
VMLGL
User storage group:
4
User storage group:
4
Space allocated:
80 blocks
 
 
Further, now that DSTREET can allocate space in file pool VMLGL, user storage group 4, 
VM:Secure
 assigns DSTREET a default allocation size (the amount of space DSTREET allocates by default to users she enrolls in VMLGL user storage group 4) and an allocation limit for that user storage group.
The default allocation size is 150 blocks, and the allocation limit is equal to the amount of space already allocated to PMASON:
 
User ID:
 
 
PMASON
 
Directory manager:
DSTREET
SFS manager:
DSTREET
File pool:
VMLGL
File pool:
VMLGL
User storage group:
4
User storage group:
4
Space allocated:
80 blocks
Default allocation:
150 blocks
 
 
Allocation limit:
80 blocks
All subsequent user IDs identified as being managed by that same directory manager, who is now an SFS manager, cause that SFS manager’s limits of SFS authority to be expanded. The limits are expanded by the amount of space allocated to those user IDs in the current file pool, which is being automatically configured. For example, if automatic configuration next finds that the directory manager DSTREET also manages user ID PDRAKE, and PDRAKE is using 250 blocks of space in file pool VMLGL, user storage group 4, DSTREET’s allocation authority is now expanded to this:
 
SFS manager:
 
 
DSTREET
 
File pool:
VMLGL
User storage group:
4
Default allocation:
150 blocks
Allocation limit:
330 blocks
If the SFS administrator runs automatic configuration on several file pools, the limits of an SFS manager are expanded also in the number of file pools if other file pools include space owned by user IDs that are managed by this SFS manager. For example, automatic configuration of the file pool VMPROD also finds the following:
 
User ID:
 
 
MARYR
 
Directory manager:
DSTREET
File pool:
VMPROD
User storage group:
2
Space allocated:
500 blocks
Because MARYR is also managed by DSTREET, DSTREET now becomes authorized to enroll user IDs in user storage group 2 of file pool VMPROD. DSTREET is assigned a default allocation size of 150 blocks in this user storage group (this is always the default allocation size for automatically configured SFS managers), and an allocation limit of 500 blocks (this is the current amount of space used by user ID MARYR):
 
SFS manager:
 
 
DSTREET
 
File pool:
VMLGL
User storage group:
4
Default allocation:
150 blocks
Allocation limit:
330 blocks
File pool:
VMPROD
User storage group:
2
Default allocation:
150 blocks
Allocation limit:
500 blocks
 
Subsequent Configuration Changes
 
You can change the 
VM:Secure
 configuration for SFS at any time, for instance, when you add file pools or need to remove an SFS manager. Remember, these changes may affect what your SFS managers, and sometimes the user IDs they manage, can do. For example, if you add file pools, you need to allow SFS managers to assign that space to have that space managed through 
VM:Secure
. If you need to remove an SFS manager, you must move all of that manager’s reporting user IDs to another manager first.
Information that you change about SFS in the 
VM:Secure
 configuration (after the automatic configuration) include any of the following:
  • Add or remove user storage groups within known file pools
  • Change the allocation limits on user storage groups
  • Add or remove SFS managers
  • Change the default file pool or allocation size for an SFS manager
 
Resynchronizing the Product Configuration of SFS
 
SFS allocations that anyone makes outside 
VM:Secure
 are unknown to 
VM:Secure
, making its SFS administration information unreliable. Therefore, you must verify that no allocations are made outside 
VM:Secure
 or resynchronize the 
VM:Secure
 configuration of each SFS file pool so that it reflects the actual current state of that file pool. To prevent outside allocations, make 
VM:Secure
 the only SFS administrator defined for each file pool.
Resynchronizing the 
VM:Secure
 configuration of SFS works much like the automatic configuration of 
VM:Secure
 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, 
    VM:Secure
     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:
 
User ID:
 
 
MARYR
 
Directory manager: 
DSTREET
 
 
 
 
Old Allocation:
 
New Allocation:
 
File pool:
VMPROD
File pool:
VMPROD
User storage group:
2
User storage group:
4
Space allocated:
500 blocks
Space allocated:
250 blocks
You resynchronize the 
VM:Secure
 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):
 
SFS manager:
 
 
DSTREET
 
File pool:
VMPROD
User storage group:
2
Default allocation:
150 blocks
Allocation limit:
330 blocks
File pool:
VMPROD
User storage group:
4
Default allocation:
150 blocks
Allocation limit:
0 blocks
  •  
    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 
    VM:Secure
    , 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:
 
SFS manager:
 
 
DSTREET
 
Allocable file pool:
VMPROD
User storage group:
5
Allocation limit:
500 blocks
Current allocation:
300 blocks
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 
VM:Secure
 is as follows:
 
SFS manager:
 
 
DSTREET
 
Allocable file pool:
VMPROD
User storage group:
5
Allocation limit:
500 blocks
Current allocation:
800 blocks
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 
    VM:Secure
     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 
    VM:Secure
     are added to that user ID’s *FP= special comment, and file pools in which a user ID no longer owns space are removed.
Do not change these *FP= comments or remove them from directory entries. Doing so invalidates the information 
VM:Secure
 has about SFS and so makes SFS administration through 
VM:Secure
 incomplete. For more information about this special comment, see *FP= (File Pool) in Special Comment Reference.
Allocation of Space in User Storage Groups
An SFS administrator can specify an allocation limit for each user storage group in any file pool known to 
VM:Secure
. The allocation limit is the amount of storage that 
all
 SFS managers can allocate from a particular user storage group, and is normally greater than the physical amount of storage.
For instance, you can set the allocation limit of a user storage group to 100 percent. This means that SFS managers can allocate the space in this user storage group up to its physical size. If the size is 10,000 blocks, then SFS managers can allocate 10,000 blocks of its space. However, you can also set the allocation limit of a user storage group to 500 percent. In this case, SFS managers can allocate the space in this user storage group up to five times its physical size; if the size is 10,000 blocks, then SFS managers can allocate 50,000 blocks of space.
Allocation of a user storage group beyond its physical size allows for the most efficient use of space on your system. It is similar to the practice of overbooking airline flights: not everyone with an airline reservation shows up for the flight, so that reserving several more seats than actually exist on a plane increases the chances that the flight will be as full as possible. Similarly, not every user ID with an allocation in a user storage group uses its full amount of space, so that allocating more space than actually exists in a user storage group increases the chances that the space will be used as fully as possible.
You can allow a user storage group to be allocated by any percentage of the physical amount of space, from 100 percent to 9999 percent, where 100 percent means that the space can be allocated only to its physical size.
Because this allocation limit is a percentage of the user storage group’s physical size, you can increase the size of a user storage group without having to adjust this allocation limit. For instance, if you allow 200 percent allocation for a user storage group that has 10,000 blocks, that storage group has 20,000 blocks of effectively allocable space. If you later increase the physical size of this storage group to 25,000 blocks, its effectively allocable space becomes 50,000 blocks.
 
Interaction Between an SFS Manager’s Allocation Limit and a User Storage Group’s Allocation Limit
 
The combination of allocation limits on user storage groups and allocation limits on managers allows for the most efficient distribution and use of space on your system. These limits allow for the incomplete use that user IDs make of the space they can use in a user storage group.
 
VM:Secure
 does not know how many blocks of space exist in a user storage group, or how many are available at any time, until it tries to process an SFS manager’s request to allocate space to a user ID. 
At that time
, it considers two factors:
  • Does this allocation raise the SFS manager’s allocation from the specified user storage group beyond the SFS manager’s allocation limit?
  • Does this allocation raise the user storage group’s allocation beyond its allocation limit?
 
Example:1
 
The following tables show the size and limits for User Storage Group 3 and the amount of space Manager A, Manager B, and Manager C can allocate from User Storage Group 3:
 
User Storage Group Limits
 
 
Effective Allocable Space (4K blocks)
 
User Storage Group 3
 
Physical size (4K blocks)
          1,000
Allocation limit (%)
           300
Effective allocable space (4K blocks)
          3,000
 
SFS Manager Limits for User Storage Group 3
 
 
Effective Allocable Space (4K blocks)
 
Manager A allocable space (4K blocks)
          1,000
Manager B allocable space (4K blocks)
          1,500
Manager C allocable space (4K blocks)
          1,500
Effective allocable space (4K blocks)
          4,000
If the physical size of user storage group 3 remains 1,000 blocks and its allocation limit remains 300 percent, at least one of these managers will not be able to allocate his full amount of allocable space. This is because the managers’ effective allocable space exceeds the user storage group’s effective allocable space.
 
Example:2
 
The SFS configuration known to 
VM:Secure
 includes the following:
 
 
 
SFS manager:
 
 
BGEDDES
 
File pool:
VMXA
Allocable file pool:
VMXA
User storage group:
2
User storage group:
2
Allocation limit:
 
150%
 
Allocation limit:
25000 blocks
SFS manager BGEDDES enrolls user ID SREED in user storage group 2, allocating him 3,000 blocks of space, with this command:
vmsecure
enroll sreed 3000 2 vmxa
 
VM:Secure
 finds the following in processing this command request:
 
 
 
SFS manager:
 
 
BGEDDES
 
File pool:
VMXA
Allocable file pool:
VMXA
User storage group:
2
User storage group:
2
Allocation limit:
150
%
 
Allocation limit:
25000 blocks
Current size:
100,000 blocks
 
 
Current allocation:
75,000 blocks
Current allocation:
20,000 blocks
Current allocation limit:
150,000 blocks
Allocation limit:
25,000 blocks
It then calculates the proposed values and determines the request can be filled:
Current allocation limit:
150,000 blocks
Allocation limit:
25,000 blocks
Proposed allocation:
78,000 blocks
Proposed allocation:
23,000 blocks
Less than current allocation limit? YES
Less than current allocation limit? YES