You can name your volumes anything you choose, subject to a few restrictions:

It is best to assign volume names that indicate the type of data they contain, and to use similar names for volumes with similar contents. It is also helpful if the volume name is similar to (or at least has elements in common with) the name of the directory at which it is mounted. Understanding the pattern then enables you accurately to guess what a volume contains and where it is mounted.

Many cells find that the most effective volume naming scheme puts a common prefix on the names of all related volumes. Table 1 describes the recommended prefixing scheme.

Table 2 is a more specific example for a cell's rs_aix42 system volumes and directories:

There are several advantages to this scheme:

If your cell is large enough to make it practical, consider grouping related volumes together on a partition. In general, you need at least three file server machines for volume grouping to be effective. Grouping has several advantages, which are most obvious when the file server machine becomes inaccessible:

The advantages of grouping related volumes on a partition do not necessarily extend to the grouping of all related volumes on one file server machine. For instance, it is probably unwise in a cell with two file server machines to put all system volumes on one machine and all user volumes on the other. An outage of either machine probably affects everyone.

Admittedly, the need to move volumes for load balancing purposes can limit the practicality of grouping related volumes. You need to weigh the complementary advantages case by case.

As discussed in Replication, replication refers to making a copy, or clone, of a read/write source volume and then placing the copy on one or more additional file server machines. Replicating a volume can increase the availability of the contents. If one file server machine housing the volume becomes inaccessible, users can still access the copy of the volume stored on a different machine. No one machine is likely to become overburdened with requests for a popular file, either, because the file is available from several machines.

However, replication is not appropriate for all cells. If a cell does not have much disk space, replication can be unduly expensive, because each clone not on the same partition as the read/write source takes up as much disk space as its source volume did at the time the clone was made. Also, if you have only one file server machine, replication uses up disk space without increasing availability.

Replication is also not appropriate for volumes that change frequently. You must issue the vos release command every time you need to update a read-only volume to reflect changes in its read/write source.

For both of these reasons, replication is appropriate only for popular volumes whose contents do not change very often, such as system binaries and other volumes mounted at the upper levels of your filespace. User volumes usually exist only in a read/write version since they change so often.

If you are replicating any volumes, you must replicate the root.afs and root.cell volumes, preferably at two or three sites each (even if your cell only has two or three file server machines). The Cache Manager needs to pass through the directories corresponding to the root.afs and root.cell volumes as it interprets any pathname. The unavailability of these volumes makes all other volumes unavailable too, even if the file server machines storing the other volumes are still functioning.

Another reason to replicate the root.afs volume is that it can lessen the load on the File Server machine. The Cache Manager has a bias to access a read-only version of the root.afs volume if it is replicate, which puts the Cache Manager onto the read-only path through the AFS filespace. While on the read-only path, the Cache Manager attempts to access a read-only copy of replicated volumes. The File Server needs to track only one callback per Cache Manager for all of the data in a read-only volume, rather than the one callback per file it must track for read/write volumes. Fewer callbacks translate into a smaller load on the File Server.

If the root.afs volume is not replicated, the Cache Manager follows a read/write path through the filespace, accessing the read/write version of each volume. The File Server distributes and tracks a separate callback for each file in a read/write volume, imposing a greater load on it.

For more on read/write and read-only paths, see The Rules of Mount Point Traversal.

It also makes sense to replicate system binary volumes in many cases, as well as the volume corresponding to the /afs/cellname/usr directory and the volumes corresponding to the /afs/cellname/common directory and its subdirectories.

It is a good idea to place a replica on the same partition as the read/write source. In this case, the read-only volume is a clone (like a backup volume): it is a copy of the source volume's vnode index, rather than a full copy of the volume contents. Only if the read/write volume moves to another partition or changes substantially does the read-only volume consume significant disk space. Read-only volumes kept on other servers' partitions always consume the full amount of disk space that the read/write source consumed when the read-only volume was created.

You cannot have a replica volume on a different partition of the same server hosting the read/write volume. "Cheap" read-only volumes must be on the same partition as the read/write; all other read-only volumes must be on different servers.

Every AFS volume has associated with it a quota that limits the amount of disk space the volume is allowed to use. To set and change quota, use the commands described in Setting and Displaying Volume Quota and Current Size.

By default, every new volume is assigned a space quota of 5000 KB blocks unless you include the -maxquota argument to the vos create command. Also by default, the ACL on the root directory of every new volume grants all permissions to the members of the system:administrators group. To learn how to change these values when creating an account with individual commands, see To create one user account with individual commands. When using uss commands to create accounts, you can specify alternate ACL and quota values in the template file's V instruction; see Creating a Volume with the V Instruction.