| About Volumes | ||
|---|---|---|
 | Chapter 5. Managing Volumes |  |
| About Volumes | ||
|---|---|---|
| | Chapter 5. Managing Volumes | |
An AFS volume is a logical unit of disk space that functions like a container for the files in an AFS directory, keeping them all together on one partition of a file server machine. To make a volume's contents visible in the cell's file tree and accessible to users, you mount the volume at a directory location in the AFS filespace. The association between the volume and its location in the filespace is called a mount point, and because of AFS's internal workings it looks and acts just like a standard directory element. Users can access and manipulate a volume's contents in the same way they access and manipulate the contents of a standard UNIX directory. For more on the relationship between volumes and directories, see About Mounting Volumes.
Many of an administrator's daily activities involve manipulating volumes, since they are the basic storage and administrative unit of AFS. For a discussion of some of the ways volumes can make your job easier, see How Volumes Improve AFS Efficiency.
There are three types of volumes in AFS, as described in the following list:
The single read/write version of a volume houses the modifiable versions of the files and directories in that volume. It is often referred to as the read/write source because volumes of the other two types are derived from it by a copying procedure called cloning. For instructions on creating read/write volumes, see Creating Read/write Volumes.
A read-only volume is a copy of the read/write source volume and can exist at multiple sites (a site is a particular partition on a particular file server machine). Placing the same data at more than one site is called replication; see How Volumes Improve AFS Efficiency. As the name suggests, a read-only volume's contents do not change automatically as the read/write source changes, but only when an administrator issues the vos release command. For users to have a consistent view of the AFS filespace, all copies of the read-only volume must match each other and their read/write source. All read-only volumes share the same name, which is derived by adding the .readonly extension to the read/write source's name. For instructions on creating of read-only volumes, see Replicating Volumes (Creating Read-only Volumes).
A backup volume is a clone of the read/write source volume and is stored at the same site as the source. A backup version is useful because it records the state of the read/write source at a certain time, allowing recovery of data that is later mistakenly changed or deleted (for further discussion see How Volumes Improve AFS Efficiency). A backup volume's name is derived by adding the .backup extension to the read/write source's name. For instructions on creating of backup volumes, see Creating Backup Volumes.
A backup volume is not the same as the backup of a volume transferred to tape using the AFS Backup System, although making a backup version of a volume is usually a stage in the process of backing up the volume to tape. For information on backing up a volume using the AFS Backup System, see Backing Up Data.
As noted, the three types of volumes are related to one another: read-only and backup volumes are both derived from a read/write volume through a process called cloning. Read-only and backup volumes are exact copies of the read/write source at the time they are created.
Volumes make your cell easier to manage and more efficient in the following three ways:
Volumes are easy to move between partitions, on the same or different machines, because they are by definition smaller than a partition. Perhaps the most common reasons to move volumes are to balance the load among file server machines or to take advantage of greater disk capacity on certain machines. You can move volumes as often as necessary without disrupting user access to their contents, because the move procedure makes the contents unavailable for only a few seconds. The automatic tracking of volume locations in the Volume Location Database (VLDB) assures that access remains transparent. For instructions on moving volumes, see Moving Volumes.
Volumes are the unit of replication in AFS. Replication refers to creating a read-only clone from the read/write source and distributing of the clone to one or more sites. Replication improves system efficiency because more than one machine can fill requests for popular files. It also boosts system reliability by helping to keep data available in the face of machine or server process outage. In general, volumes containing popular application programs and other files that do not change often are the best candidates for replication, but you can replicate any read/write volume. See Replicating Volumes (Creating Read-only Volumes).
Volumes are the unit of backup in AFS, in two senses. You can create a backup volume version to preserves the state of a read/write source volume at a specified time. You can mount the backup version in the AFS filespace, enabling users to restore data they have accidentally changed or deleted without administrator assistance, which frees you for more important jobs. If you make a new backup version of user volumes once a day (presumably overwriting the former backup), then users are always be able to retrieve the previous day's version of a file. For instructions, see Creating Backup Volumes.
Backup also refers to using the AFS Backup System to store permanent copies of volume contents on tape or in a special backup data. See Configuring the AFS Backup Systemand Backing Up and Restoring AFS Data.
The Volume Location Database (VLDB) includes entries for every volume in a cell. Perhaps the most important information in the entry is the volume's location, which is key to transparent access to AFS data. When a user opens a file, the Cache Manager consults the Volume Location (VL) Server, which maintains the VLDB, for a list of the file server machines that house the volume containing the file. The Cache Manager then requests the file from the File Server running on one of the relevant file server machines. The file location procedure is invisible to the user, who only needs to know the file's pathname.
The VLDB volume entry for a read/write volume also contains the pertinent information about the read-only and backup versions, which do not have their own VLDB entries. (The rare exception is a read-only volume that has its own VLDB entry because its read/write source has been removed.) A volume's VLDB entry records the volume's name, the unique volume ID number for each version (read/write, read-only, backup, and releaseClone), a count of the number of sites that house a read/write or read-only version, and a list of the sites.
To display the VLDB entry for one or more volumes, use the vos listvldb command as described in To display VLDB entries. To display the VLDB entry for a single volume along with its volume header, use the vos examine command as described in To display one volume's VLDB entry and volume header. (See the following section for a description of the volume header.)
Whereas all versions of a volume share one VLDB entry, each volume on an AFS server partition has its own volume header, a data structure that maps the files and directories in the volume to physical memory addresses on the partition that stores them. The volume header binds the volume's contents into a logical unit without requiring that they be stored in contiguous memory blocks. The volume header also records the following information about the volume, some of it redundant with the VLDB entry: name, volume ID number, type, size, status (online, offline, or busy), space quota, timestamps for creation date and date of last modification, and number of accesses during the current day.
To display the volume headers on one or more partitions, use the vos listvol command as described in To display volume headers. To display the VLDB entry for a single volume along with its volume header, use the vos examine command as described in To display one volume's VLDB entry and volume header.
It is vital that the information in the VLDB correspond to the status of the actual volumes on the servers (as recorded in volume headers) as much of the time as possible. If a volume's location information in the VLDB is incorrect, the Cache Manager cannot find access its contents. Whenever you issue a vos command that changes a volume's status, the Volume Server and VL Server cooperate to keep the volume header and VLDB synchronized. In rare cases, the header and VLDB can diverge, for instance because a vos operation halts prematurely. For instructions on resynchronizing them, see Synchronizing the VLDB and Volume Headers.
To make a volume's contents visible in the cell's file tree and accessible to users, you mount the volume at a directory location in the AFS filespace. The association between the volume and its location in the filespace is called a mount point. An AFS mount point looks and functions like a regular UNIX file system directory, but structurally it is more like a symbolic link that tells the Cache Manager the name of the volume associated with the directory. A mount point looks and acts like a directory only because the Cache Manager knows how to interpret it.
Consider the common case where the Cache Manager needs to retrieve a file requested by an application program. The Cache Manager traverses the file's complete pathname, starting at the AFS root (by convention mounted at the /afs directory) and continuing to the file. When the Cache Manager encounters (or crosses) a mount point during the traversal, it reads it to learn the name of the volume mounted at that directory location. After obtaining location information about the volume from the Volume Location (VL) Server, the Cache Manager fetches the indicated volume and opens its root directory. The root directory of a volume lists all the files, subdirectories, and mount points that reside in it. The Cache Manager scans the root directory listing for the next element in the pathname. It continues down the path, using this method to interpret any other mount points it encounters, until it reaches the volume that houses the requested file.
Mount points act as the glue that connects the AFS file space, creating the illusion of a single, seamless file tree even when volumes reside on many different file server machines. A volume's contents are visible and accessible when the volume is mounted at a directory location, and are not accessible at all if the volume is not mounted.
You can mount a volume at more than one location in the file tree, but this is not recommended for two reasons. First, it distorts the hierarchical nature of the filespace. Second, the Cache Manager can become confused about which pathname it followed to reach the file (causing unpredictable output from the pwd command, for example). However, if you mount a volume at more than one directory, the access control list (ACL) associated with the volume's root directory applies to all of the mount points.
There are several types of mount points, each of which the Cache Manager handles in a different way and each of which is appropriate for a different purpose. See Mounting Volumes.
A read/write volume's name can be up to 22 characters in length. The Volume Server automatically adds the .readonly and .backup extensions to read-only and backup volumes respectively. Do not explicitly add the extensions to volume names, even if they are appropriate.
It is conventional for a volume's name to indicate the type of data it houses. For example, it is conventional to name all user volumes user.username where username is the user's login name. Similarly, many cells elect to put system binaries in volumes with names that begin with the system type code. For a list of other naming conventions, see Creating Volumes to Simplify Administration.
| |  | |
| Chapter 5. Managing Volumes |  | Creating Read/write Volumes |