You can often free up significant amounts of local disk space on AFS client machines by storing standard UNIX files in AFS and creating symbolic links to them from the local disk. The @sys pathname variable can be useful in links to system-specific files; see Using the @sys Variable in Pathnames.

There are two types of files that must actually reside on the local disk: boot sequence files needed before the afsd program is invoked, and files that can be helpful during file server machine outages.

During a reboot, AFS is inaccessible until the afsd program executes and initializes the Cache Manager. (In the conventional configuration, the AFS initialization file is included in the machine's initialization sequence and invokes the afsd program.) Files needed during reboot prior to that point must reside on the local disk. They include the following, but this list is not necessarily exhaustive.

The other type of files and programs to retain on the local disk are those you need when diagnosing and fixing problems caused by a file server outage, because the outage can make inaccessible the copies stored in AFS. Examples include the binaries for a text editor (such as ed or vi) and for the fs and bos commands. Store copies of AFS command binaries in the /usr/vice/etc directory as well as including them in the /usr/afsws directory, which is normally a link into AFS. Then place the /usr/afsws directory before the /usr/vice/etc directory in users' PATH environment variable definition. When AFS is functioning normally, users access the copy in the /usr/afsws directory, which is more likely to be current than a local copy.

As detailed in Making Other Cells Visible in Your Cell, you enable the Cache Manager to access a cell's AFS filespace by storing a list of the cell's database server machines in the local /usr/vice/etc/CellServDB file. The Cache Manager reads the list into kernel memory at reboot for faster retrieval. You can change the list in kernel memory between reboots by using the fs newcell command.

Because each client machine maintains its own copy of the CellServDB file, you can in theory enable access to different foreign cells on different client machines. This is not usually practical, however, especially if users do not always work on the same machine.

When creating symbolic links into AFS on the local disk, it is often practical to use the @sys variable in pathnames. The Cache Manager automatically substitutes the local machine's AFS system name (CPU/operating system type) for the @sys variable. This means you can place the same links on machines of various system types and still have each machine access the binaries for its system type. For example, the Cache Manager on a machine running AIX 4.2 converts /afs/example.com/@sys to /afs/example.com/rs_aix42, whereas a machine running Solaris 10 converts it to /afs/example.com/sun4x_510.

If you want to use the @sys variable, it is simplest to use the conventional AFS system type names as specified in the OpenAFS Release Notes. The Cache Manager records the local machine's system type name in kernel memory during initialization. If you do not use the conventional names, you must use the fs sysname command to change the value in kernel memory from its default just after Cache Manager initialization, on every client machine of the relevant system type. The fs sysname command also displays the current value; see Displaying and Setting the System Type Name.

In pathnames in the AFS filespace itself, use the @sys variable carefully and sparingly, because it can lead to unexpected results. It is generally best to restrict its use to only one level in the filespace. The third level is a common choice, because that is where many cells store the binaries for different machine types.

Multiple instances of the @sys variable in a pathname are especially dangerous to people who must explicitly change directories (with the cd command, for example) into directories that store binaries for system types other than the machine on which they are working, such as administrators or developers who maintain those directories. After changing directories, it is recommended that such people verify they are in the desired directory.

The Cache Manager stores a table of preferences for file server machines in kernel memory. A preference rank pairs a file server machine interface's IP address with an integer in the range from 1 to 65,534. When it needs to access a file, the Cache Manager compares the ranks for the interfaces of all machines that house the file, and first attempts to access the file via the interface with the best rank. As it initializes, the Cache Manager sets default ranks that bias it to access files via interfaces that are close to it in terms of network topology. You can adjust the preference ranks to improve performance if you wish.

The Cache Manager also uses similar preferences for Volume Location (VL) Server machines. Use the fs getserverprefs command to display preference ranks and the fs setserverprefs command to set them. See Maintaining Server Preference Ranks.