vos_release - Updates read-only volumes to match the read/write
source volume
vos release
-id <volume name or ID>
[-force] [-force-reclone]
[-cell <cell name>]
[-noauth] [-localauth]
[-verbose] [-encrypt] [-noresolve]
[-config <config directory>]
[-help]
vos rel
-i <volume name or ID>
[-force] [-force-r]
[-c <cell name>]
[-noa] [-l] [-v] [-e] [-nor]
[-co <config directory>]
[-h]
The vos release command copies the contents of the
indicated read/write source volume to each read-only site defined in the
source volume's Volume Location Database (VLDB) entry. (Use the vos
addsite command to define sites as necessary before issuing this
command). Each read-only copy has the same name as read/write source with
the addition of a ".readonly"
extension.
For users to have a consistent view of the file system, the
release of the new volume version must be atomic: either all read-only sites
receive the new version, or all sites keep the version they currently have.
The vos release command is designed to ensure that all copies
of the volume's read-only version match both the read/write source and each
other. In cases where problems such as machine or server process outages
prevent successful completion of the release operation, AFS uses two
mechanisms to alert the administrator.
First, the command interpreter generates an error message on the
standard error stream naming each read-only site that did not receive the
new volume version. Second, during the release operation the Volume Location
(VL) Server marks site definitions in the VLDB entry with flags
("New release" and
"Old release") that indicate whether or
not the site has the new volume version. If any flags remain after the
operation completes, it was not successful. The Cache Manager refuses to
access a read-only site marked with the "Old
release" flag, which potentially imposes a greater load on the
sites marked with the "New release" flag.
It is important to investigate and eliminate the cause of the failure and
then to issue the vos release command as many times as necessary to
complete the release without errors.
The pattern of site flags remaining in the volume's VLDB entry
after a failed release operation can help determine the point at which the
operation failed. Use the vos examine or vos listvldb command
to display the VLDB entry. The VL Server sets the flags in concert with the
Volume Server's operations, as follows:
- Before the operation begins, the VL Server sets the
"New release" flag on the read/write
site definition in the VLDB entry and the "Old
release" flag on read-only site definitions (unless the
read-only site has been defined since the last release operation and has
no actual volume, in which case its site flag remains
"Not released").
- If necessary, the Volume Server creates a temporary copy (a clone)
of the read/write source called the ReleaseClone (see the following
discussion of when the Volume Server does or does not create a new
ReleaseClone.) It assigns the ReleaseClone its own volume ID number, which
the VL Server records in the "RClone"
field of the source volume's VLDB entry.
- The Volume Server distributes a copy of the ReleaseClone to each read-only
site defined in the VLDB entry. As the site successfully receives the new
clone, the VL Server sets the site's flag in the VLDB entry to
"New
release".
- When all the read-only copies are successfully released, the VL Server
clears all the "New release" site flags.
The ReleaseClone is no longer needed, so the Volume Server deletes it and
the VL Server erases its ID from the VLDB entry.
By default, the Volume Server determines automatically whether or
not it needs to create a new ReleaseClone:
- If there are no flags ("New release",
"Old release", or
"Not released") on site definitions in
the VLDB entry, the previous vos release command completed
successfully and all read-only sites currently have the same volume. The
Volume Server infers that the current vos release command was
issued because the read/write volume has changed. The Volume Server
creates a new ReleaseClone volume and distributes a copy of the clone
volume to all the read-only sites. In order to reduce the amount of data
transferred during a release, the Volume Server sends incremental changes
to remote sites during the release. The Volume Server only sends files and
directories which have been changed in the read/write volume since the
previous release.
- If any site definition in the VLDB entry is marked with a flag, either the
previous release operation did not complete successfully or a new
read-only site was defined since the last release. The Volume Server does
not create a new ReleaseClone, instead distributing the entire existing
ReleaseClone to sites marked with the "Old
release" or "Not released"
flag. As previously noted, the VL Server marks each VLDB site definition
with the "New release" flag as the site
receives the ReleaseClone, and clears all flags after all sites
successfully receive it.
To override the default behavior, forcing the Volume Server to
create and release a new ReleaseClone to the read-only sites, include the
-force flag. This is appropriate if, for example, the data at the
read/write site has changed since the existing ReleaseClone was created
during the previous release operation.
The -force-reclone will force the creation of a new release
clone volume, but will not force a full volume dump to be distributed to the
remote sites. Instead, incremental changes will be distributed when
possible.
- -id <volume name or
id>
- Specifies either the complete name or volume ID number of a read/write
volume.
- -force
- Creates a new ReleaseClone and distributes the entire clone volume to all
read-only sites, regardless of the "New
release", "Old release", or
"Not released" site flags.
- -force-reclone
- Creates a new ReleaseClone and incrementally distributes the clone volume
to all read-only sites, regardless of the "New
release", "Old release", or
"Not released" site flags.
- -cell <cell
name>
- Names the cell in which to run the command. Do not combine this argument
with the -localauth flag. For more details, see vos(1).
- -noauth
- Assigns the unprivileged identity
"anonymous" to the issuer. Do not
combine this flag with the -localauth flag. For more details, see
vos(1).
- -localauth
- Constructs a server ticket using a key from the local
/etc/openafs/server/KeyFile file. The vos command
interpreter presents it to the Volume Server and Volume Location Server
during mutual authentication. Do not combine this flag with the
-cell argument or -noauth flag. For more details, see
vos(1).
- -verbose
- Produces on the standard output stream a detailed trace of the command's
execution. If this argument is omitted, only warnings and error messages
appear.
- -encrypt
- Encrypts the command so that the operation's results are not transmitted
across the network in clear text. This option is available in OpenAFS
versions 1.4.11 or later and 1.5.60 or later.
- -noresolve
- Shows all servers as IP addresses instead of the DNS name. This is very
useful when the server address is registered as 127.0.0.1 or when dealing
with multi-homed servers. This option is available in OpenAFS versions
1.4.8 or later and 1.5.35 or later.
- -config
<configuration directory>
- Set the location of the configuration directory to be used. This defaults
to /etc/openafs, except if -localauth is specified, in which
case the default is /etc/openafs/server. This option allows the use
of alternative configuration locations for testing purposes.
- -help
- Prints the online help for this command. All other valid options are
ignored.
The following command clones the read/write volume usr and
releases it to the read-only sites defined in its VLDB entry.
% vos release usr
The issuer must be listed in the
/etc/openafs/server/UserList file on the machine specified with the
-server argument and on each database server machine. If the
-localauth flag is included, the issuer must instead be logged on to
a server machine as the local superuser
"root".
IBM Corporation 2000. <http://www.ibm.com/> All Rights
Reserved.
This documentation is covered by the IBM Public License Version
1.0. It was converted from HTML to POD by software written by Chas Williams
and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.