2005-12-08 12:14:33 +00:00
|
|
|
=head1 NAME
|
|
|
|
|
2007-11-11 22:54:56 +00:00
|
|
|
vos_release - Updates read-only volumes to match the read/write source volume
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
=for html
|
|
|
|
<div class="synopsis">
|
|
|
|
|
2013-02-01 22:46:45 +00:00
|
|
|
B<vos release> S<<< B<-id> <I<volume name or ID>> >>>
|
|
|
|
[B<-force>] [B<-force-reclone>]
|
2009-10-08 18:31:00 +01:00
|
|
|
S<<< [B<-cell> <I<cell name>>] >>>
|
2015-03-04 22:25:14 +00:00
|
|
|
[B<-noauth>] [B<-localauth>]
|
2013-06-20 23:45:05 +01:00
|
|
|
[B<-verbose>] [B<-encrypt>] [B<-noresolve>]
|
|
|
|
S<<< [B<-config> <I<config directory>>] >>>
|
|
|
|
[B<-help>]
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2009-10-08 18:31:00 +01:00
|
|
|
B<vos rel> S<<< B<-i> <I<volume name or ID>> >>>
|
2013-02-01 22:46:45 +00:00
|
|
|
[B<-force>] [B<-force-r>]
|
2015-03-04 22:25:14 +00:00
|
|
|
S<<< [B<-c> <I<cell name>>] >>>
|
2013-06-20 23:45:05 +01:00
|
|
|
[B<-noa>] [B<-l>] [B<-v>] [B<-e>] [B<-nor>]
|
|
|
|
S<<< [B<-co> <I<config directory>>] >>>
|
|
|
|
[B<-h>]
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
=for html
|
|
|
|
</div>
|
|
|
|
|
2005-12-08 12:14:33 +00:00
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The B<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 B<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 C<.readonly>
|
|
|
|
extension.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
For users to have a consistent view of the file system, the release of the
|
2005-12-09 14:48:56 +00:00
|
|
|
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 B<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.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
First, the command interpreter generates an error message on the standard
|
2005-12-09 14:48:56 +00:00
|
|
|
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 (C<New
|
|
|
|
release> and C<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 C<Old release> flag, which potentially imposes a greater
|
|
|
|
load on the sites marked with the C<New release> flag. It is important to
|
|
|
|
investigate and eliminate the cause of the failure and then to issue the
|
|
|
|
B<vos release> command as many times as necessary to complete the release
|
|
|
|
without errors.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
The pattern of site flags remaining in the volume's VLDB entry after a
|
2005-12-09 14:48:56 +00:00
|
|
|
failed release operation can help determine the point at which the
|
|
|
|
operation failed. Use the B<vos examine> or B<vos listvldb> command to
|
|
|
|
display the VLDB entry. The VL Server sets the flags in concert with the
|
|
|
|
Volume Server's operations, as follows:
|
|
|
|
|
|
|
|
=over 4
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=item *
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
Before the operation begins, the VL Server sets the C<New release> flag on
|
|
|
|
the read/write site definition in the VLDB entry and the C<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
|
2005-12-08 12:14:33 +00:00
|
|
|
which case its site flag remains C<Not released>).
|
|
|
|
|
|
|
|
=item *
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
If necessary, the Volume Server creates a temporary copy (a I<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 C<RClone> field of the source volume's VLDB
|
|
|
|
entry.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=item *
|
|
|
|
|
|
|
|
The Volume Server distributes a copy of the ReleaseClone to each read-only
|
2005-12-09 14:48:56 +00:00
|
|
|
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 C<New
|
|
|
|
release>.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=item *
|
|
|
|
|
|
|
|
When all the read-only copies are successfully released, the VL Server
|
2005-12-09 14:48:56 +00:00
|
|
|
clears all the C<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.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
=back
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
By default, the Volume Server determines automatically whether or not it
|
|
|
|
needs to create a new ReleaseClone:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item *
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
If there are no flags (C<New release>, C<Old release>, or C<Not released>)
|
|
|
|
on site definitions in the VLDB entry, the previous B<vos release> command
|
|
|
|
completed successfully and all read-only sites currently have the same
|
|
|
|
volume. The Volume Server infers that the current B<vos release> command
|
|
|
|
was issued because the read/write volume has changed. The Volume Server
|
2013-02-01 22:46:45 +00:00
|
|
|
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.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=item *
|
|
|
|
|
|
|
|
If any site definition in the VLDB entry is marked with a flag, either the
|
2005-12-09 14:48:56 +00:00
|
|
|
previous release operation did not complete successfully or a new
|
|
|
|
read-only site was defined since the last release. The Volume Server does
|
2013-02-01 22:46:45 +00:00
|
|
|
not create a new ReleaseClone, instead distributing the entire existing
|
2005-12-09 14:48:56 +00:00
|
|
|
ReleaseClone to sites marked with the C<Old release> or C<Not released>
|
|
|
|
flag. As previously noted, the VL Server marks each VLDB site definition
|
|
|
|
with the C<New release> flag as the site receives the ReleaseClone, and
|
|
|
|
clears all flags after all sites successfully receive it.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
To override the default behavior, forcing the Volume Server to create and
|
2009-10-08 18:31:00 +01:00
|
|
|
release a new ReleaseClone to the read-only sites, include the B<-force>
|
2005-12-09 14:48:56 +00:00
|
|
|
flag. This is appropriate if, for example, the data at the read/write site
|
|
|
|
has changed since the existing ReleaseClone was created during the
|
2005-12-08 12:14:33 +00:00
|
|
|
previous release operation.
|
|
|
|
|
2013-02-01 22:46:45 +00:00
|
|
|
The B<-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.
|
|
|
|
|
2005-12-08 12:14:33 +00:00
|
|
|
=head1 OPTIONS
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
=item B<-id> <I<volume name or id>>
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
Specifies either the complete name or volume ID number of a read/write
|
|
|
|
volume.
|
|
|
|
|
2009-10-08 18:31:00 +01:00
|
|
|
=item B<-force>
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2013-02-01 22:46:45 +00:00
|
|
|
Creates a new ReleaseClone and distributes the entire clone volume to
|
|
|
|
all read-only sites, regardless of the C<New release>, C<Old release>, or
|
|
|
|
C<Not released> site flags.
|
|
|
|
|
|
|
|
=item B<-force-reclone>
|
|
|
|
|
|
|
|
Creates a new ReleaseClone and incrementally distributes the clone volume to
|
|
|
|
all read-only sites, regardless of the C<New release>, C<Old release>, or
|
|
|
|
C<Not released> site flags.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2013-06-30 03:06:51 +01:00
|
|
|
=include fragments/vos-common.pod
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head1 EXAMPLES
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The following command clones the read/write volume usr and releases it to
|
|
|
|
the read-only sites defined in its VLDB entry.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
% vos release usr
|
|
|
|
|
|
|
|
=head1 PRIVILEGE REQUIRED
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The issuer must be listed in the F</usr/afs/etc/UserList> file on the
|
|
|
|
machine specified with the B<-server> argument and on each database server
|
|
|
|
machine. If the B<-localauth> flag is included, the issuer must instead be
|
|
|
|
logged on to a server machine as the local superuser C<root>.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
L<vos(1)>,
|
|
|
|
L<vos_addsite(1)>,
|
|
|
|
L<vos_examine(1)>,
|
|
|
|
L<vos_listvldb(1)>
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
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.
|