Text-only	Table of Contents (frame/ no frame)
(6) Volumes

Volumes may be mounted anywhere in AFS space, including multiple mount points (although this is confusing). Disk quotas are applied at the volume level. The command to check on the current quota status is subcommand listquota to fs, i.e. fs_listquota.

The ACL (Access Control List) at the top level of the volume is important, since it may be mounted in a location with less restrictive parent ACLs than intended. For example, a user volume might be inaccessible to unauthenticated users by being mounted below a private directory. If the volume itself allows public read, it may be re-mounted inside a public directory and lose the protection.

Typically we use:

• One volume per user account for the home directory and everything below it
• One volume per user for mail delivery
• One volume per major application (e.g. Matlab, IDL etc.)
• One volume per architecture for locally added executables, etc.

Two special volumes always exist, and are replicated onto each file server for redundancy.

• root.afs: The top level directory in the AFS hierarchy. It contains the mount points for the local root.cell volume, and for any remote cells to which it may be desireable to connect.
• root.cell: The top level directory for the cell. All other volumes in the cell are mounted below this point.

When a program opens a file, the AFS client must first look up the location of the volume containing the file, then connect to the appropriate file server. When listing directory contents containing many volume mount points, many database lookups are needed. This metadata is cached, but performance can still be slow (e.g. ls -l /afs/northstar/ufac). Unfortunately GUI file managers love to do this, frequently.