AFS organization: Cells and Volumes

The largest element in the AFS structure is a cell. A cell constitutes a separate administrative domain of authority. Each cell keeps its own list of users, groups, and system administrators. That means that a user from one cell might not exist in another cell. In that case, [s]he will only be able to access the files in directories that have the appropriate permission set to system:anyuser. An example of a cell is the athena.mit.edu cell (this is the cell that contains Athena user home directories, along with course lockers and most Athena software), or SIPB's own sipb.mit.edu cell.

Each cell is made up of volumes. A volume is a collection of files and directories that are grouped together and given a name. Your home directory is a volume, the volume user.username. Once created, each volume can (as a unit) be moved from one server to another, backed up, replicated or destroyed. Files and directories can be created, modified or deleted only in an existing volume.

The whole multi-cell AFS directory structure is accessible through the directory /afs. The volume in /afs is named root.afs. The directory /afs contains the mountpoints to the root volumes for each cell, which are usually named cellname:root.cell. These volumes act like directories, and may in turn contain the mountpoints to other volumes. Thus you can cd to /afs/athena.mit.edu/user/a/u/autumn, and be ``connected to'' the volume user.autumn in the cell athena.mit.edu. For the Athena cell, you can use just /afs/athena/ instead of /afs/athena.mit.edu/ since the root.afs directory contains a symbolic link from one to the other. The same goes for other .mit.edu cells, too: /afs/sipb.mit.edu/ and /afs/sipb/ are the same.

Because of the way AFS works, you do not have to explicitly attach any volume or filesystem that is on AFS in order to have access to it. All you need, in order to access a file, is the pathname of the file. For example, if I wanted to get to the games locker, I could type cd /afs/athena/contrib/games, without having to do attach games. However, this does not mean that you shouldn't, in some circumstances, attach or add a volume. For one thing, attaching a volume subscribes you to some classes of Zephyr messages, so you will be automatically notified if a portion of AFS\ you are using is becoming unavailable (e.g., due to a server shutdown). Some programs will not work unless certain lockers are attached. Also, volumes that are in other cells (outside the athena cell) will not recognize you or give you your proper permissions unless you are authenticated to that cell (except for volumes where the appropriate permissions are given to system:anyuser). To do this you need to get tokens for the cell, which are analogous to separate Kerberos tickets for individual NFS fileservers. Attaching or adding a volume will automatically get you tokens (read the manual pages for add and attach for more information). Another way to get tokens is to use the commandaklog, described later in this document.